Сине-зелёные Deployments

Deployment предоставляет одну стабильную идентичность приложения и владеет двумя слотами среды выполнения. Opfield готовит новый релиз в неактивном слоте, проверяет его состояние и переключает трафик только после готовности. Прежний активный слот остаётся кандидатом для отката, пока жизненный цикл Deployment не выведет его из эксплуатации.

Управляйте слотами через Deployment, а не как отдельными Containers. Deployment отвечает за переключение трафика, историю релизов, возможность отката и связь между двумя дочерними средами выполнения. Прямое изменение активного дочернего ресурса создаёт расхождение состояния и ослабляет гарантии безопасного отката.

Что меняет решение использовать Deployment

Выбирайте Deployment, если основной риск релиза связан с запуском и состоянием приложения, а во время переключения на одной ноде Docker могут безопасно работать два слота. В результате сервис сохраняет стабильную идентичность, новый релиз продвигается контролируемо, а для отката остаётся явный кандидат. Это особенно полезно для публичных или общих сервисов, где прямая замена одного Container вызвала бы лишний перерыв.

Команда приложения отвечает за готовность релиза, смысл проверки состояния, совместимость миграций данных и решение о продвижении или откате. Команда платформы отвечает за ёмкость ноды, доверие к образу, Routes, доставку секретов и доступность пути отката. Opfield координирует слоты и записывает операцию, но не может сделать несовместимое изменение схемы обратимым.

Не используйте сине-зелёный выпуск вместо стратегии работы с данными. Оба слота могут временно обращаться к одной внешней зависимости или общим постоянным данным. Миграции базы данных должны оставаться обратно совместимыми в течение окна отката. Иначе план релиза должен явно признавать, что одного отката среды выполнения недостаточно.

Предварительные условия

Используйте неизменяемый дайджест образа или одобренный артефакт сборки. До начала релиза убедитесь, что целевая нода подключена, образ можно загрузить, секреты и тома настроены правильно, ограничения ресурсов укладываются в ёмкость ноды, а проверка состояния Route обращается к важному для пользователей пути приложения. В рамках того же изменения проверьте зависимые Routes и привязки баз данных.

Выпустите новую версию

1. Откройте Deployment и подготовьте новый образ и конфигурацию.
2. Проверьте входные данные релиза: переменные среды, секреты, тома, выбранную среду выполнения и проверку состояния.
3. Запустите релиз и следите за Task, пока Opfield готовит неактивный слот.
4. Дождитесь успешной проверки состояния.
5. Дождитесь переключения трафика, затем проверьте реальный запрос, журналы приложения и метрики.
6. Сохраняйте предыдущий слот до окончания согласованного окна отката.

Сохранение нового тега образа, команды, точек монтирования, меток или среды выполнения в настройках Deployment запускает такой же выпуск; кнопка называется Save & Deploy. Сохранение переменных среды работающего Deployment развёртывает их в резервный слот. Ограничения ресурсов сохраняются вместе с конфигурацией. Для развёртывания или обновления Deployment с новым образом, командой или окружением нужны docker:containers:environment и docker:containers:secrets на него, потому что новый слот получает окружение и секреты Deployment. Команды развёртывания ждут загрузки образа, периода запуска и тайм-аута развёртывания, прежде чем сообщить результат.

Через API запрос POST /api/docker/nodes/{nodeId}/deployments/{deploymentId}/deploy с env заменяет всё окружение Deployment и сохраняет его в конфигурации, поэтому передавайте все переменные, которые должны остаться. Инструмент MCP deploy_docker_deployment и ассистент, наоборот, записывают env поверх сохранённого окружения и удаляют ключи из removeEnv; остальные сохранённые переменные остаются. В обоих случаях нужен docker:containers:environment.

Релизы, запущенные через webhook, используют тот же путь авторизации и проверки состояния. Запрос webhook не обходит владение Deployment и не превращает неудачную сборку в публичный релиз.

Сбой и откат

Если подготовка или проверка состояния завершилась ошибкой до переключения трафика, текущий активный слот продолжает обслуживать запросы. Откройте Task релиза и определите слой сбоя: загрузку образа, запуск, проверку состояния, секрет, том или ёмкость. Исправьте причину и начните новый релиз, не изменяя неисправный слот вручную. Слот-кандидат, не прошедший проверку состояния, останавливается и сохраняется ради журналов, поэтому он не перезапускается в цикле и не забирает соединения с базой данных у обслуживающего слота; последующее переключение на этот слот пересоздаёт его по записанному выпуску.

Если после переключения появилась заметная клиентам регрессия, используйте явное действие отката. Оно вернёт трафик на сохранённый заведомо исправный слот и запишет событие в историю Deployment. После отката проверьте Route, состояние приложения и журналы. Переключение слота сохраняет версию резервного слота, а откат возвращает предыдущий выпуск. Не удаляйте новый слот, пока не зафиксированы данные инцидента и следующие действия.

Операции во время перезапусков, обновлений и сборок

Операции Deployment переживают перезапуски Opfield. Надёжная фоновая проверка завершает вывод предыдущего слота из обслуживания, а прерванный релиз восстанавливается по слоту, который фактически обслуживает маршрутизатор ноды. Если ноду не удаётся проверить в течение 5 минут, релиз помечается как неудачный с указанием причины, например остановленного маршрутизатора или демона, который не может сообщить обслуживающий слот; во втором случае обновите демон Docker.

Пока выполняется релиз, настройки Deployment заблокированы: сохранение возвращает DEPLOYMENT_BUSY, а Console отключает Save до завершения релиза. Пока сборка из Git развёртывается в Deployment, изменения жизненного цикла и конфигурации возвращают BUILD_ROLLOUT_IN_PROGRESS; дождитесь завершения развёртывания. Deployment возвращается на активный слот после Stop и затем Start или после перезапуска ноды, а перезапуск Opfield посреди развёртывания не теряет выпуск. Во время обновления Opfield новые операции Deployment отклоняются с GATEWAY_UPDATING до завершения обновления; см. Условия обновления в 2.11.

Маршрутизатор Deployment

У каждого Deployment на его ноде есть небольшой контейнер-маршрутизатор на nginx. Он принимает трафик Deployment и передаёт его активному слоту; переключение или откат меняют только цель маршрутизатора.

• Он возвращается после перезагрузки. Маршрутизаторы работают с политикой перезапуска unless-stopped. При запуске Docker-демон восстанавливает маршрутизатор каждого обслуживающего Deployment: маршрутизатор, созданный старым релизом или оставленный с политикой перезапуска no, получает текущую политику или пересоздаётся по конфигурации, которую он обслуживает, вместе с маршрутами и опубликованными портами, и направляется на тот слот приложения, который действительно работает. Демон повторяет восстановление каждую минуту, пока оно не удастся; если Deployment занят операцией, восстановление ждёт её и выполняется сразу после её завершения. Deployment, который намеренно остановили или принудительно завершили, сохраняет свой маршрутизатор остановленным.
• Операции запускают остановленный маршрутизатор. Развёртывание, переключение слота, обновление маршрутизатора или запуск поднимают маршрутизатор, остановленный принудительным завершением или остановкой, а не завершаются ошибкой, и Deployment, у которого не запускается активный слот, больше не зависает.
• Он не зависит от DNS Docker. В конфигурации маршрутизатора указан адрес контейнера активного слота, и маршрутизатор на любой версии nginx обращается к нему напрямую, без DNS; демон проверяет адрес каждые 5 секунд и переписывает конфигурацию, когда он меняется. Имя слота через DNS Docker разрешает только конфигурация, записанная до того, как адрес слота стал известен. Существующие маршрутизаторы обновляются на месте, без пересоздания.
• Он не пишет журнал доступа. Каждый запрос и так записывает нода Ingress. Поэтому маршрутизатор никогда не блокируется на выводе своего контейнера, который забирает dockerd, и зависший Docker Engine (dockerd) не останавливает трафик к работающему Deployment.
• Приложения, которые пишут в журнал каждый запрос. Вывод контейнера проходит через конвейер журналов Docker, который перестаёт опустошаться, пока dockerd заморожен. Поэтому приложение, которое на каждый запрос пишет строку в stdout или stderr, может остановиться, когда этот канал заполнится, хотя маршрутизатор и Secure Links продолжают работать. Не выводите журнал каждого запроса в вывод контейнера или учитывайте, что такое приложение может остановиться, пока dockerd заморожен.
• Размер тела запроса не ограничен. Маршрутизатор пропускает тела запросов любого размера (ограничение задаёт Route) и передаёт их слоту потоком, а не сохраняет на диск. Маршрутизаторы, созданные до этого изменения, получают его при следующем развёртывании, переключении слота или перезапуске.
• Его собственные ошибки помечены. Если маршрутизатор не может достучаться до активного слота, он отвечает 502 или 504 с заголовком X-Gateway-Deployment-Router: upstream-unavailable, по которому ошибку маршрутизатора можно отличить от ошибки приложения. Workload Availability использует его, чтобы решить, готово ли размещение Deployment.

Последствия вывода из эксплуатации

Удаление Deployment удаляет его управляемые слоты и может удалить связи доступа, принадлежащие только этому ресурсу. Deployment можно удалить, даже если в его резервном слоте ещё работает более старый образ. Сначала отсоедините или перенесите Routes, привязки баз данных и постоянные данные, которые должны сохраниться. Откат Deployment защищает предыдущий слот среды выполнения, но не заменяет резервное копирование изменяемых данных тома.

Критерии успеха и политика выпуска

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

Задайте явное окно отката. В течение этого окна сохраняйте прежний артефакт и конфигурацию доступными и не вносите изменения, которые помешают их запустить. Если более поздняя проблема не связана с новым релизом, зафиксируйте это до отката: лишнее переключение слотов усложняет диагностику.

Операторские детали: ёмкость и неудачные релизы

Для неактивного слота одновременно с активным нужны процессор, память, хранилище, порты и доступ к загрузке образа. Пока слоты работают одновременно, они также делят каждую привязку базы данных и хранилища Deployment, а она выдерживает до 64 одновременных соединений; задавайте пулы соединений так, чтобы новый слот мог открыть свои, пока обслуживающий держит свои. См. Ёмкость привязки и пулы соединений. Планирование ёмкости должно учитывать это временное пересечение. Если ресурсов для неактивного слота недостаточно, релиз должен завершиться ошибкой до изменения трафика, сохранив активный сервис.

Если состояние не становится готовым, откройте журналы неактивного слота и точный ответ проверки состояния. Исправьте образ или конфигурацию релиза и создайте новую попытку; не изменяйте управляемый дочерний Container. Если продвижение завершилось, но итоговая проверка не прошла, используйте записанное действие отката, а затем проверьте путь сервиса и идентичность активного слота.