Развёртывание на удалённых серверах с помощью Ansible

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

Эта страница демонстрирует примеры вызовов ansible-playbook. Мы увидим, как развертывать роли или части ролей на удалённых серверах. Затем мы увидим, как выполнять команды на удалённых хостах и, возможно, получать информацию с них. Сначала ознакомьтесь со страницей Обзор Ansible, чтобы понять основные концепции Ansible.

Отправка запроса ping на удалённые серверы

Начнём с самого простого примера: мы хотим, чтобы наш локальный Ansible отправлял запрос ping на удалённые серверы, чтобы проверить, доступны ли они. Вот как это сделать:

ansible -i production-mariadb all -m ping

Прежде чем переходить к более полезным примерам, давайте обсудим этот синтаксис.

• ansible — это исполняемый файл, который можно использовать для выполнения команды на удалённых серверах.
• -i production-mariadb означает, что серверы должны быть прочитаны из инвентаря, называемого production-mariadb.
• all означает, что команда должна быть выполнена на всех серверах из указанного выше инвентаря.
• -m ping указывает, что мы хотим запустить модуль ping. Это не команда ping в Linux. Она показывает, может ли Ansible подключиться к удалённому серверу и выполнить простые команды на нём.

Чтобы выполнить ping для определённой группы или хоста, можно просто заменить «all» именем группы или именем хоста из инвентаря:

ansible -i production-mariadb main_cluster -m ping

Выполнение команд на удалённых серверах

Предыдущие примеры показывают, как запустить модуль Ansible на удалённых серверах. Но также можно выполнить пользовательские команды через SSH. Вот как:

ansible -i production-mariadb all -a 'echo $PATH'

Эта команда показывает значение $PATH на всех серверах в инвентаре «production-mariadb».

Мы также можем выполнять команды от имени root, добавив параметр -b (или --become) :

# print a MariaDB variable
ansible -i production-mariadb all -b -a 'mysql -e "SHOW GLOBAL VARIABLES LIKE \'innodb_buffer_pool_size\';"'

# reboot servers
ansible -i production-mariadb all -b -a 'reboot'

Применение ролей к удалённым серверам

Мы увидели, как выполнять команды на удалённых хостах. Применение ролей на удалённые хосты не намного сложнее, нам просто нужно добавить некоторую информацию. Пример:

ansible-playbook -i production-mariadb production-mariadb.yml

Давайте посмотрим, что изменилось:

• ansible-playbook — это исполняемый файл, который нужно вызвать для применения плейбуков и ролей.
• production-mariadb.yml — это плей, который связывает серверы, перечисленные в инвентаре, с их ролями.

Если мы вызовем ansible-playbook без дополнительных аргументов, мы применим все соответствующие роли ко всем серверам, упомянутым в плее.

Чтобы применить роли только к определённым серверам, можно использовать параметр -l для указания группы, отдельного хоста или шаблона:

# Apply to the mariadb-main role role
ansible-playbook -i production-mariadb -l mariadb-main production-mariadb.yml

# Apply to the mariadb-main-01 host
ansible-playbook -i production-mariadb -l mariadb-main-01 production-mariadb.yml

# Apply to multiple hosts whose name starts with "mariadb-main-"
ansible-playbook -i production-mariadb -l mariadb-main-* production-mariadb.yml

Мы также можем выборочно применять задачи из ролей. Задачи могут иметь теги, и каждый тег соответствует операции, которую мы хотим выполнить на наших удалённых хостах. Например, роль «mariadb» может иметь тег «timezone-update» для обновления содержимого таблиц временных зон таблиц временных зон. Чтобы применить только задачи с тегом «timezone-update», можно использовать следующую команду:

ansible-playbook -i production-mariadb --tag timezone-update production-mariadb.yml

Использование тегов особенно полезно для серверов баз данных. В то время как большинство технологий, обычно управляемых Ansible (веб-серверы, балансировщики нагрузки и т. д.) являются бессостоятельными, серверы баз данных — нет. Мы должны уделять особое внимание тому, чтобы не запускать задачи, которые могут привести к остановке сервера базы данных, например, удалению каталога данных или перезапуску службы, когда это не требуется.

Режим проверки

Мы всегда должны тестировать наши плейбуки и роли на тестовых серверах перед применением их на продакшене. Однако если тестовые и производственные серверы не находятся в идентичном состоянии (что означает, что некоторые факты могут отличаться), всё равно возможно, что применение ролей завершится неудачей. Если неудача произойдёт на начальном этапе, Ansible вообще не будет взаимодействовать с удалёнными хостами. Но есть случаи, когда Ansible может успешно применить некоторые задачи, а затем завершить неудачей применение другой задачи. После первой неудачи ansible-playbook выведет сообщения об ошибках и завершится. Но это может оставить хост в несогласованном состоянии.

Ansible имеет режим проверки, призванный значительно уменьшить вероятность неудач. При запуске в режиме проверки ansible-playbook прочитает инвентарь, плей и роли; определит задачи, которые необходимо применить; затем подключится к целевым хостам, прочитает факты и вычислит все соответствующие переменные. Если все эти шаги пройдут успешно, маловероятно, что запуск ansible-playbook без режима проверки завершится неудачей.

Чтобы запустить ansible-playbook в режиме проверки, просто добавьте параметр --check (или -C) .

Ссылки

Дополнительную документацию можно найти на веб-сайте Ansible:

• инструмент ansible.
• инструмент ansible-playbook.
• Проверка задач: режим проверки и режим сравнения.

Контент первоначально предоставлен компанией Vettabase Ltd.