Можете помочь консультацией по вопросу организации доступа к сайту с использованием docker swarm и ci/cd?
Вопросы такие:
1. Какая должна быть схема доступа к https сайту, если использутеся swarm и почему?
- один шлюз с nginx в качестве reverse_proxy и одно и более приложение в upstream?
- без шлюза: nginx и приложение в единственном числе для каждого сервиса?
- иное
(на мой взгляд тут все зависит от задачи, т.к. есть преимущества / недостатки у каждого подхода. вот по этому поводу и хотелось бы проконсультироваться)
2. как определить какой из сервисов обновился в автоматическом режиме (чтобы не пересобирать образ docker и не ребутить не_измененные образы)? Мой текущий в репозиторий в github содежит внутри сервисы разложенные по папкам и при каждом push в master собираются контейнеры. Раскладывать сервисы по отдельным git веткам не хочу, т.к. это убивает всю идею единого репозитория. хотелось бы поговорить с человеком с опытом в подобных вопросах.
Коллеги. прошу порекомендуйте контакты людей, с которыми можно было бы поговорить по первому и второму вопросу.
P.S. В гугле искал. там какаято нелогичность в статьях. ну например чтобы организовать доступ по https (чтобы сертбот мог обновить сертификаты) делают фоновый процесс с nginx который ребутится скриптом запущенным на переднем плане. после такого нет особого доверия к остальному написанному, хотя может оно и есть истина.
на ноды сварма трафик надо как-то забрасывать , то есть какой-то load-balancer у вас должен быть до него. ок, предположим он у вас есть.
дальше все достаточно просто и отработано.
схема 1. старая. ставим на все ноды consul в нем регистрируем все контейнеры, получаем авто-дискавери и автоматически обновляемые конфиги Nginx-а. это для примера. консул очень забавная зверушка.
схема 2. traefic. в зависимосте от лейблов в контейнерах и сервисах будет сам разводить трафик по сервисам, запрашивать сертификаты и т.п. Это такая реализация ingress для докера.
Простой
