Опиши структуру playbook в Ansible.

А, ну так вот, слушай, про эти плейбуки в Ansible. Представь себе, что это такой офигенный план захвата, только для серверов, а не для крепости. Вместо «взять мост» и «захватить арсенал» тут «поставить nginx» и «перезапустить службу». И всё это записано в обычном YAML-файле, который читается, как книжка, если, конечно, не охуеть от скуки.

Основные кирпичики, из которых это всё собрано:

• Плей (Play): Это как объявление: «А сейчас, сука, мы будем нагибать вот эту конкретную группу серверов». В нём указывается, кого бить и от чьего имени.

  • hosts: — вот эти несчастные (например, webservers или просто all, чтобы всем влетело).
  • become: — волшебная палочка, чтобы стать рутом. Без неё нихуя не выйдет, система тебя просто пошлёт.
  • vars: — местные переменные, типа порта или какого-нибудь лимита. Удобно, не надо каждый раз в коде ковыряться.
  • tasks: — а вот тут и начинается самое интересное, список дел на сегодня.

• Задача (Task): Конкретный приказ, одно действие. «Установить пакет», «скопировать файл», «запустить скрипт». Всё через готовые модули — не надо изобретать велосипед, бери и пользуйся.

  • У каждой задачи есть name:, чтобы потом не охуевать, глядя в логи и спрашивая «а это что, блядь, делало?».

• Хендлер (Handler): Это такая хитрая жопа. Задача-невидимка. Она сидит и ждёт, пока её не позовут по имени через notify. Обычно это перезапуск службы, который должен сработать только если конфиг реально поменялся. Умно, да? Не дёргай попу без дела.

• Роли (Roles): Ну тут уже полный ёперный театр организации. Когда твой плейбук разбухает, как питон, съевший кролика, самое время нарезать его на роли. Это такая отдельная папочка со своими задачами, шаблонами и переменными. Подключаешь одной строчкой и чувствуешь себя архитектором, а не обезьяной с гранатой.

Вот смотри, простой пример, как навесить nginx на сервера:

---
# playbook.yml
- name: Configure and deploy Nginx on web servers
  hosts: webservers  # Целимся в группу 'webservers'
  become: yes        # Превращаемся в root, иначе нихуя
  vars:
    http_port: 8080
    max_clients: 200

  tasks:
    # 1. Ставим софт
    - name: Ensure Nginx is installed
      apt:
        name: nginx
        state: latest
        update_cache: yes

    # 2. Толкаем наш конфиг через шаблон
    - name: Copy Nginx configuration template
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify:  # Кричим хендлеру: «Эй, проснись!»
        - Restart Nginx

    # 3. Проверяем, не сломали ли мы всё к хуям
    - name: Validate Nginx configuration
      command: nginx -t
      register: nginx_test
      changed_when: false  # Говорим Ансиблу: «Не дергайся, это просто проверка»
      failed_when: nginx_test.rc != 0  # А вот если проверка не прошла — тогда всё, пиздец

  handlers:
    # А вот и наш сонный хендлер. Сработает, только если его позвали.
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

Вот такой, блядь, подход. Всё по полочкам: логика отдельно, настройки отдельно, а перезагрузки — только когда надо. Получается читаемо и, что главное, не превращается в пиздопроебибну через полгода, когда нужно что-то поменять.