Spec-Zone.ru › Ansible 2.11

Вступление в Playbooks

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

Playbooks могут:

  • заявлять конфигурации
  • оркестрировать шаги любого ручного упорядоченного процесса на нескольких группах машин в определенном порядке
  • запускать задачи синхронно или асинхронно
  • Синтаксис Playbook
  • Исполнение Playbook

    • Исполнение задач
    • Желаемое состояние и «идемпотентность»
    • Запуск playbooks
  • Ansible-Pull
  • Проверка playbooks

    • ansible-lint

Синтаксис Playbook

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

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

Исполнение Playbook

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

  • управляемые узлы-цели с помощью шаблона
  • по крайней мере, одну задачу для выполнения

Примечание

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

В этом примере первый play нацелен на веб-серверы; второй play нацелен на серверы базы данных:

---
- 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

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

Исполнение задач

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

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

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

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

Запуск playbooks

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

ansible-playbook playbook.yml -f 10

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

Ansible-Pull

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

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

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

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

Также существует удачный playbook, который настраивает ansible-pull через crontab из режима отправки.

Проверка playbooks

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

ansible-lint

Вы можете использовать ansible-lint для получения подробной информации об Ansible о ваших playbooks перед их выполнением. Например, если вы запустите ansible-lint на playbook с названием 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 в playbook.

См. также

ansible-lint

Узнайте, как проверить синтаксис Ansible Playbooks

Синтаксис YAML

Узнайте о синтаксисе YAML

Советы и хитрости

Советы по управлению playbooks в реальном мире

Список коллекций

Просмотрите существующие коллекции, модули и плагины

Разрабатывать модуль?

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

Шаблоны: выбор узлов и групп

Узнайте о выборе узлов

Директория примеров GitHub

Полные примеры playbook, end-to-end

Список рассылки

Вопросы? Помощь? Идеи? Заходите на Google Groups

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

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API