Установка и использование Ansible: полное руководство по автоматизации
Полное руководство по установке и настройке Ansible: от базовой установки до создания playbook и управления ролями
Установка и использование Ansible
Что такое Ansible
Ansible — простая и гибкая система управления конфигурациями. Подразумевает минимум два файла для начала работы:
- inventory-файл — список хостов, разделенных на группы
- файл задач (playbook) — указатель на нужные роли, написанный в YAML-формате
Роли представляют собой набор задач, шаблонов, тригеров-обработчиков, переменных, файлов и ссылок на другие роли, размещенные по каталогам в стандартной для Ansible структуре.
Модули Ansible
В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами:
- Мониторинг (Nagios, monit)
- Управление пакетами (apt, yum, rhn-channel, npm, pacman, pip, gem)
- Работа с утилитами (git, hg)
- Система (LVM, SELinux, ZFS, cron, файловые системы, сервисы, модули ядра)
- Сеть и сетевая инфраструктура (OpenStack, Arista)
- Файлы (шаблонизация, регулярные выражения, права доступа)
- Базы данных (MySQL, PostgreSQL, Redis, Riak)
- Облачные ресурсы и виртуализация (OpenStack, libvirt)
- Оповещения (Jabber, IRC, почта, MQTT, HipChat)
О том, с чем умеет работать Ansible “из коробки”, можно прочитать в официальной документации.
Установка и подготовка к работе
На рабочей машине подключаем PPA и устанавливаем актуальную версию:
apt update
apt install software-properties-common
add-apt-repository --yes --update ppa:ansible/ansible
apt install ansible
Важно: Привилегии root для работы с Ansible не нужны, поэтому все операции выполняются под обычным пользователем.
Применение на практике
Добавление сервера в inventory-файл
Пример готового файла inventory.yml:
---
all:
children:
project-name:
hosts:
project-server:
ansible_host: 'project-server.example.com'
vars:
ansible_user: 'root'
ansible_python_interpreter: /usr/bin/python3
Обеспечение доступа к серверу для Ansible
Чтобы Ansible смог подключиться к серверу, необходимо предварительно добавить в /root/.ssh/authorized_keys на сервере публичную часть вашего ssh-ключа.
Рекомендация: После настройки убираем ключ, чтобы исключить вероятность случайного применения Ansible при ошибке в конфигах (например, если скопировали строчку в inventory-файле и не поменяли IP). Эта схема подходит для разовой настройки.
Проверка доступности хостов
Проверить доступность хоста для Ansible можно с помощью модуля ping:
ansible -m ping all -i ~/ansible_hosts
Пример вывода:
server-tester | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"
}
Подготовка playbook
Перед подготовкой необходимо ознакомиться с синтаксисом YAML. В playbook указываем:
- Название
- Хост
- Пользователя, под которым Ansible будет работать
- Путь к файлам с переменными
- Нужные роли
Когда Ansible видит название роли (например, atop), он ищет одноименный каталог в ~/project-ansible/roles/. Там должна быть готова структура роли: ~/project-ansible/roles/atop/tasks/main.yml.
Пример playbook:
---
- name: General playbook
hosts: all
become: true
become_method: sudo
vars_files:
- vault.yml
roles:
- role: nginx
nginx_letsencrypt_cert_renewal : true
nginx_vhosts:
- main_server_config.j2
- proxied_server_config.j2
domain_name: "XXXYYYZZZ-students.devboxops.xyz"
proxied_domain_name: "XXXYYYZZZ-proxied-students.devboxops.xyz"
- role: user
user_name: "dev-user"
user_password: "prod_user_password"
user_sudo: "yes"
user_sudoers: ["/bin/systemctl stop systemd-journald", "/bin/systemctl start systemd-journald"]
user_ssh_key: "key1"
- role: user
user_name: "prod-user"
user_password: "dev_user_password"
user_sudo: "yes"
user_sudoers: ["/bin/systemctl stop rsyslog", "/bin/systemctl start rsyslog"]
user_ssh_key: "key2"
Запуск playbook
Когда inventory-файл и playbook готовы, запускаем Ansible командой:
ansible-playbook -i inventory/project --ask-vault-pass servername.yml
где servername.yml — подготовленный playbook.
Пример минимального playbook с одной ролью:
- name: testsrv server
hosts: testsrv
remote_user: root
roles:
- nginx
Получаемый вывод:
$ ansible-playbook testsrv.yml -i ~/ansible_hosts
PLAY [testsrv server] *****************************************************************
TASK [Gathering Facts] ***************************************************************
ok: [testsrv]
TASK [nginx : install packages] *******************************************************
changed: [testsrv] => (item=[u'nginx'])
TASK [nginx : nginx service check] *****************************************************
ok: [testsrv]
TASK [nginx : nginx enable] ************************************************************
changed: [testsrv]
RUNNING HANDLER [nginx : nginx restart] ************************************************
changed: [testsrv]
PLAY RECAP ***************************************************************************
testsrv : ok=2 changed=3 unreachable=0 failed=0
Результаты выполнения модулей
В выводе отображается результат работы каждого модуля:
- ok — модуль отработал корректно, изменения на сервере не требуются
- changed — модуль отработал корректно, внесены изменения на сервер
- unreachable — не удалось подключиться к серверу по SSH
- failed — что-то пошло не так
Повторный запуск
Если какие-то модули отработали некорректно и причины были исправлены, playbook можно запустить повторно. Запуск пройдет быстрее, так как Ansible не будет повторно обновлять кэш apt, устанавливать пакеты и т.д.
Пример повторного запуска:
$ ansible-playbook testsrv.yml -i ~/ansible_hosts
PLAY [testsrv server] *****************************************************************
TASK [Gathering Facts] ***************************************************************
ok: [testsrv]
TASK [nginx : install packages] *******************************************************
ok: [testsrv] => (item=[u'nginx'])
TASK [nginx : nginx service check] *****************************************************
ok: [testsrv]
TASK [nginx : nginx enable] ************************************************************
ok: [testsrv]
RUNNING HANDLER [nginx : nginx restart] ************************************************
ok: [testsrv]
PLAY RECAP ***************************************************************************
testsrv : ok=5 changed=0 unreachable=0 failed=0
Запуск с опцией –check
Ansible поддерживает режим Dry Run с опцией --check. При запуске playbook с этой опцией на сервере не будет произведено никаких изменений.
Особенности режима –check
- Модули, поддерживающие check mode — сообщат об изменениях, которые должны быть внесены (без фактического применения)
- Модули, не поддерживающие check mode — не будут осуществлять изменения, но и не сообщат о том, что должно быть изменено
Ограничения Dry Run
Dry run может работать неэффективно в случаях, когда в playbook есть шаги, использующие переменные, задаваемые при выполнении предыдущих команд.
Пример проблемы с предварительно скачиваемым бинарником:
TASK [test-binary : extract binary to /usr/local/bin] ***************************
fatal: [testsrv]: FAILED! => {
"changed": false,
"msg": "Source '/tmp/test-binary.tar.gz' does not exist"
}
Типичные проблемы при использовании –check:
- Скачивание файлов и последующее их использование
- Проверка checksum различными шагами
- Создание симлинков на несуществующие файлы
Параметры проверки в Ansible
В Ansible существует 3 параметра, связанных с проверкой:
- Опция –check (dry run)
- Check mode в модулях
- Параметр task’ов check_mode
Таблица поведения check mode
Таблица ниже демонстрирует что, происходит при их использовании(взято здесь)
|============|=========|======================|==================|
| check_mode | dry run | check mode supported | result |
|============|=========|======================|==================|
| true | no | no | skip |
| false | no | no | run |
| absent | no | no | run |
|------------|---------|----------------------|------------------|
| true | no | yes | report changed |
| false | no | yes | run |
| absent | no | yes | run |
|============|=========|======================|==================|
| true | yes | no | skip |
| false | yes | no | run |
| absent | yes | no | skip (!) |
| true | yes | yes | report_changed |
| false | yes | yes | run |
| absent | yes | yes | report_changed |
|============|=========|======================|==================|
Некоторые подробности доступны тут