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

Тематические термины: Ansible , NGINX .

В статье разберем использование Ansible для установки веб-сервера NGINX. Мы попробуем продемонстрировать максимум возможностей системы управления — плейбуки (playbook), роли (role), переменные (vars), шаблоны (templates), обработчики (handlers). Также мы сделаем развертывание веб-сервера на 2 разных семейства операционных систем — на основе deb и RPM.

Группы хостов

Создадим тестовую группу хостов, на которой будем тестировать удаленную установку приложения.

Открываем файл хостов ansible:

Добавляем группу хостов или редактируем ее:

* в данном примере мы создаем 2 группы хостов — redhat-servers для серверов семейства Red Hat и debian-servers — для deb-серверов. В каждую группу входят по одному серверу — 192.168.0.11 и 192.168.0.12 .

Проверить доступность хостов для ansible можно командой:

* данной командой мы пропингуем все хосты из инвентаризационного файла hosts.

… мы должны получить, примерно, такой ответ:

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

Создаем файл для playbook:

* где:

• — — начало файла YAML. Данный формат имеет строгую структуру — важен каждый пробел;
• hosts — группа хостов, к которым будут применяться правила плейбука (если мы хотим, чтобы правила применялись ко всем хостам, указываем hosts: all );
• become — указывает на необходимость эскалации привилегий;
• become_method — метод эскалации привилегий;
• become_user — пользователь под которым мы заходим с помощью become_method ;
• remote_user — пользователь, под которым будем подключаться к удаленным серверам;
• roles — список ролей, которые будут применяться для плейбука.

* В данном случае мы задействуем нашу группы хостов, которые создали в самом начале; повышаем привилегии методом su под пользователем root (su — root) для группы redhat-servers и методом sudo для debian-servers ; подключение к серверам выполняется от пользователя ansible ; используем созданную нами роль nginx (саму роль мы создадим позже). Для систем RPM сначала выполним роль epel — она будет отвечать за установку репозитория EPEL, так как в стандартном репозитории nginx нет.

Стоит отдельно уделить внимание вопросу повышения привилегий. IT-среды могут применять разные политики относительно безопасности. Например, на серверах CentOS, по умолчанию, нет sudo и повышать привилегии нужно с помощью su. В Ubuntu наоборот — по умолчанию есть sudo, а su не работает, так как пароль на root не устанавливается. В данном случае есть несколько путей при работе с Ansible:

1. Как в нашем примере, разделить группы хостов на разные семейства операционных систем и применять к ним разные методы повышения привилегий. Чтобы данный плейбук корректно отработал, учетная запись, под которой идет удаленное подключение к серверу (в нашем примере ansible) должна иметь такой же пароль, как у пользователей root на серверах семейства Red Hat. Данный метод удобен с точки зрения отсутствия необходимости приводить к единому виду безопасность серверов разного семейства. Однако, с точки зрения безопасности лучше, чтобы пароли у root и ansible были разные.
2. Использовать метод для создания плейбука, как описан выше, но запускать его с ключом —limit, например, ansible-playbook —limit=debian-servers … — таким образом, мы запустим отдельные задания для каждого семейства операционных систем и сможем ввести индивидуальные пароли для каждого случая.
3. Мы можем на всех серверах deb установить пароль для пользователя root, таким образом, получив возможность для become_method: su.
4. И наконец, можно для серверов Red Hat установить sudo и проходить become с помощью метода sudo.

Создание роли

Роли в Ansible используются для логического разделения плейбука. Они имеют строгий синтаксис и файловую структуру. Таким образом, конфигурация становится более упорядоченной и понятной для дальнейшей поддержки.

И так, для ролей должна быть четкая файловая структура — создаем каталоги:

* в данном случае мы создали каталоги nginx , epel и tasks внутри каталога roles . В ansible это означает, что мы создали роли с названием nginx и epel , а файл main.yml , который мы поместим в каталоги tasks будет описывать задачи данных ролей.

Создаем файл с описанием задач для роли nginx:

* где

• — — начало файла YAML;
• name — название для роли (может быть любым);
• yum/apt — используемый модуль для установки приложения;
• yum/apt name — название пакета, которое мы устанавливаем;
• yum/apt state — состояние пакета, которое должно контролироваться ролью;
• when — условие, при котором данная роль будет выполняться;
• notify — обработчик, который будет вызван в случае успешного выполнения задачи. При необходимости, можно задать несколько обработчиков;

* В данном примере мы создали простую задачу для роли по развертыванию nginx . На системы RPM установка выполняется с помощью модуля yum , на deb — apt . Версия должна быть последней ( latest ); после установки пакета, необходимо разрешить автозапуск сервиса и запустить его.
* при установке пакетов также следует учитывать, что некоторые могут иметь разные названия в разных системах. Например, Apache в RMP-системах называется httpd , в deb — apache2 .

Создаем файл с описанием задач для роли epel:

Обратите внимание, что в плейбуке выше мы задействовали notify, но не задали handlers — в качестве примера, мы вынесем его в отдельный файл:

* handlers — описание обработчика, который может быть вызван с помощью notify; systemd — модуль для управления юнитами systemd; systemd enabled — разрешает или запрещает сервис; systemd state — состояние, которое должно быть у сервиса. В данном примере мы указываем, что у демона nginx должно быть состояние started и разрешен автозапуск ( enabled ).

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

Запускаем наш плейбук:

После ввода данной команды система запросит первый пароль для учетной записи, от которой мы подключаемся к удаленным серверам (в нашем примере мы задали ее в самом плейбуке, опции remote_user):

После ввода пароля, будет запрошен второй пароль — для повышения привилегий на самой удаленной системе:

… в итоге мы должны увидеть следующую картину:

Настройка NGINX с помощью шаблона ansible

После установки веб-сервера nginx необходимо его настроить. Процесс настройки мы разделим на создание переменных и шаблонов конфигурационных файлов, а также настройки роли для формирования конфигурационных файлов на основе шаблона.

Создаем общие переменные

Переменные задаются в файле main.yml, который находится в каталоге vars, который, в свою очередь, находится в каталоге роли. И так, создаем каталог для переменных:

… и сам файл main.yml:

* где представлены некоторые опции настройки NGINX:

• worker_processes — определяет количество рабочих процессов. Чаще всего, оптимальнее выставлять автоматическое конфигурирование.
• worker_connections — максимальное количество соединений одного рабочего процесса.
• client_max_body_size — максимальный размер загружаемых данных.

Шаблон для nginx.conf

Создаем каталог для хранения шаблонов:

… и создаем первый шаблон для конфигурационного файла nginx.conf:

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

Теперь настраиваем нашу роль для использования шаблона:

Добавляем:

* данная роль определяет, каким файлом на сервере ansible ( src ) необходимо заменить файл на удаленной системе ( dest ).

И последнее, открываем файл плейбука:

… вставляем:

* в данном примере мы создаем переменную nginx_user . Так как для разных семейств операционных систем используются разные пользователя для nginx по умолчанию, мы также сделали переменную с разными значениями для RPM и deb.

Готово — запускаем плейбук:

… и вводим дважды пароли. На наших серверах должен появиться конфигурационной файл nginx.conf в соответствии с нашим шаблоном.

Шаблон для создания виртуальных доменов в NGINX

Создадим виртуальные домены при помощи ansible. Сначала создадим переменные — для каждого сервера должны быть свои домены — такие переменные можно задать в файле hosts, котором мы создавали хосты для ansible:

Добавляем к нашим строкам:

* мы создали переменную virtual_domain , у которой будут свои значения для каждого хоста.

Создаем шаблон:

* в данном примере мы создаем простой конфигурационный файл для создания виртуального домена. В качестве самого домена берется значение переменной virtual_domain , которую мы задали через файл hosts . Переменная fastcgi_pass_path будет создана для каждой группы систем своя и определяем путь до сокетного файла для взаимодействия nginx с fastcgi.

Настраиваем нашу роль — создаем 3 задачи:

Добавляем:

* первая задача нужна для создания каталога, в котором будут находиться файлы сайта (без данного каталога наш конфигурационный сайт выдаст ошибку при попытке перезапустить сервис nginx). Вторая задача создаем конфигурационный файл для виртуального домена, который находится в каталоге /etc/nginx/conf.d ; источником данных служит созданный нами шаблон nginx_vhosts.conf ; также мы задаем переменную fastcgi_pass_path , которая будет указывать путь до сокетного файла. Третья задача также создает конфигурацию для виртуального домена на базе созданного шаблона; в отличие от второй задачи, третья создает конфигурационный файл в каталоге /etc/nginx/sites-enabled , а также имеет другое значение переменной fastcgi_pass_path . После успешного выполнения задачи, будет отправлен сигнал на перезапуск службы nginx для применения настроек (некоторые сервисы принимают более предпочтительный вариант — reloaded ).Также мы добавили условие — вторая задача будет применяться к система на базе Red Hat, третья — Debian.
* на самом деле, мы могли две последние задачи объединить в одну, а переменную fastcgi_pass_path задать в файле плейбука. Но мы так поступили намеренно, чтобы продемонстрировать возможность использования переменных при описании роли.

Открываем обработчик:

Дописываем:

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

Теги

В нашем примере нам не довелось использовать теги — еще одну удобную возможность управления запуском плейбука.

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

* в данном плейбуке есть две роли — одна называется nginx , вторая — apache ; для каждой роли мы задали свой тег.

Теперь, чтобы запустить плейбук, но выполнить в нем определенную роль, нам достаточно указать тег:

* данная команда запустит плейбук с выполнением только роли с тегом web2 (в нашем примере, apache ).

Ansible Galaxy

На последок хочется сказать пару слов о Ansible Galaxy. Грубо говоря, это репозиторий готовых плейбуков и ролей. Найти файлы, соответствующую задаче, а также документацию можно на портале galaxy.ansible.com . Установка выполняется командой ansible-galaxy, например:

* данная команда создаст в каталоге пользователя папку .ansible/roles/geerlingguy.apache — в нее поместит файлы с описанием роли.

Готовые библиотеки можно использовать для выполнения задач или просто как шпаргалки.

Если команда нам вернула предупреждение:

… и не установила модуль, скорее всего, у нас низкая версия ansible. Проверить ее можно командой:

Начиная с версии 2.13.9, разработчик выпустил новый сервер Galaxy, а для версий ниже нужно использовать сервер old-galaxy.ansible.com.

Для решения проблемы открываем конфигурационный файл ansible:

Добавляем:

Пробуем установку.