Zero‑downtime деплой: стратегии Blue‑Green и Canary с использованием Ansible и Terraform для PHP‑ и Python‑приложений

Zero‑downtime деплой — это набор практик, позволяющих обновлять сервис без прерывания доступа пользователей. В статье рассматриваются две проверенные стратегии: Blue‑Green и Canary, а также их реализация с помощью Ansible и Terraform для типовых стеков PHP и Python.

Почему именно Blue‑Green и Canary?

Обе стратегии решают одну задачу — минимизировать риск при выкатывании новой версии. Blue‑Green полностью переключает трафик на новую среду, а Canary вводит изменения постепенно, позволяя собрать метрики и откатиться при необходимости.

Blue‑Green деплой

Схема:

Создаём две идентичные инфраструктурные группы: blue (текущая) и green (новая).
Разворачиваем новую версию в green при помощи Terraform.
Тестируем green в изолированном окружении.
Переключаем балансировщик (NGINX, HAProxy, AWS ALB) на green.
После подтверждения стабильности blue удаляется или переиспользуется для следующего релиза.

Пример Terraform‑модуля, создающего две среды:

module "app_blue" {
  source = "./modules/app"
  env    = "blue"
  vpc_id = var.vpc_id
}

module "app_green" {
  source = "./modules/app"
  env    = "green"
  vpc_id = var.vpc_id
}

Внутри модуля определяется набор EC2/Compute Engine, security‑group, IAM‑роли и т.д. Переключение трафика реализуется через изменение целевых групп в ALB:

resource "aws_lb_target_group_attachment" "blue" {
  target_group_arn = aws_lb_target_group.blue.arn
  target_id        = module.app_blue.instance_id
  port             = 80
}

resource "aws_lb_target_group_attachment" "green" {
  target_group_arn = aws_lb_target_group.green.arn
  target_id        = module.app_green.instance_id
  port             = 80
}

Для переключения достаточно изменить правило в aws_lb_listener_rule и применить terraform apply.

Canary деплой

Canary‑подход позволяет отправлять небольшую часть трафика (например, 5‑10 %) на новую версию и постепенно увеличивать её долю.

Создаём отдельный набор инстансов canary через Terraform.
Настраиваем балансировщик так, чтобы часть запросов направлялась в canary (weight‑based routing).
Собираем метрики (latency, error‑rate) с помощью Prometheus, Grafana, CloudWatch.
Если всё в порядке — увеличиваем вес до 100 % и выводим старые инстансы из эксплуатации.

Пример Terraform‑конфигурации для canary‑группы:

resource "aws_autoscaling_group" "canary" {
  name                      = "app-canary"
  max_size                  = 2
  min_size                  = 1
  desired_capacity          = 1
  launch_configuration      = aws_launch_configuration.app.id
  vpc_zone_identifier       = var.subnet_ids
  health_check_type         = "ELB"
  target_group_arns         = [aws_lb_target_group.canary.arn]
}

Настройка правила в ALB для weighted routing:

resource "aws_lb_listener_rule" "canary" {
  listener_arn = aws_lb_listener.http.arn
  priority     = 10

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.green.arn
    forward {
      target_group {
        arn    = aws_lb_target_group.green.arn
        weight = 90
      }
      target_group {
        arn    = aws_lb_target_group.canary.arn
        weight = 10
      }
    }
  }
  condition {
    host_header {
      values = ["example.com"]
    }
  }
}

Автоматизация конфигураций с Ansible

Ansible отвечает за подготовку окружения, деплой кода и пост‑деплойные проверки. Ниже – минимальный playbook, который работает одинаково для PHP‑ и Python‑приложений.

- name: Deploy application
  hosts: "{{ target_group }}"
  become: true
  vars:
    app_repo: "git@github.com:company/app.git"
    deploy_path: "/var/www/{{ app_name }}"
    python_venv: "/opt/venv/{{ app_name }}"
  tasks:
    - name: Ensure deploy directory exists
      file:
        path: "{{ deploy_path }}"
        state: directory
        owner: www-data
        group: www-data
        mode: "0755"

    - name: Pull latest code
      git:
        repo: "{{ app_repo }}"
        dest: "{{ deploy_path }}"
        version: "{{ git_branch }}"
        force: true

    - name: Install PHP dependencies (Composer)
      when: app_type == "php"
      composer:
        working_dir: "{{ deploy_path }}"
        command: install
        no_dev: true

    - name: Install Python dependencies (pip)
      when: app_type == "python"
      pip:
        requirements: "{{ deploy_path }}/requirements.txt"
        virtualenv: "{{ python_venv }}"
        virtualenv_python: python3

    - name: Restart service
      systemd:
        name: "{{ app_name }}"
        state: restarted
        enabled: true

    - name: Health check
      uri:
        url: "http://{{ inventory_hostname }}/health"
        status_code: 200
        timeout: 5
      register: health_check
      failed_when: health_check.status != 200

Playbook можно вызывать из CI/CD пайплайна после применения Terraform:

ansible-playbook -i inventory/green.ini deploy.yml \
  -e "target_group=green app_name=myapp app_type=php git_branch=release-1.2"

Полный CI/CD сценарий

# 1. Build образ Docker (если используется)
docker build -t registry.example.com/myapp:${CI_COMMIT_SHA} .

# 2. Push образ
docker push registry.example.com/myapp:${CI_COMMIT_SHA}

# 3. Terraform – создать/обновить green (или canary) среду
terraform init && terraform apply -auto-approve -var "image_tag=${CI_COMMIT_SHA}" -var "env=green"

# 4. Ansible – задеплоить код и выполнить smoke‑тесты
ansible-playbook -i inventory/green.ini deploy.yml \
  -e "target_group=green app_name=myapp app_type=python git_branch=main"

# 5. Переключить трафик (Blue‑Green) или увеличить вес (Canary)
terraform apply -auto-approve -target=aws_lb_listener_rule.canary

# 6. Мониторинг и автоматический откат при отклонении метрик
# (в реальном проекте – отдельный процесс, например, в GitLab CI)

Лучшие практики

Идемпотентные инфраструктурные изменения – всегда используйте Terraform state и remote backend.
Тесты на уровне инфраструктуры – проверяйте, что новые инстансы отвечают health‑check до переключения.
Версионирование конфигураций – храните Ansible playbooks и Terraform модули в Git.
Rollback‑планы – храните предыдущие AMI/Docker‑теги и автоматический скрипт отката.
Метрики и алерты – интегрируйте Prometheus/Grafana или CloudWatch для контроля Canary‑шагов.

Заключение

Комбинация Terraform и Ansible позволяет построить надёжный процесс Zero‑downtime деплоя как для монолитных PHP‑приложений, так и для микросервисов на Python. Выбор между Blue‑Green и Canary зависит от требований к рискам и скорости выпуска новых функций.

Услуги RybinskLab

RybinskLab предлагает полный цикл разработки и поддержки: проектирование архитектуры, написание инфраструктурного кода на Terraform, автоматизацию деплоя с Ansible, а также настройку мониторинга и CI/CD пайплайнов под ваши бизнес‑задачи. Свяжитесь с нами, чтобы вывести ваш продукт на уровень Zero‑downtime деплоя уже сегодня.