Ваш CI/CD врёт вам.
“Deployment successful” не значит что в продакшене работает то, что вы задеплоили.
Увидел пост про ArgoCD. Автор объяснял с точки зрения безопасности - не надо раздавать kubeconfig, все через Git.
Правильно. Но я хочу обратить внимание на то, что ломается в три часа ночи.
Вопрос который мне задают: “Зачем ArgoCD? У нас Jenkins (Github Actions, GitlabCI, CircleCI, etc.) деплоит, работает же?”
Работает. А потом ты просыпаешься в три часа ночи и фиксишь срочно.
Представьте:
Push-based - это как работать над курсовой с другом через флешку. “Вот тебе курсовая_работа_v3_final_fix_last_checked.doc”. Он правит, отдаёт обратно. Потом ты что-то меняешь в своей копии. Потом он в своей. Через неделю у вас 5 версий файла, никто не помнит какая последняя, и в итоге сдаёте не ту.
Pull-based - это общий Google Doc. Один файл, одна правда. Кто-то напортачил локально - синхронизация вернёт как надо. История изменений всегда на месте.
В чём реальная разница:
Jenkins задеплоил. kubectl apply отработал с exit code 0. Билд зелёный. Красота.
Но:
- Кто-то руками поправил deployment в кластере? Jenkins не узнает.
- HPA изменил количество реплик? Jenkins не видит.
- Другой пайплайн перезаписал конфиг? Jenkins пофиг.
- Манифест в Git устарел? Jenkins применил что есть.
kubectl apply - fire and forget. Выстрелил и забыл.
ArgoCD живёт в кластере. Каждые 3 минуты сверяет: “То что в Git = то что в кластере?”
Нет? Фиксит.
Но главное не это.
Главное - кто контролирует ваш production?
Jenkins, GitHub Actions, GitLab CI - это внешние инструменты. Управляются кем-то еще. Их правила, их цены, их breaking changes.
Помните Google URL Shortener? Bitnami образы MongoDB? GitHub Actions меняли расценки?
Когда CI/CD интегрирован в ваш workflow напрямую - вы зависите от него как от критической инфраструктуры. Но не контролируете.
ArgoCD - это часть вашего кластера. Под вашим контролем. Как библиотека в коде, а не внешний сервис.
Мой опыт:
Я видел и использовал оба подхода в production.
Push-based ломается тихо. Всё зелёное, а продакшн лежит. Потому что то что задеплоили != то что реально работает.
Pull-based ломается громко, сразу. Drift detection показывает расхождение. Git log - полный аудит. Rollback = git revert.
Да, ArgoCD - это ещё один компонент. Порог вхождения, настройка, поддержка.
Но для Kubernetes в production - это может критически повысить надежность.
Не всегда, иногда это оверкилл, или ваше приложение не настолько зависит от git - тогда push-based норм.
А что обычно у вас ломает деплой ночью - ручные правки, конфликты пайплайнов или что-то другое?