Из чего состоит Ansible плейбук

Структура и компоненты Ansible Playbook

Ansible плейбук (playbook) — это основной документ для описания конфигураций, развертываний и оркестрации в Ansible. Он написан на YAML (Yet Another Markup Language) и состоит из декларативных инструкций, которые определяют желаемое состояние инфраструктуры. Плейбук — это не скрипт, а "рецепт", который описывает, что должно быть, а не как этого достичь.

Основные структурные элементы плейбука

1. Плей (Play) — Это блок верхнего уровня в плейбуке. Один плейбук может содержать один или несколько плейев. Каждый плей связывает набор задач с группой хостов, для которых эти задачи должны быть выполнены. Плей определяет "где" и "в каком порядке" работать.

    Ключевые директивы внутри плей:
    *   **`hosts`**: Определяет целевую группу хостов или шаблон (например, `webservers`, `db:&prod`).
    *   **`vars` / `vars_files`**: Позволяет задавать переменные на уровне плей.
    *   **`tasks`**: Основной список задач для выполнения.
    *   **`roles`**: Список ролей, которые нужно применить.
    *   **`become`**: Включение привилегий (sudo) для выполнения задач.
    *   **`gather_facts`**: Флаг, определяющий, собирать ли информацию о хосте (по умолчанию `true`).

1. Задача (Task) — Это основная единица работы в Ansible. Каждая задача вызывает определенный модуль Ansible с набором параметров. Задачи выполняются последовательно, одна за другой, на всех целевых хостах (по умолчанию). Модуль — это готовый инструмент (например, apt, copy, service), который выполняет конкретное действие.

    Пример задачи:

```yaml
tasks:
  - name: Ensure nginx package is installed  # Человекочитаемое имя задачи
    ansible.builtin.apt:
      name: nginx
      state: present
    become: yes  # Пример повышения прав для этой конкретной задачи
```

3. Обработчик (Handler) — Это специальный тип задачи, который запускается только по уведомлению (notify) от других задач. Обработчики обычно используются для перезапуска служб после изменения их конфигурации. Они выполняются один раз в конце плейя, даже если уведомлены несколько раз.

```yaml
tasks:
  - name: Update nginx configuration
    ansible.builtin.copy:
      src: nginx.conf.j2
      dest: /etc/nginx/nginx.conf
    notify: restart nginx  # Уведомление обработчика

handlers:
  - name: restart nginx
    ansible.builtin.service:
      name: nginx
      state: restarted
    become: yes
```

Расширенные элементы и организация

1. Роли (Roles) — Это механизм для структурирования и повторного использования плейбуков. Роль — это автономный каталог с предопределенной структурой, содержащий задачи, обработчики, переменные, шаблоны, файлы и метаданные. Роли позволяют разбить сложную конфигурацию на логические компоненты.

    Примерная структура роли `webserver`:

```
roles/webserver/
├── defaults/
│   └── main.yml       # Переменные по умолчанию (наименьший приоритет)
├── vars/
│   └── main.yml       # Переменные роли (высокий приоритет)
├── tasks/
│   └── main.yml       # Основной список задач роли
├── handlers/
│   └── main.yml       # Обработчики роли
├── templates/
│   └── nginx.conf.j2  # Шаблоны Jinja2
├── files/
│   └── index.html     # Статические файлы для копирования
└── meta/
    └── main.yml       # Зависимости от других ролей
```

    Использование в плейбуке:

```yaml
- hosts: webservers
  roles:
    - role: webserver
      vars_from_role: value
    - common  # Роль без параметров
```

5. Переменные (Variables) — Ansible предоставляет гибкую систему переменных для адаптации поведения плейбука. Они могут быть определены в множестве мест с разным приоритетом (от низшего к высшему): defaults роли, inventory, group_vars, host_vars, vars плейбука, extra_vars (переданные через CLI -e).

1. Шаблоны (Templates) — Задача с модулем template копирует файл, предварительно обрабатывая его движком Jinja2. Это позволяет динамически генерировать конфигурационные файлы на основе переменных и логики.

   - name: Configure application
     ansible.builtin.template:
       src: app.conf.j2
       dest: /etc/myapp/app.conf
     vars:
       server_port: 8080
   

    Пример шаблона `app.conf.j2`:

```jinja2
# Динамически сгенерированный конфиг
server {
    listen {{ server_port }};
    server_name {{ inventory_hostname }};
    root /var/www/{{ app_name }};
}
```

Полный пример плейбука

---
# Пример плейбука для настройки веб-сервера
- name: Configure web servers  # Имя плейя (необязательно, но полезно)
  hosts: webservers            # Целевая группа хостов
  vars:                        # Переменные на уровне плей
    http_port: 80
    max_clients: 200
  become: yes                  # Выполнять все задачи с правами root
  gather_facts: yes            # Собрать факты о хостах (информация об ОС, IP и т.д.)

  tasks:                       # Список задач
    - name: Ensure nginx is at the latest version
      ansible.builtin.apt:
        name: nginx
        state: latest
        update_cache: yes

    - name: Write the nginx configuration file from template
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx    # Уведомить обработчик

    - name: Ensure nginx is running and enabled
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes

  handlers:                    # Обработчики
    - name: restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

- name: Apply common configuration to all servers  # Второй плей в том же плейбуке
  hosts: all
  roles:                       # Использование роли для повторного использования кода
    - common_base

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