Нужен совет: корректна ли связка Nginx — Docker — Nginx (proxy)?

Question

[Paul Petrov]

Привет!

Друзья DevOps, подскажите советом,пожалуйста!
Хочу мнение со стороны.

Суть

В проекте есть Dockerfile с multi-stage builds:

1. FROM node:13.10.1-alpine as builder - в нём приложение билдуется в статику
   
2. FROM nginx:1.14-alpine - итоговый образ с файлами приложения и Nginx "на раздаче"
   

Есть Jenkinsfile, pipeline, прогоняющий код по тестам, запускающий сборку нового образа, создание контейнера на его основе, запуск нового контейнера и остановку старого.

На сервере, где должен крутиться контейнер, стоит Nginx в качестве proxy до приложения в контейнере с помощью proxy_pass http://localhost:<номер порта>

Таким образом, получается цепочка:
Клиент -> Nginx (proxy) -> Nginx (in Docker) -> App

Схема работает, но задумался, возможно, есть вариант проще?

Comments

[Дмитрий Шицков]

Хотелось бы понимать что у вас за app в образе. Если статика, то зачем её в докер? Если бекенд сервис, то nginx явно лишняя прослойка и сервис можно вывешивать портами наружу из докера без него.
Однако серьёзного криминала тут нет. Если есть причины использовать такую схему - используйте.

[Paul Petrov]

Дмитрий Шицков, спасибо за уточнение.
Отчасти, это эксперимент по организации конвейера силами Jenkins и Docker.
В роли App я не рассматривал исключительно статику: там может быть и API, и backend.

В текущем варианте, приложение - Svelte App.
На стадии builder в Dockerfile запускаю команду npm build и она компилирует мне все сорцы в статику.
Я переношу результат в заветную директорию для Nginx в контейнере. Конфиг там проще некуда:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

Всё остальное - логи, ssl, http2, обработка локаций css / js / img и т.п. - в конфиге для прокси.
Особых причин делать так, как описано, не наблюдаю - скорее решение придумывалось на ходу.

Думал при слиянии в master настроить запуск процедуры тестов, сборки и выкатки в прод. Пока без поклажи в реестр пакетов / образов. Можно, конечно, билдовать статику сразу после тестов и класть в нужное место вне контейнера командами прямо из Jenkinsfile, но давать Jenkins-пользователю рулить в файловой системе кажется неверным подходом.

+ Может я неверно понял идею, но подумал, что возможность накатить версию принудительно / откатиться к прошлому состоянию приложения из реестра контейнеров / пакетов в случае каких-то проблем - это хорошо.
Потому в Docker, хоть пока и без хранения прошлых версий App в реестре.

С backend-сервисами, понятно, можно обойтись и без прослойки Nginx в контейнере.

[Дмитрий Шицков]

Paul Petrov,

С backend-сервисами, понятно, можно обойтись и без прослойки Nginx в контейнере.

Да, с этим понятно.

Со статикой - вариантов много.

Это может быть и nginx в docker - и тут нет проблем, если таких контейнеров единицы и нет острой необходимости в отказоустойчивости, когда статика начнет занимать уже какие-то ощутимые ресурсы. Преимущества вы озвучили.

Но это может быть единый сервер Nginx, куда статика выкатывается каким-либо инструментом для деплоя. К сожалению, мне доводилось работать только с Capistrano / Ansistrano в качестве такой роли. С таким способом так же будет возможность быстрого отката, так как инструмент использует ссылки для переключения на каталог необходимой версии.

Со стороны Jenkins можно сокрыть работу пайплайна, ограничить доступ к его изменению и выполнению.

Answer 1

[Иван Корюков]

В этом нет ничего криминального. Если вам надо именно так - делайте. Если видите способ упростить систему - упрощайте.
Главное не забыть прокинуть реальный ip и схему в заголовке.

Кстати, k8s например примерно так и работает. Там 80,443 порт слушает т.н. ингрес - обычно тот же nginx, конфиг которого задаётся через yml файл. И вот он принимает все запросы и в зависимости от настроек проксирует их на бэкэнды, в том числе и на внутренние nginx'ы.