Ansible: создание и обзор структуры для playbook контента

Решил как говориться начать с нуля и подготовить основную структуру для playbook контента. Идею по организации структуры для ansible проектов подчеркнул с  ansible best practise где есть много интересных рекомендаций, которые не стоит игнорировать.

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

Данный подход позволяет использовать конфигурировать и работать с большим количеством хостов, для которых нужна гибкость. По єтому, Подключаем нужные роли в наш плейбук, после чего в group_vars или hosts_vars заполняем нужными нам параметрами, версиями пакетов для нужной группы или определенного хоста. По максимуму используем темплейтинг, чтоб на основе одного темплейта, создавались разные файлы в соответствии с окружением. Конечно, если это не специфическая роль для настройки проекта, а например подготовка web сервера, где нужно установить nginx, php, common-packages.

Для даной структуры создадим отдельный репозиторий который и будем в будущем заполнять (добавлять новые роли, плейбуки и прочее).

Создал следующую структуру:

├── inventories 
│    ├── AWS 
│    │     ├── group_vars
│    │     │    ├── all 
│    │     │    └── web-servers
│    │     ├── hosts
│    │     └── host_vars
│    │           ├── hostname1
│    │           └── hostname2
│    ├── DO
│    │    ├── group_vars
│    │    │    ├── group1
│    │    │    └── group2
│    │    ├── hosts
│    │    └── host_vars
│    │          ├── host1
│    │          └── host2
│    └── Local
│          ├── group_vars
│          ├── hosts
│          └── host_vars
├── roles 
│    ├── nginx 
│    ├── php
│    ├── grafana
│    └── common
├── ansible.cfg
├── README.md
├── grafana.yml
└── web-server.yml

Теперь рассмотрим структуру подробнее:

inventories
директория в которой будет размещены host, group_vars, host_vars в зависимости от разных окружений, провайдеров и прочее. В моем примере создана структура отталкиваясь от облачных провайдеров которыми я пользуюсь. С директориями AWS и DO все понятно сразу, это облачные провайдеры в которых живет инфраструктура. Намного интереснее директория Local, в ней размешаются локальные ресурсы (сервера, локальные мониторилки, билд машины) которые конфигурируем используя ansible.

Кстати, дополнительно в директориях AWS и DO можно добавить под директории dev, stage, prod которые будут соответствовать окружениям разработки.

hosts
Основной инвентарный файл, в который добавляем хосты и параметры к хостам. В файле можно создавать группы хостов и обеднять группы в группы (так называемые сhildren) для обеднения их в одно целое, пример содержания файла hosts:

# host без групы
10.4.5.11 

# група Local в которую входят локальные сервера мониторинга 
[local]
10.2.3.10
10.2.3.15

# можно додавать не только IP но и hostname
[web-servers] # группа веб серверов
web-1.example.com
web-2.example.com

Подробнее почитать про интентори файл и группы можно здесь.

group_vars
Здесь размещаем фалы с переменными которые будут применены к определенной группе хостов. Для этого нужно создать файл с именем группы хостов и добавить в него переменные. Названия груп прописываются в файле hosts.
Если мы хотим чтоб переменные использовались все хосты одновременно, нужно создать в директории group_vars файл all, и тогда все добавленные переменные в данный файл будут использоваться всеми хостами, пример:

--- 
# file: group_vars/monitoring
prometheus_version: 2.32.1
prometheus_conf_path: /etc/prometheus

host_vars
В данной директории создаются файлы с названием хостов, в которые добавляются переменные для определенного хоста. То есть,  переменные индивидуальные и используются только хостом в котором они записаны, пример:

--- 
# file: host_vars/mysql.master.domain.local
db_port: 3308
db_type: mysql

кстати, некоторые директории  не всегда нужно создавать, тут зависит от ситуаций и надобности.

roles

Директория с ролями, пример название ролей nginx, php, common-packages.  Роль позволяет сгруппировать несколько задач в один конвейер, и автоматизировать работу с помощью понятной структуры каталогов. Дополнительно про роли читаем здесь.

Рассмотрим структуру ролей:

roles/
    nginx/ # название роли 
        tasks/
        handlers/
        library/
        files/
        templates/
        vars/
        defaults/
        meta/

где:

• tasks/main.yml – основной список задач которые будет исполнять роль. Для лучшего понимания, в данной директории задания можно описывать в разных файлах, для примера создали два файла install.yml,  config.yml и после добавляем их в main.yml используя include_tasks.
• handlers/main.yml – списки задач (обработчиков),  на которые можно ссылаться. Если ничто не ссылается на обработчик, тогда он не будет запускаться. Обработчик запускается только один раз, после того как все задачи завершены. В большинстве случаев в обработчике описывают перезапуск systemd сервиса и потом добавляют вызов в нужной задаче,  подробнее про обработчики читаем здесь.
• library/my_module.py – в директории размещают самописные модули, которые могут быть использованы в роли, подробнее смотри здесь.
• defaults/main.yml – переменные по умолчанию с очень низким приоритетом, подробнее про использование переменных читаем здесь. Данные переменные могут быть переназначены в директориях vars, hosts_vars, group_vars или через ansible cli. На практике здесь хранятся дефолтные переменные которые очень редко изменяются. Тут уже как говориться — на ваше усмотрение.
• vars/main.yml – переменные с большим приоритетом.
• files – директория с файлами которые используются в роли. Передавать в файлы которые лежат в этой директории переменные — нельзя. Для примера в ней можно разместить сохраненные дашборды графаны, конфигурационные файлы и прочее где не нужно применять переменные.
• templates – директория с шаблонами  Jinja2. На практике в данной директории находятся шаблоны, конфигурационные файлы в формате.j2 которые используются для копирования на хост в оригинальном формате. Использование темплейтов позволяет нам передавать переменные, что делает их более гибкими. Используя один шаблон для разных окружений изменяя только переменные которые мы определим.
• meta/main.yml – директория с метадатай об авторе, зависимостях которые использует роль.

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

ansible.cfg
конфигурационный файл, в котором назначаются настройки по умолчанию для ansible. Если говорить о хранение файла, то Ansible будет его искать в следующих местах:

• в переменной ANSIBLE_CONFIG если определить.
• в текущем каталоге ./ansible.cfg
• в домашней директории ~/ansible.cfg
• в директории  /etc/ansible/ansible.cfg
• в моем случае, файл будет храниться в корне репозитория, вместе с плейбуками, ролями

playbook.yml
Файл в котором мы связываем хосты и роли которые нужно выполнять. Для примера рассмотрим плейбук grafana.yml:

---
 - hosts: grafana
   become: yes
   roles:
     - nginx
     - docker
     - certbot
     - grafana

где:

• hosts: grafana – имя хоста на котором хотим выполнить роль.
• become: yes – выполнять все команды c привилегиями sudo.
• roles:
  • nginx – установит и настроит nginx
  • docker – установит docker and docker-compose
  • certbot – установит все для генерации самоподписных сертификатов le
  • grafana – подготовит и развернет конвейеризированную grafana

Собственно на этом все, далее будем потихоньку заполнять структуру новыми ролями.