Мы с вами уже очень кратко познакомились с Ansible – поговорили о том, что это вообще такое, разобрались с базовыми основами его использования. В последней публикации про Ansible мы с вами разобрали даже не самый простой пример playbook. В заключении цикла статей про Ansible я расскажу о том, что такое Ansible Galaxy.
Что такое Ansible Galaxy
Ansible Galaxy – это еще один инструмент Ansible, которые еще дальше автоматизирует и упрощает использование этого инструмента. Основная черта Ansible Galaxy – использование ролей. Например, мы говорим, что на определенной группе хостов нужно установить стэк LAMP. И все – все остальные заботы берет на себя Ansible Galaxy.
Как я уже сказал ранее Ansible Galaxy использует концепцию ролей, т.е. вы указываете ему какие роли должны быть настроены на хосте (или группе) хостов и Ansible Galaxy выполняет всю необходимую работу. Ролей можно указать несколько, тогда Ansible Galaxy выполнит настройку всех ролей из списка.
Для работы с Ansible Galaxy используется одноименная утилита командной строки:
ansible-galaxy -hroman@ansible:~$ ansible-galaxy -h
usage: ansible-galaxy [-h] [--version] [-v] TYPE ...
Perform various Role and Collection related operations.
positional arguments:
TYPE
collection Manage an Ansible Galaxy collection.
role Manage an Ansible Galaxy role.
options:
--version show program's version number, config file location, configured module search
path, module location, executable location and exit
-h, --help show this help message and exit
-v, --verbose Causes Ansible to print more debug messages. Adding multiple -v will increase the
verbosity, the builtin plugins currently evaluate up to -vvvvvv. A reasonable
level to start is -vvv, connection debugging might require -vvvv.
roman@ansible:~$ 
На данном этапе мы с вами еще не выполняли настройку ролей, поэтому мы даже не сможем вывести список этих самых ролей. Поэтому предлагаю сначала рассмотреть базовый пример использования Ansible Galaxy, который я приведу в следующем разделе.
Простой пример использования Ansible Galaxy
В этом примере я буду использовать файл инвентаризации вот из этой предыдущей публикации.
Далее предлагаю перейти к самому простому сценарию использования Ansible Galaxy. В этом примере использую Ansible Galaxy я выполню установку Apache.
Непосредственно перед началом написания playbook необходимо установить роль для apache:
ansible-galaxy install geerlingguy.apacheroman@ansible:~$ ansible-galaxy install geerlingguy.apache
Starting galaxy role install process
- downloading role 'apache', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-apache/archive/3.3.0.tar.gz
- extracting geerlingguy.apache to /home/roman/.ansible/roles/geerlingguy.apache
- geerlingguy.apache (3.3.0) was installed successfully
roman@ansible:~$ 
Важно различать установку роли Ansible Galaxy для последующего использования для настройки хостов или групп и непосредственную настройку хоста или группы в соответствии с указанной ролью. В примере выше мы просто добавили Ansible Galaxy возможность конфигурировать эту роль на хостах или группе. Мы не выполняли установку Apache на текущем хосте. Про настройку хостов или групп в соответствии с ролью мы поговорим чуть ниже.
Если установка завершилась успешно, то вы также должны увидеть роль в перечне всех установленных ролей:
ansible-galaxy listroman@ansible:~$ ansible-galaxy list
# /home/roman/.ansible/roles
- geerlingguy.apache, 3.3.0
[WARNING]: - the configured path /usr/share/ansible/roles does not exist.
[WARNING]: - the configured path /etc/ansible/roles does not exist.
roman@ansible:~$ 
Для того, чтобы указать Ansible Galaxy о том, что следует выполнить настройку роли необходимо объявить соответствующий блок – roles. В этом блоке вы указываете список ролей, настройку которых нужно выполнить. Например, ниже я приведу пример playbook для установки и настройки роли apache:
---
- hosts: front
become: yes
roles:
- geerlingguy.apache
Теперь инициируем процесс настройки роли:
ansible-playbook -i inv.ini apache.ymlroman@ansible:~$ ansible-playbook -i inv.ini apache.yml
PLAY [front] ***************************************************************************************
TASK [Gathering Facts] *****************************************************************************
ok: [tst1]
TASK [geerlingguy.apache : Include OS-specific variables.] *****************************************
ok: [tst1]
TASK [geerlingguy.apache : Include variables for Amazon Linux.] ************************************
skipping: [tst1]
TASK [geerlingguy.apache : Define apache_packages.] ************************************************
ok: [tst1]
TASK [geerlingguy.apache : include_tasks] **********************************************************
included: /home/roman/.ansible/roles/geerlingguy.apache/tasks/setup-Debian.yml for tst1
TASK [geerlingguy.apache : Update apt cache.] ******************************************************
changed: [tst1]
TASK [geerlingguy.apache : Ensure Apache is installed on Debian.] **********************************
changed: [tst1]
TASK [geerlingguy.apache : Get installed version of Apache.] ***************************************
ok: [tst1]
TASK [geerlingguy.apache : Create apache_version variable.] ****************************************
ok: [tst1]
TASK [geerlingguy.apache : Include Apache 2.2 variables.] ******************************************
skipping: [tst1]
TASK [geerlingguy.apache : Include Apache 2.4 variables.] ******************************************
ok: [tst1]
TASK [geerlingguy.apache : Configure Apache.] ******************************************************
included: /home/roman/.ansible/roles/geerlingguy.apache/tasks/configure-Debian.yml for tst1
TASK [geerlingguy.apache : Configure Apache.] ******************************************************
ok: [tst1] => (item={'regexp': '^Listen ', 'line': 'Listen 80'})
TASK [geerlingguy.apache : Enable Apache mods.] ****************************************************
changed: [tst1] => (item=rewrite)
changed: [tst1] => (item=ssl)
TASK [geerlingguy.apache : Disable Apache mods.] ***************************************************
skipping: [tst1]
TASK [geerlingguy.apache : Check whether certificates defined in vhosts exist.] ********************
skipping: [tst1]
TASK [geerlingguy.apache : Add apache vhosts configuration.] ***************************************
changed: [tst1]
TASK [geerlingguy.apache : Add vhost symlink in sites-enabled.] ************************************
changed: [tst1]
TASK [geerlingguy.apache : Remove default vhost in sites-enabled.] *********************************
skipping: [tst1]
TASK [geerlingguy.apache : Ensure Apache has selected state and enabled on boot.] ******************
ok: [tst1]
RUNNING HANDLER [geerlingguy.apache : restart apache] **********************************************
changed: [tst1]
PLAY RECAP *****************************************************************************************
tst1 : ok=16 changed=6 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0
roman@ansible:~$
Обратите внимание на то, что я не указывал какой менеджер пакетов использовать – apt, yum или dnf. Ansible Galaxy самостоятельно определил дистрибутив (Ubuntu) и использовал соответствующий менеджер пакетов. Соответственно, это добавляет ему универсальности – не нужно разрабатывать отдельные playbook для разных дистрибутивов. Второй момент, на который я бы хотел обратить ваше внимание, это ряд дополнительных действий. Настройка Apache, включение его автоматического запуска и т.д. Ansible Galaxy выполняет эти действия за нас с вами. Даже выполняется проверка – запущен ли Apache успешно или нет.
Пожалуй, для базового примера этого достаточно. А теперь давайте усложним задачу – выполним установку и настройку брандмауэра, а также установку сервера nginx. В следующем разделе я более детально покажу этот сценарий.
Расширенный пример использования Ansible Galaxy
В предыдущем примере я показал, как выполняется настройка роли apache. Теперь усложним пример – убедимся, что брандмауэр активировал, настроены исключения и установлен nginx.
Полный перечень параметров для настройки nginx через AnsibleGalaxy приведен вот тут.
Полный перечень параметров для настройки firewall через AnsibleGalaxy приведен вот тут.
Для этого примера я буду использовать следующую структуру каталога:
treeroman@ansible:~/nginxfwd$ tree
.
├── inventory
│ └── inv.ini
├── playbook.yml
└── requirements
└── requirements.yml
2 directories, 2 files
roman@ansible:~/nginxfwd$ 
Файл инвентаризации будет расположен по пути inventory/inv.ini.
Основную логику playbook я вынесу в одноименный файл – playbook.yml
Необходимые роли для Ansible Galaxy в этот раз я не буду устанавливать вручную, а покажу пример того, как перечень ролей можно вынести во внешний файл. Файл я размещу вот тут – requirements/requirements.yml.
Содержимое файла inventory/inv.ini:
[front]
tst1
[front:vars]
ansible_host=10.10.10.107
Перечень ролей я выне в файл requirements/requirements.yml:
---
- src: geerlingguy.firewall
- src: geerlingguy.nginx
Установим нужные роли Ansible Galaxy:
ansible-galaxy install -r requirements/requirements.ymlroman@ansible:~/nginxfwd$ ansible-galaxy install -r requirements/requirements.yml
Starting galaxy role install process
- downloading role 'firewall', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-firewall/archive/2.5.1.tar.gz
- extracting geerlingguy.firewall to /home/roman/.ansible/roles/geerlingguy.firewall
- geerlingguy.firewall (2.5.1) was installed successfully
- downloading role 'nginx', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-nginx/archive/3.1.4.tar.gz
- extracting geerlingguy.nginx to /home/roman/.ansible/roles/geerlingguy.nginx
- geerlingguy.nginx (3.1.4) was installed successfully
roman@ansible:~/nginxfwd$
Теперь мы выполнили всю необходимую подготовку и можем приступать к написанию playbook. Я сразу приведу полный текст playbook:
---
- hosts: front
become: yes
roles:
- geerlingguy.firewall
- geerlingguy.nginx
vars:
firewall_allowed_tcp_ports:
- "22"
- "80"
- "443"
nginx_vhosts: []
nginx_remove_default_vhost: True
nginx_docroot: /var/www/html
Этот небольшой playbook на самом деле выполняет довольно много работы. Мы в этом убедимся на живом примере. Также хочу обратить ваше внимание на то, что для настройки ролей я объявил некоторый перечень переменных. Переменная firewall_allowed_tcp_ports указывает – для каких портов необходимо сделать исключения в брандмауэре. Переменные с префиксом nginx учитываются при настройке роли nginx на группе хостов и выполняют дополнительную настройку сервиса nginx.
Запустим этот runbook:
ansible-playbook -i inventory/inv.ini playbook.ymlВывод команды получился очень большой. Я приведу лишь его последнюю часть:
TASK [geerlingguy.nginx : Copy nginx configuration in place.] **************************************
changed: [tst1]
TASK [geerlingguy.nginx : Ensure nginx service is running as configured.] **************************
ok: [tst1]
RUNNING HANDLER [geerlingguy.firewall : restart firewall] ******************************************
changed: [tst1]
RUNNING HANDLER [geerlingguy.nginx : restart nginx] ************************************************
changed: [tst1]
RUNNING HANDLER [geerlingguy.nginx : reload nginx] *************************************************
changed: [tst1]
PLAY RECAP *****************************************************************************************
tst1 : ok=21 changed=10 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 
Для того, чтобы Ansible Galaxy выполнил такой большой объем работ нам потребовалось написать все с десяток инструкций. Однако, за кадром Ansible Galaxy выполнил много вещей – настроил правила iptables, установил nginx, настроил его автозапуск, убедился, что сервис активен и т.д.
Если теперь перейти на один из хостов группы front, то можно убедиться, что сервис nginx активен и в правилах iptable Ansible Galaxy выполнил необходимые настройки:
Этой публикацией я завершаю цикл статей по экспресс знакомству с Ansible. Надеюсь, что смог донести до вас назначение этого инструмента и его основы.