Сине-зелёное развёртывание

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Сине-зелёное развёртывание (англ. blue-green deployment) в программной инженерии — метод внесения изменений на веб-сервер, сервер приложений или баз данных путём поочерёдной смены рабочего и промежуточного серверов.

При сине-зелёном развёртывании поддерживаются два сервера: «синий» и «зелёный». В любой момент времени запросы обрабатывает только один сервер (например, тот, на который указывает DNS). К примеру, публичные запросы могут быть направлены на синий сервер, превращая его в рабочий, в то время как зелёный сервер становится промежуточным (staging), доступ к которому осуществляется только из частной сети. Изменения устанавливаются на неактивный сервер, который затем тестируется через частную сеть для проверки корректной работы изменений. После проверки неактивный сервер меняется местами с рабочим, что фактически делает развёрнутые изменения доступными для всех[1].

Этот метод развёртывания позволяет быстро выполнить откат к предыдущему состоянию, если что-то пойдёт не так. Откат достигается простым перенаправлением трафика на предыдущий рабочий сервер, всё ещё содержащий старую версию без изменений[2]. Дополнительное преимущество сине-зелёного метода — сокращение времени простоя сервера. Так как запросы мгновенно переключаются с одного сервера на другой, в идеале отсутствует период необработанных запросов[3].

Технику сине-зелёного развёртывания часто сравнивают с техникой канареечного релиза[3] и она имеет сходства с A/B-тестированием.

Дэн Норт и Джез Хамбл столкнулись с различиями между своими тестовыми средами и рабочей средой при работе с Oracle WebLogic Server для клиента примерно в 2005 году[4]. Чтобы обеспечить безопасное развёртывание, они внедрили метод, при котором новая версия приложения разворачивалась параллельно с работающей системой. Этот подход позволял проводить тщательное тестирование и легко выполнять откат в случае проблем. Команда сначала рассматривала возможность назвать эти среды A и B, но отказалась от этой идеи, чтобы избежать восприятия, будто одна из них основная, а другая — второстепенная. Вместо этого они выбрали названия на основе цветов, такие как синий, зелёный, оранжевый и жёлтый, в итоге используя только синий и зелёный, поскольку «двух было достаточно»[5]. Эта система именования была принята во время работы над первой книгой о непрерывной поставке, опубликованной в 2010 году[6], и впоследствии стала общепринятым термином в индустрии.

Преимущества и трудности

[править | править код]

Сине-зелёное развёртывание широко известно своей способностью сокращать время простоя во время обновлений приложений и минимизировать риск внесения дефектов в рабочую среду. Поддерживая две отдельные среды — синюю (текущую рабочую) и зелёную (с обновлённой версией) — можно легко переключать трафик между ними, гарантируя, что обновления разворачиваются без прерывания работы пользователей. Этот метод позволяет быстро выполнить откат в случае сбоя развёртывания, тем самым повышая общую отказоустойчивость системы и улучшая пользовательский опыт[7].

Хотя сине-зелёное развёртывание снижает риски при обновлениях, оно также требует дополнительных ресурсов, так как необходимо одновременно поддерживать две среды. Стоимость эксплуатации дублирующей инфраструктуры, даже временной, может быть непомерно высокой для небольших организаций. Кроме того, сложности могут представлять комплексные миграции баз данных, поскольку система должна обеспечивать согласованность данных между синей и зелёной средами. Решения этих проблем часто включают использование инструментов миграции баз данных, обеспечивающих обратную совместимость между средами[7].

Реализация

[править | править код]

Существует несколько подходов к реализации сине-зелёного развёртывания, каждый из которых предлагает разный уровень автоматизации и простоты использования в зависимости от платформы и доступных инструментов.

AWS CodeDeploy облегчает сине-зелёные развёртывания, автоматизируя весь процесс для таких сервисов, как Amazon EC2 и AWS Lambda. Сервис переключает трафик между старой (синей) и новой (зелёной) средой, минимизируя время простоя и обеспечивая плавный переход. AWS CodeDeploy также позволяет использовать хуки жизненного цикла событий, давая разработчикам возможность запускать тесты и шаги верификации перед направлением трафика на зелёную среду[7].

Пример конфигурации CodeDeploy[7]:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html
hooks:
  AfterInstall:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root

Команда для развёртывания[7]:

aws deploy create-deployment --application-name MyApp --deployment-group-name MyDeploymentGroup --s3-location bucket=my-bucket,key=my-app.zip,bundleType=zip

Kubernetes поддерживает сине-зелёные развёртывания с помощью своих встроенных возможностей сервисов. Используя несколько развёртываний и сервисов, Kubernetes позволяет операторам управлять маршрутизацией трафика между синей и зелёной средами с минимальным риском прерывания обслуживания. Инструменты, такие как ArgoCD или Spinnaker, дополнительно улучшают автоматизацию, интегрируя конвейеры развёртывания непосредственно с кластерами Kubernetes[8].

Google Cloud Deployment Manager

[править | править код]

Google Cloud предлагает возможности сине-зелёного развёртывания через Deployment Manager. Определяя ресурсы в декларативном формате, Deployment Manager позволяет пользователям создавать, обновлять и удалять ресурсы в рамках процесса сине-зелёного развёртывания. Как и AWS CodeDeploy, он минимизирует время простоя, переключая трафик со старой на новую среду после проведения необходимых тестов[9].

Настройка среды[10]:

  • Установите `gcloud` CLI или используйте Google Cloud Shell.
  • Установите ваш проект по умолчанию:
gcloud config set project <YOUR_PROJECT_ID>

Клонирование репозитория с примером[10]:

gcloud source repos clone copy-of-gcp-mig-simple
cd copy-of-gcp-mig-simple

Чтобы изменить конфигурацию, перейдите к файлу конфигурации (например, `infra/main.tfvars`) и обновите среду с синей на зелёную[10]:

sed -i'' -e 's/blue/green/g' infra/main.tfvars

Добавление, коммит и отправка изменений для запуска развёртывания[10]:

git add .
git commit -m "Promote green"
git push

Пример того, как может выглядеть файл `main.tfvars`[10]:

# main.tfvars
project_id = "<YOUR_PROJECT_ID>"
region = "us-central1"
zone = "us-central1-a"

# Настройки балансировщика нагрузки
blue_instance_group = "blue-instance-group"
green_instance_group = "green-instance-group"

# Настройки проверки работоспособности
health_check = {
  name                = "http-health-check"
  request_path        = "/"
  check_interval_sec  = 10
  timeout_sec         = 5
  healthy_threshold   = 2
  unhealthy_threshold = 2
}

Azure Container Apps

[править | править код]

Azure Container Apps предоставляет возможности сине-зелёного развёртывания с помощью ревизий приложений-контейнеров, весов трафика и меток ревизий. В этой модели развёртывания используются две идентичные среды, называемые «синей» и «зелёной». В синей среде размещается текущая стабильная версия приложения, а в зелёной — новая. После полного тестирования зелёной среды на неё направляется рабочий трафик, а синяя среда выводится из эксплуатации до следующего цикла развёртывания.

Для реализации сине-зелёного развёртывания вы создаёте ревизии приложений-контейнеров и назначаете веса трафика. Синей ревизии изначально назначается 100% трафика, в то время как зелёная разворачивается без рабочего трафика. После успешного тестирования зелёной ревизии трафик плавно переключается без простоя. Если в зелёной среде возникают проблемы, легко выполняется откат, направляя трафик обратно на синюю ревизию[11].

Создание приложения-контейнера с новой ревизией[11]:

az containerapp create --name $APP_NAME \
     --environment $APP_ENVIRONMENT_NAME \
     --resource-group $RESOURCE_GROUP \
     --image mcr.microsoft.com/k8se/samples/test-app:$BLUE_COMMIT_ID \
     --revision-suffix $BLUE_COMMIT_ID \
     --ingress external \
     --target-port 80 \
     --revisions-mode multiple

Развёртывание новой зелёной ревизии[11]:

az containerapp update --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --image mcr.microsoft.com/k8se/samples/test-app:$GREEN_COMMIT_ID \
  --revision-suffix $GREEN_COMMIT_ID \
  --set-env-vars REVISION_COMMIT_ID=$GREEN_COMMIT_ID

Переключение 100% рабочего трафика на зелёную ревизию[11]:

az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label-weight blue=0 green=100

Примечания

[править | править код]
  1. LaToza, Thomas. Deployment (англ.) (2019). Дата обращения: 14 января 2020. Архивировано 14 января 2020 года.
  2. Fowler, Martin. Blue Green Deployment (англ.) (1 марта 2010). Дата обращения: 14 января 2020. Архивировано 10 января 2020 года.
  3. 1 2 Posta, Christian. Blue-green Deployments, A/B Testing, and Canary Releases (англ.) (3 августа 2015). Дата обращения: 14 января 2020. Архивировано 30 марта 2018 года.
  4. Kuenzli, Stephen. Origin Story: The Blue-Green Deployment Method (англ.) (1 марта 2010). Дата обращения: 23 января 2024. Архивировано 9 июня 2023 года.
  5. Terhorst-North, Daniel. Blue-Green deployment (англ.) (1 марта 2010). Дата обращения: 23 января 2024.
  6. Humble, Jez. Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation / Jez Humble, David Farley. — Addison-Wesley, 2010. — ISBN 978-0-321-60191-9.
  7. 1 2 3 4 5 Blue-Green Deployment: Update Software Risk-Free - DZone (англ.). dzone.com. Дата обращения: 29 сентября 2024.
  8. Best practices for continuous integration and delivery to Google Kubernetes Engine. Google Cloud. Дата обращения: 29 сентября 2024.
  9. Reduce Deployment Risk with Blue-Green Deployments. Google Cloud. Дата обращения: 29 сентября 2024.
  10. 1 2 3 4 5 Deploy to Compute Engine | Cloud Build Documentation (англ.). Google Cloud. Дата обращения: 29 сентября 2024.
  11. 1 2 3 4 Blue-Green Deployment in Azure Container Apps. Microsoft Learn (27 июня 2023). Дата обращения: 29 сентября 2024.