Бесшовный деплой с Docker Swarm

Сага обычно реализуется как обычный обработчик команды и слушатель событий. Хореографическая сага реализуется обычным вызовом наших сущностей из слушателей событий других сущностей. И даже сагу-оркестратор при необходимости хранить состояние можно оформить тоже как обычную Doctrine-сущность.

Мы здесь как раз все эти варианты рассмотрим.

Вместо хранения сессий по умолчанию в файлах переходят на хранение в БД или в Redis. Для этого во многих фреймворках вместо HttpSession имеются классы DbSession или RedisSession.

А для хранения файлов у себя на нужном хосте можно через докер на нём поднять сервис хранилища. Потом из php-fpm загружать в него файлы по FTP и проксировать запросы из gateway.

Если частей несколько, то следят за обратной совместимостью API и занимаются его версионированием. То есть новые вещи добавляют аккуратно, чтобы они не ломали старые запросы. Тогда проблем с поломками фронтенда или мобильного приложения не будет.

Проблема оказалась не в этом, Конфликты faerwalld iptables and nftables . Centos 8 в топку пока)

Да, это специфика работы overlay-сети в Swarm. При балансировке между несколькими нодами на gateway передаётся не реальный клиентский запрос с реальным IP-адресом, а уже перенаправленный внутрь запрос из балансировщика Docker с IP-адресом этого балансировщика.

Так что если сильно нужен реальный IP и не хочется ставить внешний Nginx с простановкой X-Real-IP, то как компромисс можно привязывать порты gateway напрямую к портам виртуальной машины через режим mode:host вместо проброса через docker-балансировщик:

services:
    gateway:
        image: ${REGISTRY}/auction-gateway:${IMAGE_TAG}
        volumes:
            - /etc/letsencrypt:/etc/letsencrypt:ro
            - /var/www/html:/var/www/html:ro
        ports:
            - target: 80
              published: 80
              protocol: tcp
              mode: host
            - target: 443
              published: 443
              protocol: tcp
              mode: host
        deploy:
            placement:
                constraints: [node.role == manager]

Тогда входящий запрос будет отправляться в gateway напрямую. Но при таком прямом подключении портов в обход Swarm-а не получится запускать несколько реплик одновременно. Так что бесшовное обновление сделать не получится и gateway при каждой сборке будет отваливаться при обновлении.

Для бесшовного деплоя надо будет, например, присваивать и менять версию gateway вручную:

docker build --tag gateway:1.3 ...

и в продакшене в image указывать gateway:1.3. Тогда этот сервис не будет обновляться при каждой сборке. Но придётся вручную помнить, что нужно будет при изменении везде менять эту версию.

Либо можно присвоить дополнительно тег latest:

docker build --tag gateway:${IMAGE_TAG} --tag gateway:latest ...

и использовать в продакшене gateway:latest, чтобы Swarm его перезапускал только когда увидит изменения после pull. Но так мы не сможем сделать rollback.

Потому что на Swarm перейти проще. А K8s уже следующий продвинутый шаг.

победил вот этим в prod.yml у gateway добавил

ports:

  - mode: host
    protocol: tcp
    published: 80
    target: 80
  - mode: host
    protocol: tcp
    published: 443
    target: 443

В Swarm будем использовать crazymax/swarm-cronjob. А в K8s есть CronJob.

PS: может MinIO, либо NFS или что будет оптимальней.

Для хранения пользовательских файлов вроде фотографий вместо вольюмов уместно сразу использовать отдельный файловый хостинг вроде хранилища Amazon S3 или аналогов. А как эмулятор хранилища для локальной разработки удобно как раз подключить minio.

В этой серии пока не будет.

Вместо сложного ручного разворачиванию кластера лучше взять готовый Managed Kubernetes от любого облачного провайдера и оплачивать его из бюджета компании.

А на стороне приложения нужно будет заменить docker-compose-production.yml на набор yaml-файлов для Kubernetes и переписать команду deploy на использование kubectl.

Добавил. Спасибо!

По умолчанию Swarm так не умеет. Можно попробовать найти кастомный драйвер для томов вместо local. Либо ко всем виртуалкам примонтировать сетевую папку по NFS и в docker-compose.yml монтировать уже её.

Но вместо этого удобнее использовать отдельный файловый хостинг и из кода загружать в него файлы по протоколу FTP или S3, как мы сделали в эпизоде 60.

Swarm сам перестаёт маршрутизировать новые HTTP-запросы на инстанс перед тем как начать его отключать. С этим проблем нет и так.

А для завершения процесса оркестратор сначала отправляет ему сигнал завершения, а потом после таймаута принудительно отключает. Поэтому в слушателе очереди можно спрограммировать обработку сигналов как в примере к php-amqplib, чтобы по сигналу завершения слушатель отключался от очереди и завершал работу.

Для бесшовного деплоя организовывают постепенную миграцию. Это уже обсуждали здесь.