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

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

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

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

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

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

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

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

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

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

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

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

Сбой и откат

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

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

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

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

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

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

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

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

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

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