Не усложняйте

По возможности делайте всё просто.

Используйте расширенные возможности только при необходимости и выбирайте ту, которая лучше всего соответствует вашему сценарию использования. Например, вам, вероятно, не понадобятся одновременно vars, vars_files, vars_prompt и --extra-vars, да ещё и внешний файл инвентаризации.

Если что-то кажется сложным, скорее всего, так оно и есть. Потратьте время на поиск более простого решения.

Используйте систему контроля версий

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

Настройте вывод CLI

Вы можете изменить вывод команд Ansible CLI с помощью плагинов обратного вызова.

Избегайте содержимого, зависящего от конфигурации

Чтобы ваш проект автоматизации было легко понимать, изменять и передавать другим, избегайте содержимого, зависящего от конфигурации. Например, вместо того чтобы использовать ansible.cfg в качестве корня проекта, можно применять магические переменные, такие как playbook_dir или role_name, чтобы определять пути относительно известных расположений в каталоге проекта. Это поможет сделать содержимое автоматизации гибким, повторно используемым и простым в обслуживании. Дополнительные сведения см. в разделе специальные переменные.

Используйте пробелы

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

Всегда задавайте имена для плей, задач и блоков

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

Всегда указывайте состояние

Для многих модулей параметр state является необязательным.

В разных модулях для state используются разные значения по умолчанию, а некоторые модули поддерживают несколько значений state. Явное указание state: present или state: absent делает плейбуки и роли понятнее.

Используйте комментарии

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

Используйте полностью квалифицированные имена коллекций

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

Для встроенных модулей и плагинов используйте в качестве префикса имя коллекции ansible.builtin, например ansible.builtin.copy.

Используйте динамическую инвентаризацию для облачных сред

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

Группируйте инвентаризацию по функциям

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

Разделяйте инвентаризацию рабочей и промежуточной сред

Рабочую среду можно отделить от сред разработки, тестирования и предварительного развертывания, используя для каждой из них отдельные файлы или каталоги инвентаризации. Так вы сможете выбирать целевую среду с помощью -i. Если хранить все среды в одном файле, могут возникнуть неприятные сюрпризы! Например, при использовании инвентаризации должны быть доступны все пароли хранилища, используемые в ней. Если инвентаризация содержит и рабочую среду, и среду разработки, разработчики, использующие её, смогут получить доступ к рабочим секретам.

Сохраняйте зашифрованные переменные доступными для просмотра

Конфиденциальные переменные и переменные с секретами следует шифровать с помощью Ansible Vault. Однако шифрование имён переменных вместе с их значениями затрудняет поиск источника значений. Чтобы этого избежать, можно шифровать переменные по отдельности с помощью ansible-vault encrypt_string или добавить следующий уровень косвенности, чтобы имена переменных оставались доступными (например, для grep), не раскрывая секретов:

1. Создайте подкаталог group_vars/ с именем группы.
2. В этом подкаталоге создайте два файла с именами vars и vault.
3. В файле vars определите все необходимые переменные, включая конфиденциальные.
4. Скопируйте все конфиденциальные переменные в файл vault и добавьте к их именам префикс vault_.
5. Измените переменные в файле vars так, чтобы они ссылались на соответствующие переменные vault_ с помощью синтаксиса jinja2: db_password: "{{ vault_db_password }}".
6. Зашифруйте файл vault, чтобы защитить его содержимое.
7. Используйте в плейбуках имена переменных из файла vars.

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

Обратите внимание: если использовать эту стратегию в инвентаризации, при запуске с этой инвентаризацией всё равно должны быть доступны все пароли хранилища (например, для ansible-playbook или AWX/Ansible Tower).

Используйте среды выполнения

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

Сначала проверьте в промежуточной среде

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

ansible-playbook --syntax-check

Обновляйте пакетами

Используйте ключевое слово serial, чтобы задать количество машин, обновляемых одновременно в одном пакете. См. раздел Управление местом выполнения задач: делегирование и локальные действия.

Обработка различий между ОС и дистрибутивами

Файлы групповых переменных и модуль group_by работают вместе, помогая Ansible выполнять задачи в различных операционных системах и дистрибутивах, для которых требуются разные настройки, пакеты и инструменты. Модуль group_by создаёт динамическую группу узлов, соответствующих заданным критериям. Эту группу не нужно определять в файле инвентаризации. Такой подход позволяет выполнять разные задачи в разных операционных системах или дистрибутивах.

Например, следующий плей распределяет все системы по динамическим группам на основе названия операционной системы:

- name: Talk to all hosts just so we can learn about them
  hosts: all
  tasks:

    - name: Classify hosts depending on their OS distribution
      ansible.builtin.group_by:
        key: os_{{ ansible_facts['distribution'] }}

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

- hosts: os_CentOS
  gather_facts: False
  tasks:

    # Tasks for CentOS hosts only go in this play.
    - name: Ping my CentOS hosts
      ansible.builtin.ping:

Вы также можете добавить настройки для отдельных групп в файлы групповых переменных. В следующем примере для машин CentOS задаётся значение «42» для asdf, а для остальных машин — значение «10». Файлы групповых переменных также можно использовать для применения ролей к системам и задания переменных.

---
# file: group_vars/all
asdf: 10

---
# file: group_vars/os_CentOS.yml
asdf: 42

Такая же настройка применима с include_vars, если нужны только переменные для конкретной ОС, а не задачи:

- name: Use include_vars to include OS-specific variables and print them
  hosts: all
  tasks:

    - name: Set OS distribution dependent variables
      ansible.builtin.include_vars: "os_{{ ansible_facts['distribution'] }}.yml"

    - name: Print the variable
      ansible.builtin.debug:
        var: asdf

Это подключает переменные из файла group_vars/os_CentOS.yml.