Argo CD: Rollback revision и исправление Git

Версия два прошла dev и stage, но reader может обнаружить ошибку, требующую возвращения к первому API. В этой главе разберём два пути: применить прежнюю историю Argo CD для оперативного возврата и изменить Git main, чтобы дальнейший sync сохранял выбранное состояние. Результат — откат полного совместимого набора, который не отменяется следующим чтением источника.

Автор не выполнял rollback, Git revert или применение манифестов. Исторические ID появляются только после reader операций; в статье нет выдуманного номера готового релиза. Синтаксис оперативного действия сверён с официальным argocd app rollback. Конечный архив содержит обе версии исходников, но наличие старого образа в конкретном кластере ещё требует самостоятельной подготовки.

Возвращаем совместимый release набор

Первый выпуск использует image api один и APP_VERSION один. Второй — image два и параметр два. Если вернуть только image, ответ может продолжить показывать версию два из окружения. Если вернуть только ConfigMap параметр, новый код всё ещё содержит третий элемент каталога. Поэтому откат рассматривает совместимый набор источника, а не одну красивую строку номера.

Kustomize generator связывает конфигурацию с hash именем. При возврате прежних данных построенная ссылка Deployment снова соответствует прежнему ConfigMap содержимому. Старые объекты могут оставаться live без prune, однако source должен ясно описывать требуемые данные. Наличие старого ConfigMap в списке само по себе не переключает процесс на него.

Теги образов тоже должны оставаться доступными. История Argo CD хранит сведения о release source, но не слои собственного image. Если reader удалил api один из kind либо перезаписал тег другим кодом, rollback не создаст прежний артефакт. Поэтому регламент передачи сохраняет источник обеих версий и фиксирует, какие images фактически подготовлены в самостоятельной лаборатории.

История Argo CD отражает состоявшиеся применения

После нескольких sync reader может прочитать app history и увидеть реальные ID операций. Эти записи помогают выбрать прежнюю source revision. Номер history не равен Git SHA и не является универсальным номером курса. Другая лаборатория с другим порядком применений получит иные значения; копирование выдуманного ID из статьи могло бы выбрать неподходящий выпуск.

Будущий оперативный путь выглядит так. Команда rollback выполняется с фактическим ID, прочитанным самим reader; placeholder в описании нужно заменить осмысленно.

argocd app history release-stage
# После выбора реального ID прежнего совместимого выпуска:
argocd app rollback release-stage <HISTORY_ID>
argocd app wait release-stage --health --timeout 120

Операция возвращает выбранное историческое состояние приложения, но не редактирует working tree и main repository автоматически. Это принципиальная граница. Если main всё ещё желает версию два, следующий обычный sync по source может снова её применить. Поэтому оперативный возврат требует последующего согласования долгосрочного намерения. В показанной команде wait ожидается health, без требования sync: пока main остаётся на версии два, исторический вариант может закономерно отличаться от текущего желания. Старые hash ConfigMap также могут удерживать признак лишних ресурсов до осознанного prune.

В нашей Application automated отсутствует. Официальная политика автоматической синхронизации отдельно ограничивает rollback при включённой автоматизации. Reader не должен переносить ручную последовательность в неизвестную автонастройку без проверки. Если позднее automated появится, регламент отката потребуется пересмотреть вместе с её правилами.

Git откат сохраняет будущее намерение

Для долговременного возврата reader меняет stage overlay обратно на image один и APP_VERSION один либо делает Git revert определённого promotion commit, если он действительно содержит только нужное изменение. Затем создаётся новый commit, публикуется bundle, выполняются refresh/diff и manual sync release-stage. Main теперь явно желает прежний совместимый набор.

Новый commit возврата лучше объясняет историю, чем скрытое перемещение main назад с исчезновением последующих решений. Его сообщение связывает причину ошибки и выбранный release. Если после promotion другие поля уже изменены осмысленно, общий revert может отменить лишнее. Поэтому reader читает diff самого Git изменения, не считая любое «revert» автоматически точным восстановлением.

Dev может оставаться на версии два для разбора, пока stage возвращается к одной. Это нормальное различие overlays. Если решение требует вернуть оба, меняются оба paths отдельным осмысленным набором. Название Application в sync должно совпадать с выбранным окружением; одна операция release-stage не изменяет dev просто по факту общей base.

После публикации bundle repo-server должен разрешить новый main. Если source ещё показывает прежний commit, нужно выяснить, завершён ли импорт refs и refresh. Прямая правка live image через kubectl могла бы временно помочь, но оставила бы drift и не изменила долгосрочное желание. Восстановление считается согласованным только когда Git и live выражают выбранный результат.

Данные и секреты не откатываются по одной revision

Наш API читает константу каталога, поэтому версия один не требует миграции базы. Это упрощает учебный rollback. Для приложения с изменяемыми данными старый код может оказаться несовместим с уже изменённой схемой или содержимым. Возврат Deployment не возвращает внешнюю СУБД к прежнему состоянию; нужен отдельный план совместимости и восстановления.

Secret api-demo-secret находится вне GitOps набора. История Argo CD не вернёт его прежнее содержание автоматически. Если причина отказа в смене секретного параметра, возврат API source может не устранить проблему. Регламент должен назвать фактическую зависимость, владельца значения и способ создания нового процесса, который получит его.

Даже ConfigMap с постоянным именем в другом проекте мог бы сохранить новое содержание после возврата Deployment. Наш hash generator уменьшает неоднозначность конфигурации, но не решает любую внешнюю зависимость. Нельзя расширять конкретное свойство «Площадки» до обещания, что Git revision восстанавливает весь мир приложения.

Наблюдаем возврат на нескольких уровнях

После выбранного rollback reader читает sync/health, Pod images, готовность и пользовательский маршрут. Ожидаемый каталог версии один содержит два исходных элемента. Старые Pod могут ещё завершаться во время rolling update, поэтому мгновенный ответ случайного экземпляра не всегда отражает окончательный результат. Нужно дождаться подходящей готовности и понять состояние выбранного Service.

При Synced, но неверном каталоге исследуют фактический image, env и источник кода. При недоступном контейнере сначала проверяют наличие image и Secret. При прекращении port-forward восстанавливают временный канал, не считая это доказательством неудачного Git отката. Такая последовательность отделяет прикладную ошибку от транспорта локальной диагностики.

Теперь возврат версии имеет ясный смысл: выбрать прежний совместимый набор, временно или постоянно применить его, сохранить доступный артефакт и согласовать main. History полезна для оперативного решения, Git commit удерживает будущее намерение. Следующая глава разберёт удаление лишних ресурсов и полномочия: успешный откат не должен случайно очищать инфраструктуру или раскрывать реальные секреты.

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