Советы и рекомендации

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

• Общие советы

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

• Советы по playbook-файлам

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

• Советы по инвентаризации

  • Используйте динамическую инвентаризацию с облаками
  • Группируйте инвентаризацию по функциям
  • Разделяйте инвентаризацию для разработки и тестирования
  • Обеспечьте безопасный доступ к зашифрованным переменным

• Уловки выполнения

  • Сначала протестируйте в среде тестирования
  • Выполняйте обновления группами
  • Учет различий в операционных системах и дистрибутивах

Общие советы

Эти принципы применимы ко всем операциям и артефактам Ansible.

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

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

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

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

Советы по playbook-файлам

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

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

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

Всегда называйте задачи

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

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

Для многих модулей параметр «state» является необязательным. У разных модулей разные значения по умолчанию для «state», и некоторые модули поддерживают несколько значений «state». Явное указание «state=present» или «state=absent» делает playbook-файлы и роли более понятными.

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

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

Советы по инвентаризации

Эти советы помогают поддерживать организацию инвентаризации.

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

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

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

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

Разделяйте инвентаризацию для разработки и тестирования

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

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

Вы должны шифровать конфиденциальные или секретные переменные с помощью Ansible Vault. Однако шифрование имён переменных, а также значений переменных затрудняет поиск источника значений. Вы можете сохранить доступ к именам переменных (например, с помощью 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 в своих playbook-файлах.

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

Уловки выполнения

Эти советы относятся к использованию Ansible, а не к артефактам Ansible.

Сначала протестируйте в среде тестирования

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

Выполняйте обновления группами

Используйте ключевое слово «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
       group_by:
         key: os_{{ ansible_facts['distribution'] }}

 # now just on the CentOS hosts...

 - hosts: os_CentOS
   gather_facts: False
   tasks:
     - # tasks that only happen on CentOS go in this play

Первый плей сортирует все системы в динамические группы на основе имени операционной системы. Позже плей могут использовать эти группы в качестве шаблонов в строке hosts. Вы также можете добавлять настройки, специфичные для группы, в файлы group vars. Все три имени должны совпадать: имя, созданное задачей group_by, имя шаблона в последующих плей и имя файла group vars. Например:

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

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

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

Вы можете использовать ту же настройку с include_vars, когда вам нужны только операционно-специфичные переменные, а не задачи:

- hosts: all
  tasks:
    - name: Set OS distribution dependent variables
      include_vars: "os_{{ ansible_facts['distribution'] }}.yml"
    - debug:
        var: asdf

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