Откат релиза в Argo CD: Git revert и включённая автосинхронизация

После релиза выросло число ошибок, и команда решила вернуть прошлую версию API. В live можно изменить image вручную, но Git всё ещё указывает на новый релиз. При следующей синхронизации он вернётся; selfHeal может ускорить это. Для устойчивого возврата нужно изменить желаемое состояние либо осознанно приостановить управляющую автоматизацию.

Записываем, что именно требуется вернуть

argocd app get demo-api --refresh
argocd app history demo-api
argocd app diff demo-api
kubectl -n argocd get application demo-api -o yaml

Сохраните текущий commit, предыдущую успешную ревизию, параметры Helm и список источников. Старая ревизия Git и старое состояние приложения могут различаться, если image tag перемещался или параметр был переопределён в Application. Перед решением проверьте фактический артефакт и изменения конфигурации. История Sync показывает операции, но не автоматически доказывает работоспособность выбранной версии сейчас.

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

Возвращаем желаемое состояние через Git

Когда приложение отслеживает branch и плохое изменение изолировано одним commit, новый revert-commit сохраняет историю и возвращает выбранные изменения. Сначала выполните процедуру в локальном репозитории конфигурации. Команды ниже подготавливают исправление для ревью и не отправляют его в remote:

git status --short
git show BAD_COMMIT
git revert --no-commit BAD_COMMIT
git diff --cached

Замените BAD_COMMIT проверенным идентификатором. Рабочее дерево должно быть подготовлено к операции. Для merge-commit требуется отдельное решение о mainline; без понимания состава merge не выбирайте параметр наугад. --no-commit позволяет изучить результат до создания нового commit. Если плохой релиз включал несколько несвязанных изменений, точечное исправление image и конфигурации может быть понятнее полного revert.

Проверьте рендер желаемых манифестов, совместимость ссылок на Secret/ConfigMap и наличие старого образа в registry. После принятого в команде review создайте и отправьте исправляющий commit. При auto-sync Argo CD применит новую желаемую ревизию, когда это разрешено политиками. Sync window, AppProject и ошибки генерации могут задержать применение; появление revert в Git ещё не означает возврат работающего трафика.

Чем отличается rollback из истории

Операция rollback Argo CD использует выбранную историческую запись, но не выполняется при включённой автоматической синхронизации. Если команда выбирает этот путь, сначала требуется управляемо отключить auto-sync. Для ApplicationSet это изменение должно быть выражено в управляющем шаблоне или разрешённом исключении; ручное переключение Application может быть возвращено контроллером.

Даже после временного исторического rollback Git нужно согласовать с решением до повторного включения auto-sync. Иначе текущая ветка снова задаст неудачный релиз. При multi-source проверяйте все источники и параметры: возврат одного revision может оставить несовместимую конфигурацию другого. Процедура должна явно говорить, какой набор считается согласованным.

Проверяем восстановление сервиса

argocd app get demo-api --refresh
argocd app diff demo-api
kubectl -n demo rollout status deployment/api --timeout=180s
kubectl -n demo get pods -l app=api -o wide

После применения проверьте фактический image новых Pod и исходный бизнес-запрос, на котором обнаружили сбой. Посмотрите фоновые workers, очередь и внешние интеграции: старый HTTP-обработчик может быть исправен, а новое сообщение уже лежать в несовместимом формате. Измерьте, вернулись ли ошибки и задержки к принятому уровню, вместо завершения проверки на статусе Synced.

Сохраните исправляющий commit, фактический артефакт и результат проверки данных. Если auto-sync временно выключали, укажите условие и владельца его включения. Такой откат оставляет согласованное состояние, которое переживёт следующий reconcile, и объясняет, какие последствия релиза были исправлены, а какие требуют отдельной работы.

Ещё по теме

• Argo CD и Helm: где искать values, которые реально попали в релиз
• Prune и selfHeal в Argo CD: какие изменения они исправляют

Продолжить изучение

Хотите выстроить доставку изменений из Git в кластер? Синхронизация, окружения и восстановление после неудачного релиза — темы программы «Argo CD и GitOps: деплой в Kubernetes».