Делайте все просто

Всегда старайтесь делать все просто.

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

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

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

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

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

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

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

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

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

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

Всегда называйте play, задачи и блоки

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

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

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

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

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

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

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

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

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

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

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

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

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

Разделяйте инвентари производства и этапов тестирования

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

Хранение зашифрованных переменных в безопасности

Вы должны шифровать чувствительные или секретные переменные с помощью 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 в своих playbooks.

При выполнении playbook Ansible находит переменные в незашифрованном файле, который извлекает значения чувствительных переменных из зашифрованного файла. Нет ограничений на количество файлов переменных и vault или их имена.

Обратите внимание, что использование этой стратегии в вашем инвентаре по-прежнему требует, чтобы все пароли vault были доступны (например, для 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.