Теория: Ad-Hoc

Ansible – консольная утилита для настройки серверов и деплоя приложений. Если смотреть в целом, то она просто выполняет запросы на удаленных серверах, автоматизируя различные рутинные операции, например, установку и обновление пакетов, первоначальную подготовку машины для кода приложения и так далее.

У Ansible несколько режимов работы. Самый простой - ad-hoc, когда запрос к серверу выполняется напрямую из командной строки, без создания дополнительных файлов. Для выполнения такого запроса нам понадобится имя сервера или его ip-адрес. В примерах этого урока используется ip-адрес 157.230.82.133, в вашем случае это будет что-то свое. Кроме этого, сервер должен быть доступен для подключения по SSH суперпользователю (root).

# Проверяет доступность сервера по ip-адресу
# all – запрос выполняется для всех указанных машин
# 157.230.82.133 – ip-адрес моей машины. В вашем случае будет другой
# запятая в конце не ошибка, так нужно для работы Ansible
# root – пользователь для подключения по ssh
# ping – используемая команда (модуль ansible)
ansible all -i '157.230.82.133, ' -u root -m ping

После выполнения этой команды, Ansible покажет ответ от сервера:

# В случае, если доступ есть
157.230.82.133 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

# В случае, если доступа нет
# Здесь использовалось неправильное имя пользователя
157.230.82.133 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: unknown@157.230.82.133: Permission denied (publickey).",
    "unreachable": true
}

В примере выше выполняется соединение с сервером по ssh, на котором запускается команда ping. За ее запуск отвечает одноименный модуль ping входящий в состав Ansible. Модули в Ansible выполняют команды на удаленных машинах. На протяжении следующих уроков мы познакомимся с десятком других самых часто используемых модулей для работы. Один из них называется command, он позволяет выполнить произвольную команду на сервере. Проверим с ее помощью сколько времени запущен сервер (время с последней перезагрузки), за это в Ubuntu отвечает команда uptime:

# Модуль command запускает на удаленной машине команду uptime
# -a – означает аргумент. В случае модуля command это то, что запустится на удаленной машине
ansible all -i '157.230.82.133, ' -u root -m command -a 'uptime'
157.230.82.133 | CHANGED | rc=0 >>
 06:12:48 up 11 days, 21:53,  1 user,  load average: 0.04, 0.04, 0.01
# На момент написания урока сервер находился в строю 11 дней

Модуль command в режиме Ad-Hoc подразумевается по умолчанию, то есть его можно пропустить:

# Тоже самое что и запуск выше
ansible all -i '157.230.82.133, ' -u root -a 'uptime'

Файл инвентаризации

Указание ip-адреса напрямую в командах Ansible — не очень удобный способ управления инфраструктурой. Во-первых, придется запомнить адрес и передавать его всем остальным членам команды. Во-вторых, серверов может быть больше одного. Чтобы не указывать адрес каждый раз, Ansible предлагает создать файл инвентаризации для описания инфраструктуры. В простейшем случае в этом файле указывается список ip адресов, по одному на строчку:

157.230.82.133
# Именем может быть доменное имя, что удобнее
# имена понятнее и не завязаны на ip-адрес, который может поменяться
ec2-3-17-186-111.us-east-2.compute.amazonaws.com
# тут другой адрес
# тут еще один

Сам файл имеет формат ini, но у него нет фиксированного имени. Для удобства назовем его inventory.ini. С этим файлом запуск Ansible в Ad-hoc режиме меняется на:

# -i – означает inventory
ansible all -i inventory.ini -u root -m ping

Ansible не просто выполняет команды на всех серверах, но и делает это одновременно. Ошибка выполнения команды на одном из серверов не останавливает выполнение. Ansible дойдет до конца и оповестит, о том где команда выполнилась успешно, а где нет.

Файл инвентаризации хранят в git-репозитории. Обычно прямо вместе с проектом. Если проект разделен на разные репозитории, то для управления инфраструктурой создают отдельный git-репозиторий, в котором работают администраторы и возможно разработчики. Здесь уже зависит от того, есть ли в компании культура DevOps.