Освоение многоэтапных развертываний с помощью последовательных плейбуков Ansible

Многоэтапные развертывания Ansible становятся необходимыми, когда «скопировать файлы и перезапустить службу» уже недостаточно. Настоящее развертывание может потребовать миграции базы данных, изменения функционального флага, развертывания пакета, перезагрузки службы, проверки работоспособности и пути отката в случае сбоя новой версии. Если все это находится в одном большом плейбуке с нечеткими границами, каждый неудачный развертывание превращается в упражнение по чтению.

Последовательные плейбуки дают каждому этапу четкую задачу. Вы можете запускать их из конвейера CI/CD, AWX, Ansible Automation Platform или простого скрипта оболочки. Важна не программа, нажимающая кнопку. Важно то, что развертывание имеет порядок, каждый этап можно безопасно повторить, а обработка сбоев явная.

Зачем нужны последовательные плейбуки для многоэтапных развертываний?

Развертывание приложения часто включает в себя нечто большее, чем просто копирование файлов. Вам может потребоваться:

Подготовить среду: Создать каталоги, установить разрешения, установить зависимости.
Обновить базу данных: Выполнить миграции схемы, заполнить начальные данные.
Развернуть код приложения: Перенести новые версии кода, перезапустить службы.
Настроить службы: Обновить конфигурации приложений, перезагрузить демоны.
Выполнить проверки после развертывания: Запустить дымовые тесты, проверить доступность служб.

Последовательность имеет значение, потому что одни операции легко откатить, а другие — нет. Откат символической ссылки на предыдущий релиз обычно прост. Откат разрушительной миграции базы данных может быть невозможен. Это различие должно формировать план развертывания до того, как кто-либо напишет YAML.

Разделение на отдельные последовательные плейбуки дает несколько преимуществ:

Модульность: Каждый плейбук фокусируется на одном этапе, что упрощает их понимание, поддержку и повторное использование.
Читаемость: Сложная логика разбивается на управляемые части.
Контроль: Вы можете выполнять определенные этапы независимо или как часть более крупного рабочего процесса.
Изоляция ошибок: Если сбой происходит на одном этапе, легче определить причину и откатить конкретные изменения, не затрагивая другие части развертывания.
Идемпотентность: Хорошо написанные плейбуки по своей сути идемпотентны, то есть их многократный запуск дает тот же эффект, что и однократный. Это важно для безопасных повторных попыток.

Есть компромисс. Отдельные плейбуки добавляют работу по оркестрации. Переменные, артефакты и статус могут перемещаться от одного этапа к другому. Для небольшого внутреннего сервиса может быть достаточно одного плейбука с тегированными блоками. Для внешнего приложения с миграциями и требованиями к откату дополнительная структура обычно окупается.

Проектирование рабочего процесса многоэтапного развертывания

Прежде чем писать какой-либо код Ansible, спланируйте этапы развертывания. Определите логические шаги, их зависимости и порядок выполнения. Типичный рабочий процесс может выглядеть так:

Проверки перед развертыванием: Убедитесь, что целевая среда готова.
Миграция базы данных: Примените необходимые изменения схемы базы данных.
Развертывание приложения: Разверните новую версию кода приложения.
Перезапуск/перезагрузка службы: Запустите службы приложения с новым кодом.
Проверка после развертывания: Запустите тесты, чтобы подтвердить успешность развертывания.

Для каждого этапа определите, какие задачи Ansible необходимы и какой плейбук будет их содержать.

Также решите, каким этапам разрешено изменять состояние продакшена. Плейбук дымового теста не должен незаметно исправлять конфигурацию. Плейбук предварительной проверки не должен устанавливать отсутствующие пакеты, если это явно не является частью контракта развертывания. Разделение проверок только для чтения и изменяющих шагов делает рабочий процесс более надежным.

Вот практичная структура каталогов:

deploy/
  inventories/
    staging.ini
    production.ini
  group_vars/
    all.yml
    production.yml
  playbooks/
    00-preflight.yml
    01-migrate-db.yml
    02-deploy-app.yml
    03-reload-services.yml
    04-smoke-test.yml
    rollback-app.yml

Числа не являются магией. Они просто делают порядок видимым в списках файлов и журналах CI.

Выполнение плейбуков последовательно

Ansible предоставляет простой способ запускать плейбуки один за другим с помощью команд --playbook-dir и ansible-playbook. Самый простой метод — объединить команды в вашем конвейере CI/CD или в командной строке.

Предположим, у вас есть следующие файлы плейбуков:

01-database-migration.yml
02-deploy-application.yml
03-restart-services.yml
04-smoke-tests.yml

Вы можете выполнить их последовательно следующим образом:

ansible-playbook -i inventory.ini 01-database-migration.yml
ansible-playbook -i inventory.ini 02-deploy-application.yml
ansible-playbook -i inventory.ini 03-restart-services.yml
ansible-playbook -i inventory.ini 04-smoke-tests.yml

На практике оберните эту последовательность так, чтобы неудачный этап останавливал конвейер:

set -euo pipefail

ansible-playbook -i inventories/production.ini playbooks/00-preflight.yml
ansible-playbook -i inventories/production.ini playbooks/01-migrate-db.yml
ansible-playbook -i inventories/production.ini playbooks/02-deploy-app.yml
ansible-playbook -i inventories/production.ini playbooks/03-reload-services.yml
ansible-playbook -i inventories/production.ini playbooks/04-smoke-test.yml

set -e сам по себе не является стратегией развертывания, но он предотвращает худшую ошибку: продолжение после неудачного этапа, как будто ничего не произошло. Системы CI обычно предоставляют собственное поведение при сбое, но та же идея применима.

Использование `ansible-playbook --skip-tags` или `--limit`

В более сложных сценариях вы можете объединить несколько логических шагов в один плейбук, но использовать теги для управления выполнением. Однако для настоящего многоэтапного разделения обычно предпочитают отдельные плейбуки. Если вы хотите запустить подмножество плейбуков или пропустить некоторые, вы можете использовать аргументы командной строки.

Пропуск плейбука: Если 03-restart-services.yml не удается из-за временной проблемы со службой, вы можете повторно запустить только этот этап после устранения причины. Не пропускайте этапы вслепую, когда более ранние этапы создают артефакты или состояние, от которых зависят более поздние этапы.

Ограничение конкретным этапом: Вы также можете ограничить выполнение конкретным хостом или группой с помощью флага --limit, что может быть полезно для тестирования.

Для поэтапных развертываний --limit также может уменьшить радиус поражения:

ansible-playbook -i inventories/production.ini playbooks/02-deploy-app.yml --limit web_canary

Запустите развертывание на одном хосте или одной небольшой группе, проверьте его, затем продолжите на остальной части парка. Это особенно полезно, когда ваш балансировщик нагрузки поддерживает отключение хостов перед перезагрузкой или перезапуском.

Включение обработки ошибок и стратегий отката

Надежные развертывания требуют плана на случай, если что-то пойдет не так.

`ignore_errors` и `failed_when`

По умолчанию Ansible останавливает выполнение, если задача не удалась. Вы можете управлять этим поведением:

ignore_errors: true: Позволяет плейбуку продолжить выполнение, даже если задача не удалась. Используйте это с осторожностью, обычно для некритичных задач или когда у вас есть последующая задача для очистки или компенсации.
failed_when:: Определите пользовательские условия, при которых задача должна считаться неудачной. Это полезно для обработки ожидаемых некритичных ошибок или проверки определенных результатов.

- name: Проверить статус службы (потенциально некритично)
  command: systemctl status myapp
  register: service_status
  ignore_errors: true

- name: Завершить ошибкой, если служба не активна
  fail:
    msg: "Служба myapp не запущена!"
  when: "service_status.rc != 0"

Используйте ignore_errors экономно. Часто лучше зарегистрировать результат и принять четкое решение. Журнал развертывания, полный игнорируемых ошибок, учит людей переставать читать сообщения об ошибках.

Для команд предпочитайте специально созданные модули, когда они существуют. Например, используйте ansible.builtin.service, ansible.builtin.systemd, ansible.builtin.copy, ansible.builtin.template и модули пакетов вместо вызова оболочки. Модули обычно обеспечивают лучшую идемпотентность и более четкие состояния изменений и сбоев.

Плейбуки отката

Для критических развертываний создайте специальные плейбуки отката. Эти плейбуки должны быть разработаны для отмены изменений, внесенных соответствующими плейбуками развертывания.

01-database-migration-rollback.yml: Отменяет изменения схемы.
02-deploy-application-rollback.yml: Развертывает предыдущую версию приложения или восстанавливает резервную копию.
03-restart-services-rollback.yml: Перезапускает службы в их предыдущем состоянии.

Откат базы данных требует особого внимания. Некоторые миграции невозможно безопасно отменить после того, как записи начали использовать новую схему. Более безопасным шаблоном часто является расширение и сжатие: добавьте обратно совместимые изменения схемы, разверните код приложения, который может работать как со старой, так и с новой структурой, при необходимости заполните данные, затем удалите старые столбцы или поля в более позднем развертывании.

При такой модели откат обычно означает откат кода приложения и оставление совместимой схемы на месте, а не попытку отменить рискованное изменение базы данных в условиях стресса.

Пример триггера отката: В вашем конвейере CI/CD, если плейбук 04-smoke-tests.yml не удается, вы должны запустить выполнение плейбуков отката в обратном порядке.

# Если 04-smoke-tests.yml не удается:
ansible-playbook -i inventory.ini 03-restart-services-rollback.yml
ansible-playbook -i inventory.ini 02-deploy-application-rollback.yml
ansible-playbook -i inventory.ini 01-database-migration-rollback.yml

Использование `block`, `rescue` и `always`

Конструкции Ansible block, rescue и always предоставляют более структурированный способ обработки ошибок в рамках одного плейбука. Хотя они не предназначены для последовательности между плейбуками, они отлично подходят для инкапсуляции серии задач, которые могут завершиться ошибкой, и определения того, что делать в случае сбоя.

- block:
    - name: Развернуть новый код приложения
      copy:
        src: /path/to/new/app/
        dest: /var/www/myapp/

    - name: Перезапустить службу приложения
      service:
        name: myapp
        state: restarted

  rescue:
    - name: Попытка вернуться к предыдущей версии
      copy:
        src: /path/to/old/app/
        dest: /var/www/myapp/

    - name: Перезапустить службу приложения после отката
      service:
        name: myapp
        state: restarted

  always:
    - name: Зарегистрировать попытку развертывания
      debug:
        msg: "Попытка развертывания завершена."

Этот подход полезен для группировки связанных задач в рамках одного плейбука этапа развертывания.

Для отката между плейбуками позвольте оркестратору принять решение. Конвейер CI может запускать плейбуки отката только в случае сбоя более позднего этапа. Рабочие процессы AWX могут визуально моделировать те же ветви успеха и сбоя. Сделайте команду отката скучной и отрепетированной.

Передача состояния релиза между этапами

Последовательным плейбукам часто требуется общий идентификатор релиза. Например, этапу развертывания нужно знать, какой артефакт устанавливать, дымовому тесту нужно знать, какую версию ожидать, а откату нужно знать предыдущую версию.

Передавайте это состояние явно:

ansible-playbook -i inventories/production.ini playbooks/02-deploy-app.yml \
  -e release_version=2026.05.24.3 \
  -e artifact_url=https://artifacts.example.com/myapp/2026.05.24.3.tar.gz

Внутри плейбука запишите, что изменилось:

- name: Записать маркер текущего релиза
  ansible.builtin.copy:
    dest: /opt/myapp/current-release.txt
    content: "{{ release_version }}\n"
    owner: root
    group: root
    mode: "0644"

Этот маркер помогает во время инцидентов. Когда кто-то подключается по SSH к хосту, он может увидеть, какую версию, по мнению хоста, он запускает. Вы также можете настроить плейбук дымового теста на чтение маркера и сравнение его с ожидаемым релизом.

Дополнительные соображения

Управление состоянием между плейбуками

Иногда задача в одном плейбуке должна сообщить другому плейбуку о своем результате. Вы можете добиться этого с помощью:

Кэширования фактов: Если кэширование фактов включено, факты, собранные одним плейбуком, могут быть доступны последующим, запущенным в рамках того же сеанса Ansible.
Временных файлов/баз данных: Записывайте критическую информацию о статусе или выходные данные во временный файл или специальную таблицу статусов, которые могут читать последующие плейбуки.

Предпочитайте явное состояние скрытому. Кэширование фактов может быть полезным, но оно также может сбивать с толку, когда значения устарели или когда у одного исполнителя кэш включен, а у другого нет. Файлы релизов, метаданные артефактов, переменные CI и записи развертываний легче проверять.

Инструменты управления версиями и оркестрации

Для сложных оркестраций рассмотрите возможность интеграции ваших последовательных плейбуков Ansible в инструмент более высокого уровня:

Конвейеры CI/CD: Такие инструменты, как Jenkins, GitLab CI, GitHub Actions или CircleCI, отлично подходят для определения и запуска многоэтапных развертываний. Вы определяете последовательность команд ansible-playbook в конфигурации конвейера.
Ansible Tower/AWX: Для оркестрации корпоративного уровня Ansible Tower (теперь Automation Platform) или его аналог с открытым исходным кодом AWX предоставляет надежный пользовательский интерфейс для планирования, мониторинга и управления сложными шаблонами заданий, которые могут объединять несколько плейбуков.

Если несколько человек развертывают одну и ту же систему, централизованная оркестрация становится не столько вопросом удобства, сколько контроля. Она обеспечивает согласованные инвентаризации, учетные данные, журналы аудита, утверждения и видимую историю того, какой этап не удался. Эти детали имеют значение во время инцидента на продакшене.

Тегирование для детального контроля

Хотя мы выступаем за отдельные плейбуки для разных этапов, вы также можете использовать теги внутри плейбуков. Если у вас очень большой плейбук для одного этапа (например, миграция базы данных), вы можете пометить определенные задачи и запускать только их с помощью ansible-playbook --tags <имя_тега>.

Это скорее о детальном контроле внутри этапа, а не о последовательности между этапами.

Лучшие практики для многоэтапных развертываний

Держите плейбуки сфокусированными: Каждый плейбук должен хорошо делать одно дело (например, миграция базы данных, развертывание приложения).
Называйте плейбуки понятно: Используйте соглашение об именах, отражающее этап и порядок (например, 01-, 02-).
Реализуйте идемпотентность: Убедитесь, что все задачи идемпотентны, чтобы обеспечить безопасные повторные попытки.
Тестируйте откаты: Регулярно тестируйте процедуры отката, чтобы убедиться, что они работают должным образом.
Используйте систему контроля версий: Храните все свои плейбуки и файлы инвентаризации в системе контроля версий (например, Git).
Автоматизируйте оркестрацию: Используйте конвейеры CI/CD или такие инструменты, как Ansible Tower/AWX, для автоматизации выполнения ваших последовательных плейбуков.
Документируйте свой рабочий процесс: Четко документируйте этапы, их назначение, зависимости и процедуры отката.
Делайте дымовые тесты реальными: Проверяйте фактическую конечную точку, путь входа, обработчик очереди или фоновую задачу, которые имеют значение. Простая проверка процесса недостаточна.
Защищайте инвентаризации продакшена: Используйте отдельные инвентаризации и учетные данные для промежуточной среды и продакшена. Опечатка в --limit не должна развертывать не в том месте.
Используйте последовательное развертывание, когда это возможно: serial позволяет обновлять несколько хостов за раз и останавливаться до того, как будет затронут весь парк.

- name: Постепенное развертывание приложения
  hosts: web
  serial: 2
  tasks:
    - name: Установить релиз
      ansible.builtin.unarchive:
        src: "{{ artifact_path }}"
        dest: /opt/myapp/releases/{{ release_version }}
        remote_src: true

С serial Ansible обрабатывает хосты партиями. Комбинируйте это с отключением балансировщика нагрузки, если ваше приложение не может быть перезапущено без потери активных запросов.

Конкретный поток развертывания

Безопасное развертывание Ansible для веб-приложения может выглядеть так:

00-preflight.yml проверяет дисковое пространство, подтверждает существование целевого релиза, проверяет подключение к базе данных и убеждается, что хосты находятся в ожидаемой среде. Он не изменяет систему.

01-migrate-db.yml выполняет только обратно совместимые миграции. Он записывает версию миграции и завершается ошибкой, если база данных уже опережает запрошенный релиз.

02-deploy-app.yml загружает артефакт, распаковывает его в каталог релиза с версией, шаблонизирует конфигурацию и обновляет символическую ссылку current. Он еще не перезапускает службы.

03-reload-services.yml отключает каждый хост от балансировщика нагрузки, перезагружает или перезапускает службу, ожидает локальную конечную точку работоспособности, а затем возвращает хост в обслуживание.

04-smoke-test.yml вызывает публичную конечную точку по тому же пути, что и пользователи. Он проверяет тело ответа или конечную точку версии, а не просто 200 со страницы по умолчанию балансировщика нагрузки.

Этот поток медленнее, чем перезапуск одной командой. Но о нем гораздо легче рассуждать, когда развертывание не удается на полпути.

Привычка, которая заставляет это работать

Последовательные плейбуки Ansible работают лучше всего, когда каждый из них имеет узкий контракт: что он ожидает, что он изменяет, как он доказывает успех и что делать, если он не удается. Этот контракт важнее количества файлов YAML.

Начните с этапов, которые отражают ваш реальный риск: предварительная проверка, миграция, развертывание, перезагрузка, дымовой тест, откат. Держите команды скучными. Тестируйте откат до того, как он понадобится. Когда развертывание ломается, вы должны быть в состоянии указать на конкретный этап, который не удался, и решить следующий шаг без перечитывания всего дерева автоматизации.