Создание первого плейбука

Введение

В предыдущей лабораторной работе вы выполнили одну команду (ansible ... -m ping). Это удобно для быстрой проверки, но настоящая сила Ansible заключается в плейбуках.

Плейбук — это текстовый файл с инструкциями для автоматизации. В отличие от обычного shell-скрипта, плейбук обычно описывает желаемое конечное состояние, а не каждый низкоуровневый шаг выполнения команды.

Модель желаемого состояния — одна из важнейших идей Ansible. Вместо того чтобы указывать «выполните эти команды в точности», обычно описывают состояние, которое должно быть достигнуто после завершения автоматизации.

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

В этой лабораторной работе вы создадите плейбук, который превратит сервер в веб-сервер:

Установит Nginx — популярный веб-сервер.
Убедится, что служба Nginx запущена.

Затем вы запустите этот плейбук, чтобы настроить локальный компьютер.

Создание файла плейбука

Начнём с создания файла плейбука. Обычно основной плейбук по соглашению называют site.yml.

Сначала перейдите в каталог проекта:

cd ~/project

Теперь создайте и откройте новый файл site.yml в текстовом редакторе nano:

nano site.yml

В самом начале файла введите три дефиса. Они обозначают начало документа YAML.

---

Правила YAML, которые важно помнить:

Отступы критически важны! Используйте пробелы, обычно по 2 пробела, а не символы табуляции. При неправильных отступах Ansible сообщит об ошибке.
Регулярно сохраняйте файл. В nano нажмите Ctrl+O, затем Enter, чтобы сохранить файл, но оставьте его открытым для следующих шагов.

Определение play

Плейбук состоит из одной или нескольких структур play. Play связывает группу хостов с задачами, которые нужно на них выполнить.

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

В файле site.yml добавьте следующие строки под ---.

---
- hosts: webservers
  become: yes

Разбор кода:

- hosts: webservers: эта строка сообщает Ansible: «Выполните эти инструкции на каждом сервере, указанном в группе [webservers] моего inventory».
become: yes: это аналог добавления sudo перед командой. Параметр предоставляет Ansible права root, необходимые для установки программного обеспечения.

Убедитесь, что - hosts начинается в самом начале строки: перед дефисом не должно быть пробелов.

Сохраните файл (Ctrl+O, Enter).

Добавление задачи установки

Теперь нужно указать Ansible, что именно делать. Для этого добавим список задач. Каждая задача использует модуль.

Мы воспользуемся модулем apt, поскольку работаем в Ubuntu, чтобы установить Nginx.

Измените файл site.yml, чтобы он выглядел так:

---
- hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

Разбор кода:

tasks: начинает список задач.
- name: ... — описание задачи для человека. Оно будет выведено на экран при запуске плейбука.
apt: вызывает модуль apt.
name: nginx указывает нужный пакет.
state: present — ключевая декларативная часть. Мы не говорим «установите пакет сейчас». Мы говорим: «убедитесь, что пакет установлен».
- Если пакета нет, Ansible установит его.
- Если пакет уже установлен, Ansible ничего не изменит. Это свойство называется идемпотентностью.

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

Проверьте отступы:

tasks должен быть выровнен по уровню с become.
Перед - name должен быть отступ в 2 пробела.
apt должен быть выровнен по уровню с name.
Для name и state внутри apt нужен дополнительный отступ.

Сохраните файл.

Добавление задачи для службы

Одной установки программного обеспечения недостаточно: нужно убедиться, что программа запущена. Для этого используется модуль service.

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

Добавьте в список в файле site.yml вторую задачу.

---
- hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Start nginx
      service:
        name: nginx
        state: started

Разбор кода:

service: — модуль для управления системными службами, например через systemctl.
state: started гарантирует, что служба запущена. Если служба остановлена, Ansible запустит её.

Важно: дефис - второй задачи должен быть точно выровнен с дефисом первой задачи.

Сохраните файл и выйдите из nano (Ctrl+X, затем Y, затем Enter).

Запуск плейбука

Теперь самое интересное — запуск автоматизации!

Для этого используется команда ansible-playbook. Ей нужно передать имя запускаемого плейбука (site.yml) и используемый inventory (hosts.ini).

Выполните команду:

ansible-playbook site.yml -i hosts.ini

Проследите за выводом. Вы увидите:

Gathering Facts: сначала Ansible проверяет сведения о системе.
Install nginx: будет показано changed (жёлтым цветом), если пакет пришлось установить.
Start nginx: будет показано changed (жёлтым цветом), если службу пришлось запустить.

Если повторно выполнить ту же команду, вывод будет зелёным и будет содержать ok. Это означает: «Всё уже находится в желаемом состоянии, поэтому ничего изменять не пришлось».

Наконец, вручную проверьте, что Nginx запущен:

systemctl status nginx

Вы должны увидеть строку Active: active (running).

Итоги

В этой лабораторной работе вы написали свой первый плейбук Ansible. Вы научились:

Синтаксису YAML: правильно структурировать плейбук с помощью отступов.
Play: задавать hosts — где выполнять задачи, и become — использовать права sudo.
Задачам: применять такие модули, как apt для установки и service для запуска.
Идемпотентности: понимать, почему многократный запуск плейбука безопасен и даёт стабильный результат.

Теперь вместо ручного выполнения команд вы описываете «инфраструктуру как код».