Продвижение релиза из dev в stage

Kustomize разделил общую «Площадку» и параметры окружений. Теперь выпустим API версии два сначала в dev, затем перенесём его в stage. Результат урока — promotion как изменение Git намерения и ручное применение одного артефакта, а не повторная сборка похожего кода под другим именем среды.

В архиве app/api-v2 содержит полный сервер с третьим элементом каталога «Релиз из Git». Reader самостоятельно строит ploshchadka-api:2 и загружает его в kind согласно README. Автор не выполнял сборку, Git commit, публикацию bundle или sync. Все изменения состояния ниже ожидаемые; материал не объявляет кандидата проверенным выпуском до самостоятельных наблюдений читателя.

Кандидат должен иметь известное происхождение

Version два отличается прикладным результатом: каталог API получает ещё один урок. Контракт /api/lessons сохраняется, web версии один продолжает читать массив. Это небольшое совместимое изменение позволяет сосредоточиться на продвижении, не вводя одновременно миграцию данных или другой формат ответа. API по-прежнему stateless и использует включённую константу каталога.

Tag ploshchadka-api:2 обозначает локальную сборку reader из app/api-v2. Его не следует перезаписывать другим кодом после выбора кандидата. Если два окружения используют одинаковую строку tag, но на узлах лежат разные слои, сравнение Git потеряет связь с фактическим артефактом. Для производственного пути нужен проверенный digest и надёжный registry; здесь сохранён явный локальный предел.

Argo CD не выполняет подготовку image. Если Git уже указывает два, а образ отсутствует, Deployment может стать желаемым по spec и всё равно не запустить Pod. Поэтому наличие кандидата в kind проверяется раньше решения о sync. В этой подготовке нет фактического image digest или вывода успешной загрузки: их обязан получить reader при собственном проходе.

Меняем только dev намерение

В gitops/overlays/dev/kustomization.yaml reader меняет newTag API с один на два и APP_VERSION с один на два. Stage остаётся прежним. Два поля принадлежат одному совместимому release набору: код получает дополнительный урок, а текст ответа обозначает выбранную версию. GREETING продолжает говорить dev, replicas остаётся один.

Следующий фрагмент показывает изменяемые значения, а не весь kustomization файл. Остальные строки сохраняются из предыдущей главы.

images:
  - name: ploshchadka-api
    newTag: '2'
  - name: ploshchadka-web
    newTag: '1'
# В configMapGenerator api-config:
# APP_VERSION=2

После редактирования нужен commit. Его сообщение объясняет прикладное изменение и выбранное dev окружение. Тег candidate-2 может отметить эту revision для обсуждения, но не заменяет сам commit и не создаёт образ. Затем reader публикует bundle в локальный Git Service. До этого repo-server продолжает читать прежний main, даже если рабочая копия уже показывает правильные файлы.

Refresh и diff release-dev должны показать новый API image и другую ссылку hash ConfigMap. Web image остаётся прежним. Если diff включает stage или изменение Service порта, reader сначала объясняет, почему оно появилось. Promotion полезен именно ясным малым набором, который можно сопоставить с ожидаемым прикладным результатом.

Manual sync запускает переход, затем идёт наблюдение

Reader применяет release-dev и ждёт sync/health. Kubernetes rolling update может некоторое время держать старые и новые API экземпляры согласно своей стратегии. Совместимый контракт позволяет web работать в этот промежуток. У dev одна desired копия, но фактическое количество Pod во время обновления не обязано быть ровно одним каждую секунду.

После готовности открывается тот же локальный web маршрут. Ожидаемый /api/lessons содержит дополнительный gitops элемент и version два. Текст версии сам по себе не доказывает image происхождение, поэтому reader сопоставляет desired image, Pod контейнер и ответ. Пробы сообщают готовность процесса, но не проверяют смысл нового элемента каталога.

Если ошибка обнаружена только в прикладном содержимом, зелёное health не должно закрывать вопрос о пригодности релиза. Нужен явный результат reader проверки: соответствует ли каталог ожидаемому, сохраняется ли маршрут, не изменился ли контракт. Автор не запускал эти действия, поэтому источники курса не называют кандидат «успешно проверенным». Последующий promotion зависит от наблюдений самостоятельного прохода.

Stage получает тот же артефакт

После принятия кандидата reader переносит те же два release значения в gitops/overlays/stage/kustomization.yaml отдельным commit. Stage сохраняет своё GREETING и replicas два. Это продвижение одного образа api два с соответствующей конфигурацией, а не сборка отдельного «stage варианта» программы. Так расхождения среды остаются декларативными и видимыми.

Bundle снова публикует main. Release-stage get/diff покажет новый image и hash ConfigMap в ploshchadka-stage. Release-dev при этом уже соответствует версии два и не должен неожиданно откатываться. После отдельного stage sync ожидаются два готовых API экземпляра и web версии один. Пользовательский port-forward для stage нужен свой или последовательно переключённый адресный канал.

Один Git commit может хранить и dev, и stage состояние. Новый resolved commit для dev ещё не означает изменение его ресурсов: если path результат прежний, live может оставаться Synced. Это нормальная связь общей истории repository с отдельными Application paths. Поэтому reader смотрит не только commit SHA, но и фактический diff конкретного окружения.

Что не входит в promotion

Архив не создаёт CI pipeline, автоматическую проверку образа, внешнее stage окружение или production. Ручной перенос показывает прикладную механику GitOps и решение о выпуске. Если позднее добавить CI, оно должно построить один выбранный артефакт и обновить source по известным правилам, сохраняя историю намерения и разрешения владельцев.

APP_VERSION в ConfigMap остаётся параметром, а не источником бинарной идентичности. В рабочем проекте полезно встроить build revision в приложение и сопоставлять её с artifact digest. Такая доработка должна иметь реальные данные сборки; выдуманный digest в учебной статье не повысит воспроизводимость. Здесь reader знает исходники обеих версий и локальные теги своего прохода.

Секреты также не копируются из dev в stage через overlay. В обоих namespaces есть отдельная api-demo-secret bootstrap зависимость. Реальные значения могли бы различаться и управляться иным процессом. Promotion кода не даёт права получить все полномочия одного окружения в другом; именно поэтому source хранит ссылку, а содержание исключено из GitOps набора.

После этой главы выпуск имеет две осмысленные границы: кандидат применён в dev, затем тот же артефакт выбран для stage отдельным Git решением. Argo CD Kustomize обеспечивает построение source, а организация promotion принадлежит нашему проекту. Следующий урок разберёт обратный путь: оперативный rollback и долговременное исправление main должны быть согласованы.

Оглавление серии