Сценарии Ansible

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

Сценарии могут:

объявлять конфигурации
оркестрировать этапы любого ручного упорядоченного процесса на нескольких группах машин в определенном порядке
запускать задачи синхронно или асинхронно

Синтаксис сценария
Выполнение сценария
Ansible-Pull
Проверка сценариев
- ansible-lint

Синтаксис сценария

Сценарии записываются в формате YAML с минимальным синтаксисом. Если вы не знакомы с YAML, ознакомьтесь с нашим обзором синтаксиса YAML и рассмотрите возможность установки дополнения для вашего текстового редактора (см. Другие инструменты и программы), чтобы помочь вам писать чистый синтаксис YAML в ваших сценариях.

Сценарий состоит из одного или нескольких «игр» в упорядоченном списке. Термины «сценарий» и «игра» являются аналогиями из мира спорта. Каждая игра выполняет часть общей цели сценария, выполняя одну или несколько задач. Каждая задача вызывает модуль Ansible.

Выполнение сценария

Сценарий выполняется в порядке сверху вниз. Внутри каждой игры задачи также выполняются в порядке сверху вниз. Сценарии с несколькими «играми» могут оркестрировать развертывания на нескольких машинах, выполняя одну игру на веб-серверах, затем другую игру на серверах базы данных, затем третью игру на вашей сетевой инфраструктуре и так далее. Как минимум, каждая игра определяет две вещи:

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

Примечание

В Ansible 2.10 и более поздних версиях рекомендуется использовать полное имя коллекции в ваших сценариях, чтобы обеспечить правильный выбор модуля, так как несколько коллекций могут содержать модули с одинаковым именем (например, user). См. Использование коллекций в сценарии.

В этом примере первая игра ориентирована на веб-серверы, вторая игра — на серверы базы данных.

---
- name: Update web servers
  hosts: webservers
  remote_user: root

  tasks:
  - name: Ensure apache is at the latest version
    ansible.builtin.yum:
      name: httpd
      state: latest

  - name: Write the apache config file
    ansible.builtin.template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

- name: Update db servers
  hosts: databases
  remote_user: root

  tasks:
  - name: Ensure postgresql is at the latest version
    ansible.builtin.yum:
      name: postgresql
      state: latest

  - name: Ensure that postgresql is started
    ansible.builtin.service:
      name: postgresql
      state: started

Ваш сценарий может содержать больше, чем просто строку hosts и задачи. Например, сценарий выше устанавливает remote_user для каждой игры. Это пользовательская учетная запись для подключения SSH. Вы можете добавить другие Ключевые слова сценария на уровне сценария, игры или задачи, чтобы повлиять на поведение Ansible. Ключевые слова сценария могут управлять плагином подключения, использовать ли эскалацию привилегий, как обрабатывать ошибки и многое другое. Для поддержки различных сред Ansible позволяет устанавливать многие из этих параметров в качестве флагов командной строки, в вашей конфигурации Ansible или в вашем инвентаре. Знание правил приоритетов для этих источников данных поможет вам при расширении вашей экосистемы Ansible.

Выполнение задач

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

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

Желаемое состояние и идемпотентность

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

Запуск сценариев

Для запуска вашего сценария используйте команду ansible-playbook.

ansible-playbook playbook.yml -f 10

Используйте флаг --verbose при запуске сценария, чтобы увидеть подробные данные как об успешных, так и об неудачных модулях.

Запуск сценариев в режиме проверки

Режим проверки Ansible позволяет вам выполнить сценарий без внесения каких-либо изменений в ваши системы. Вы можете использовать режим проверки для тестирования сценариев перед их внедрением в производственную среду.

Для запуска сценария в режиме проверки вы можете передать флаг -C или --check команде ansible-playbook:

ansible-playbook --check playbook.yaml

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

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

Ansible-Pull

Если вы хотите изменить архитектуру Ansible, чтобы узлы обратились к центральному расположению, а не извлекали конфигурацию из него, вы можете это сделать.

ansible-pull — это небольшой скрипт, который извлечет репозиторий инструкций по конфигурации из git и затем выполнит ansible-playbook с этим содержимым.

Предполагая, что вы настраиваете балансировку нагрузки для своего места проверки, ansible-pull масштабируется практически до бесконечности.

Запустите ansible-pull --help для получения подробной информации.

Проверка плейбуков

Вы можете проверить свои плейбуки, чтобы выявить синтаксические ошибки и другие проблемы до их запуска. Команда ansible-playbook предлагает несколько вариантов проверки, включая --check, --diff, --list-hosts, --list-tasks и --syntax-check. Инструменты для проверки плейбуков описывает другие инструменты для проверки и тестирования плейбуков.

ansible-lint

Вы можете использовать ansible-lint для получения подробных, специфичных для Ansible, отзывов о ваших плейбуках перед их выполнением. Например, если вы запустите ansible-lint на плейбуке под названием verify-apache.yml в верхней части этой страницы, вы получите следующие результаты:

$ ansible-lint verify-apache.yml
[403] Package installs should not use latest
verify-apache.yml:8
Task/Handler: ensure apache is at the latest version

Страница стандартных правил ansible-lint описывает каждую ошибку. Для [403] рекомендуемое исправление — изменить state: latest на state: present в плейбуке.

См. также

ansible-lint: Узнайте, как проверить синтаксис Ansible Playbooks
YAML Синтаксис: Узнайте о синтаксисе YAML
Общие советы: Советы по управлению плейбуками в реальных условиях
Индекс коллекций: Просмотрите существующие коллекции, модули и плагины
Разрабатывать модуль?: Научитесь расширять Ansible, написав собственные модули
Шаблоны: нацеливание на хосты и группы: Узнайте, как выбирать хосты
Связь: Есть вопросы? Нужна помощь? Хотите поделиться своими идеями? Посетите руководство по коммуникации Ansible

© 2012–2018 Michael DeHaan
© 2018–2024 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html