Знакомство с Ansible. Часть 5. Примеры использования Ansible Galaxy
Знакомство с Ansible. Часть 5. Примеры использования Ansible Galaxy
Мы с вами уже очень кратко познакомились с 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 -h
roman@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.apache
roman@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 list
roman@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.yml
roman@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 приведен вот тут.
Для этого примера будет использоваться следующую структуру каталога:
tree
roman@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.yml
roman@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.