Содержимое
GitOps без боли: Continuous Promotion в Kubernetes 🚀 Одна из самых сложных частей CI/CD в Kubernetes - это promotion между окружениями: dev → stage → prod. Все умеют “задеплоить в dev”, но дальше начинается хаос: - кто и когда двигает релиз в staging? - как не сломать прод? - как избежать ручных кнопок и «перекинь тег в чате»? Решение - Continuous Promotion по GitOps. Что это значит Promotion - это не “новый деплой”, а перевод уже собранного релиза на следующий этап. И в GitOps это делается правильно: ✅ *Git = единственный источник правды* ✅ каждый переход окружения - это коммит/PR ✅ Argo CD (или Flux) просто синхронизирует кластер с репо ✅ релиз продвигается автоматически, когда проходят проверки Как выглядит пайплайн 1) CI собирает образ и пушит в registry 2) Обновляется манифест (tag/digest) в репозитории окружения dev 3) После тестов создаётся PR на stage 4) После approval/валидаторов PR мерджится 5) Argo CD подтягивает изменения → stage обновлён 6) То же самое для prod Какие инструменты обычно используют - Argo CD - синхронизация состояния кластера с Git - Kargo (Akuity) - управление promotion (когда/как переводить релиз) - Helm/Kustomize - упаковка релизов под окружения Почему это топ-подход 🔥 нет ручных “перекинь версию” 🔥 история релизов всегда в Git 🔥 откаты = обычный revert 🔥 можно встроить правила: security checks, e2e, approvals 🔥 идеально для больших команд и микросервисов Вывод Если ты хочешь настоящий production GitOps, то деплой - это только половина. Вторая половина - promotion между окружениями, и она должна быть: - декларативной - автоматизированной - и воспроизводимой через Git. Это тот случай, когда GitOps реально превращается в систему, а не в модное слово. https://piotrminkowski.com/2025/01/14/continuous-promotion-on-kubernetes-with-gitops/