Blue-green и canary
Тема дорожной карты · Backend разработчик
Blue-Green деплой — стратегия выпуска, устраняющая простои и снижающая риск деплоя за счёт поддержания двух идентичных продакшен-окружений — «синего» (текущего рабочего) и «зелёного» (новой версии) — с мгновенным переключением трафика между ними после проверки нового выпуска. В blue-green деплое зелёное окружение получает новый Docker-образ, собранный и опубликованный через CI/CD-пайплайн, проходит автоматизированные smoke-тесты и проверки работоспособности, и только после этого балансировщик нагрузки или селектор Kubernetes Service переключает 100% трафика с синего на зелёное. Поскольку синее окружение продолжает работать после переключения, откат неудачного выпуска происходит так же быстро, как обратное переключение трафика — без нового деплоя, — что делает blue-green деплой значительно безопаснее обновлений на месте для критически важных REST API. Blue-green деплои органично интегрируются с Kubernetes через такие инструменты, как Argo Rollouts или переключение переменных Helm chart, и с Infrastructure as Code (IaC) через управляемые Terraform целевые группы балансировщиков нагрузки на облачных платформах. Эта стратегия хорошо сочетается с дисциплиной миграций баз данных: изменения схемы должны быть обратно совместимыми (только аддитивными), чтобы и синяя, и зелёная версии бэкенд-сервиса могли работать с одними и теми же базами данных PostgreSQL или MySQL в период перехода.
Как это работает
Blue-green и canary включает CI/CD пайплайны, infrastructure as code, управление секретами, zero-downtime деплои и стратегию rollback. Современный стек: Git → CI (GitHub Actions, GitLab CI, Drone) собирает + тестирует + пушит container image; CD-пайплайн (ArgoCD, Flux или imperative Ansible) деплоит на staging; промоут в production гейтится ручным одобрением, автоматическими проверками или обоими. Секреты в vault (HashiCorp Vault, AWS Secrets Manager, Yandex Lockbox); никогда не в репо. Blue-green или rolling для zero-downtime.
Когда применять
Автоматизируйте деплои до любого масштабирования — ручной деплой это редко-правильный деплой. Immutable инфраструктура (пересобрать вместо патча на месте). Всегда тестированный rollback до forward-изменения. Для маленьких команд master + tag-based деплои (push tag → CI builds → CD deploys) бьют сложность Kubernetes на первый год.
Типичные ошибки
Ловушки Blue-green и canary: деплой без простого rollback (один плохой деплой = downtime + паника); общие production-секреты в .env-файлах в репо; "config drift" — production отличается от IaC из-за ручных правок; релиз вечером пятницы (Мёрфи отдыхает на выходных); не feature-flag'аете рискованные изменения (DB-записи откатить нельзя, флаг переключить можно).