Сквозная публикация приложения

Этот сценарий ведёт от одобренного артефакта приложения к публичному адресу HTTPS. До начала подготовьте ноды, доступ к Domain и права на изменение Route. Если это первая публикация, начните с установки и добавления первой ноды. Назначьте владельцев приложения, платформы, DNS/TLS и инцидентов: один человек, нажавший Create, не должен быть единственным средством контроля релиза.

Целевой результат — сервис, который работоспособен с точки зрения пользователя, доступен через нужный Domain, наблюдается в Gateway, защищён ожидаемой политикой доступа и допускает откат без перестройки контура управления.

Выберите модель рабочей нагрузки

Используйте ресурс, соответствующий владению жизненным циклом:

• Container подходит для простой автономной службы, где замена выполняется явным Recreate.
• Deployment нужен для сине-зелёного выпуска с проверкой состояния и сохранённым слотом отката.
• Compose Project объединяет несколько служб, сетей и томов в одно приложение с единым жизненным циклом неизменяемых ревизий.

Не представляйте многосервисное приложение набором несвязанных автономных Containers только ради прямого редактирования каждого дочернего объекта. Это уничтожает владение проекта и усложняет откат, анализ расхождений и зависимые изменения.

До продолжения утвердите точный дайджест образа или коммит Git, ожидаемые ограничения ресурсов, источники секретов, политику резервного копирования томов, зависимости от баз данных, адрес проверки состояния, публичное имя хоста и цель отката.

1. Подготовьте ёмкость и владение

Зарегистрируйте или выберите ноду Docker со статусом online для рабочей нагрузки и ноду Ingress со статусом online для публичного трафика. Убедитесь, что у каждой ноды правильная роль, совместимая версия, необходимые возможности и достаточный запас ресурсов. Зелёное состояние ноды не доказывает, что большой образ поместится на диске или запрошенный порт свободен.

Назначьте области до релиза. Разработчику может требоваться видимость источника и сборки, оператору платформы — управление жизненным циклом рабочей нагрузки, оператору Ingress — доступ к Route. Не выдавайте права системного администратора только потому, что сценарий затрагивает несколько типов ресурсов.

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

2. Создайте или подключите рабочую нагрузку

Создайте Container, Deployment или Compose Project. Настройте неизменяемый дайджест образа или одобренный источник Git, command, переменные среды, защищённые секреты, поведение перезапуска, ограничения ресурсов и управляемые тома.

Предпочитайте управляемые тома или явно одобренное внешнее хранилище. Привязки каталогов хоста (bind mounts) закрепляют нагрузку за одним хостом и не переносятся обычными сценариями архива или миграции. Не помещайте секреты в обычные значения среды, исходный файл Compose, аргументы сборки или метки образа.

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

3. Докажите состояние приложения до подачи публичного трафика

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

Для Deployment настройте путь проверки, ожидаемый диапазон статусов, необязательное совпадение тела, тайм-аут, интервал и порог медленного ответа. Сохраняйте предыдущий слот, пока новая версия не пройдёт проверку состояния и внешнюю приёмку. Для Container или службы Compose Project проверьте фактическое состояние среды выполнения, журналы и ответ приложения до создания публичного Route.

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

4. Подготовьте Domain и TLS

Создайте или выберите Domain, разместите его на нужной ноде Ingress и убедитесь, что авторитетный DNS указывает на публичный служебный адрес. Выпустите, импортируйте или выберите сертификат, покрывающий точное имя хоста или подходящий подстановочный домен.

Разделение владения упрощает работу: изменение DNS не требует менять рабочую нагрузку, а откат рабочей нагрузки — заменять сертификат. Назначьте ответственного за продление загруженных сертификатов и получателя уведомлений об истечении срока.

5. Создайте Route

Создайте Route для Domain и выберите управляемую рабочую нагрузку как целевую службу. Для Docker Container, службы Compose Project или Deployment Gateway может создать Secure Link, чтобы Ingress обращался к нагрузке через Relay без публикации порта приложения на хосте только ради этого пути.

Выберите порт и схему целевой службы, которые фактически обслуживает приложение. Включите публичный TLS и Force HTTPS по требованиям. WebSockets, поведение префикса, изменения буферизации, пользовательские тайм-ауты и шаблоны включайте только тогда, когда этого требует контракт приложения: каждое исключение расширяет объём проверки.

Дождитесь успешного согласования Route и конфигурации Ingress. Не редактируйте созданную конфигурацию nginx вручную: Gateway остаётся источником истины и восстановит управляемое состояние.

6. Приёмочная проверка

Пользовательский путь

• DNS правильно разрешается из внешней сети.
• TLS доверен и покрывает имя хоста.
• Основная страница или адрес API возвращает ожидаемый релиз.
• Вход, обратный вызов, загрузки, потоки данных и WebSockets работают, если используются.
• Ответы обслуживания и запрета доступа намеренны и выглядят ожидаемо.

Путь платформы

• Рабочая нагрузка сообщает одобренный дайджест или коммит.
• Состояние среды выполнения, журналы и использование ресурсов стабильны.
• Route и среда выполнения Secure Link работоспособны.
• Журналы доступа и ошибок Ingress содержат приёмочные запросы без повторяющихся сбоев целевой службы.
• Перезапуск рабочей нагрузки не теряет постоянные данные или конфигурацию привязки.
• Уведомления достигают ожидаемого ответственного при контролируемом тестовом событии.

Путь управления

• Пользователи с минимальными правами управляют только назначенными ресурсами.
• Релиз, изменение Route и связанные операции присутствуют в Tasks, недавней активности и аудите.
• Резервное копирование охватывает тома с состоянием и внешние зависимости, а не только определение Container.

7. Откат и граница инцидента

До продвижения запишите последнюю заведомо исправную цель. Для Deployment подтвердите состояние предыдущего слота. Для Container сохраните прежние неизменяемый дайджест и конфигурацию. Для Compose Project — предыдущую неизменяемую ревизию. Для доставки из Git сохраните одобренную сборку и точный коммит.

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

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

Симптом	Сначала проверьте	Подробная страница
Domain не открывается	DNS, ноду Ingress и итоговую Task Route	Диагностика Ingress
Ошибка TLS	Имя, срок и размещение сертификата	Сертификаты
Route есть, но приложение не отвечает	Состояние рабочей нагрузки, порт и Secure Link	Приватные целевые службы