Как запустить ansible playbook на линукс
Обновлено: 04.07.2024
Официальную документацию с официальными примерами всегда можно почитать на сайте разработчиков Ansible.
Как установить и первоначально настроить Ansible описано здесь:
Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:
По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.
Как настраивать защищенные плейбуки описано в этом разделе.
Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах.
Рассмотрим структуру и правила написания таких сценариев более подробно.
Чтобы выполнить сценарий используется команда ansible-playbook со следующим синтаксисом:
Для Ansible практически каждый YAML файл начинается со списка. Каждый элемент списка — список пар «ключ-значение», часто называемая словарем.
Перед каждым новым разделом списка ставится дефис ( - ):
Основными параметрами/группами простого сценария являются:
Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:
Рассмотрим все эти разделы более подробно.
В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.
Так, строка формата:
Это означает, что изменения будут применены к узлам из группы webservers .
Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соединение, но и любого другого.
В следующем примере авторизация на узле будет произведена с именем yourname , но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):
В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:
Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks . Каждой задаче ( task ) присваивается имя ( name ).
Далее указываются модули Ansible, которые будут задействованы при ее выполнении:
Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:
Еще некоторые примеры.
Словарь представлен в виде « ключ: » (двоеточие и пробел) « значение »:
При необходимости словари могут быть представлены в сокращенной форме:
Можно указать логические значение (истина/ложь) так:
Целиком наш пример YAML–файла будет выглядеть так:
Для переменных Ansible использует « > ». Если значение после двоеточия начинается с « < », то YAML будет думать, что это словарь.
Для использования переменных нужно заключить скобки в кавычки:
Этого достаточно для начала написания playbooks.
По данной ссылке я создам небольшую подборку самых интересных и типовых плейбуков, которые могут пригодиться вам в повседневной работе.
Ansible не просто выполняет задачи в указанном порядке, но и проверяет их состояние на наличие изменений. Если при выполнении сценария требовалось, например, добавить строку в конфигурационный файл, и в результате выполнения он изменился (необходимой строки действительно не было), то Ansible может выполнить специальную задачу, описанную как обработчик события ( handler ). Если при выполнении строка уже была в конфигурационном файле, то обработчик выполнен не будет. Обработчики событий описываются в конце сценария. В описании задачи они указываются через параметр notify .
4. Контроль выполнения.
Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи.
Для этого можно использовать оператор « when »:
5. Шаблонизация.
В Ansible используется шаблонизатор Jinja2.
Приведём пример шаблона (часть конфигурации powerdns):
В приведённом примере мы подставляем в шаблон следующие значения:
Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template ; он же может задать необходимые права доступа и изменить владельца/группу:
Внимание! Файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.
6. Делегирование задачи другому узлу.
Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла.
Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива delegate_to .
7. Роли.
Ролью называется типовой набор переменных и задач, назначаемых для одного или нескольких серверов. Если вам нужно применить к серверу или группе серверов типовой набор операций, вам достаточно просто назначить ему роль. Предварительно в проекте каталоге проекта должна быть создана соответствующая структура.
В сценариях роли назначаются следующим образом:
8. Структура проекта.
Playbook может состоять из списка обслуживаемых серверов, переменных пользователя, задач, обработчиков (хендлеров) и так далее. Большинство настроек конфигурации можно переопределить в playbook. Каждый playbook состоит из одного или более действия (игры) в списке.
Цель игры — связать группу хостов с предопределенными ролями, представленными как вызов задач Ansible.
В качестве другого примера давайте рассмотрим процесс установки nginx.
Создадим директорию, где будут хранится playbooks:
Создадим файл setup_nginx.yml в директории playbooks со следующим содержанием:
Давайте рассмотрим содержимое:
- hosts: Список узлов или группа, на которой вы запускаете задачу.
Это поле обязательное и каждый playbook должен иметь его, за исключением ролей. Если указана узловая-группа, сначала Ansible ее ищет в playbook, а затем в файле inventory .
Узнать, на каких узлах будет происходить работа, можно командой:
где – путь к вашему playbook ( playbooks/setup_nginx.yml ).
- tasks: Задачи. Все playbooks содержат задачи.
Задача — это список действий, которые вы хотите выполнить. Поле задачи содержит имя задачи (справочная информация о задаче для пользователя playbook), модуль, который должен быть выполнен и аргументы, требуемые для модуля. Параметр « name » может добавляться опционально, но, в целом, рекомендуемый.
10. Пример сценария.
11. Практические примеры плейбуков.
По данной ссылке я создам небольшую подборку типовых плейбуков, которые могут пригодиться вам в повседневной работе.
12. Запуск плейбуков.
Чтобы запустить плейбук и выполнить все определенные в нем задачи, используйте команду ansible-playbook:
Чтобы перезаписать в плейбуке опцию hosts по умолчанию и ограничить выполнение определенной группой или узлом, включите в команду опцию -l :
13. Запрос информации о play.
Опция --list-tasks используется для перечисления всех задач, которые будут выполнены в play, при этом не внося никаких изменений на удаленные серверы:
Точно так же можно запросить все узлы, которые будут затронуты выполнением play, без запуска каких-либо задач на удаленных серверах:
Вы можете использовать теги, чтобы ограничить выполнение play.
Чтобы вывести список всех тегов, доступных в play, используйте параметр --list-tags :
14. Управление выполнением плейбука.
Вы можете использовать опцию --start-at-task , чтобы определить новую точку входа вашего плейбука. Затем Ansible пропустит все, что предшествует указанной задаче, выполнив оставшуюся часть play с заданного момента.
Эта опция в качестве аргумента требует правильное имя задачи:
Чтобы выполнять только задачи, связанные с конкретными тегами, вы можете использовать опцию --tags .
Например, если вы хотите выполнить только задачи, помеченные как nginx или mysql, вы можете использовать:
Если вы хотите пропустить все задачи, которые находятся под определенными тегами, используйте --skip-tags .
Следующая команда будет выполнять myplaybook.yml , пропуская все задачи, помеченные как mysql :
15. Настройка защищенных плейбуков.
Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.
Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.
В инструкции описано применение и работа с Ansible Playbook, а также кратко рассмотрена их структура.
Что такое Ansible Playbooks?
Playbook в Ansible определяет серию некоторых действий для выполнения и адресованы определенным наборам серверов. В отличие от некоторых других инструментов для выполнения настроек, Playbook не описывает состояние машины, а Ansible самостоятельно определяет все изменения, которые необходимо внести. Тем не менее, плейбуки должны быть разработаны как идемпотенты, а это значит, что они могут запускаться более одного раза без негативных последствий.
Часто плейбуки используют для выполнения начальной настройки серверов - добавления пользователей и каталогов, управлением пакетами программного обеспечения и файлами.
Playbook - это YAML-файл, который обычно имеет следующую структуру:
Например, следующий playbook будет входить на все серверы группы marketingservers и обеспечивать запуск веб-сервера Apache:
В плейбуке выше приведен пример задания (task):
Каждое задание должно иметь имя, которое впоследствии регистрируется и может помочь отслеживать прогресс. После строки имени (name) находится модуль, который будет запущен, в данном случае это служебный модуль. Другие атрибуты разрешают больше опций, в примере Ansible разрешается использовать привилегии sudo.
Запуск Ansible Playbook
Запустить готовый плейбук можно используя следующую команду:
Однако, если есть необходимость отфильтровать список хостов, чтобы сценарий применялся только к одному из этих хостов, можно добавить флаг и указать подмножество хостов в файле:
ansible-playbook -l host_subset playbook.yml
ansible-playbook -l host3 nginx.yml
Когда вы устанавливаете и настраиваете службы вручную, почти всегда необходимо знать результат действий. Настроить эту функциональность можно с помощью регистрации.
Для каждой задачи при желании возможно зарегистрировать ее результат (сбой или успех) в переменной, которую можно проверить позже. При использовании этой функциональности рекомендуется указывать Ansible игнорировать ошибки для такой задачи, так как обычно выполнение playbook прерывается в случае возникновения каких-либо проблем.
Таким образом, если необходимо проверить, выполнилась ли задача или нет и принять решение о последующих шагах, необходимо использовать функциональность регистрации.
Главное меню » Linux » Ansible: playbook в Ansible
Специальные команды Ansible идеально подходят для выполнения задач, которые не выполняются часто, таких как получение данных о работоспособности серверов, получение системной информации и т. д.
С другой стороны, плейбуки Ansible идеально подходят для автоматизации сложных задач, таких как системные исправления, развертывание приложений, конфигурации брандмауэра, управление пользователями и т. д.
Обратите внимание, что мы включили все сценарии, сценарии и файлы, которые я собираюсь обсудить в этой серии, в этот репозиторий GitHub.
Прежде чем следовать этой статьи по Ansible Playbook, вам следует обратиться к настройке, упомянутой в первой главе серии статей о Ansible.
Создание вашей первой Ansible playbook
Плейбуки написаны в формате YAML (еще один язык разметки). Если вы не знаете YAML; Мы включили наиболее важные правила синтаксиса YAML на рисунок ниже, чтобы вы могли легко следовать всем примерам статьи:
Вы также должны знать, что файлы YAML также должны иметь расширение .yaml или .yml. Мы лично предпочитаем .yml, потому что в нем меньше печатать.
Кроме того, YAML чувствителен к отступам. Отступ в два пробела рекомендуется использовать в YAML; однако YAML будет следовать любой системе отступов, которую использует файл, если она согласована.
Постоянно нажимать два пробела на клавиатуре не раздражает, поэтому сделайте себе одолжение и включите следующую строку в файл
Это преобразует вкладки в два пробела всякий раз, когда вы работаете с файлом YAML. Понравился этот удобный совет по Vim?
Теперь давайте создадим ваш первый сценарий. В каталоге проекта создайте файл с именем first-playbook.yml со следующим содержимым:
Playbook будет работать на всех хостах и использует файловый модуль для создания файла с именем /tmp/foo.conf ; вы также устанавливаете режим: 0664 и параметры модуля owner: destroyer, чтобы указать права доступа к файлу и владельца файла. Наконец, вы устанавливаете опцию state: touch, чтобы убедиться, что файл создается, если он еще не существует.
Чтобы запустить playbook, вы можете использовать команду ansible-playbook, за которой следует имя файла playbook:
Вот полный вывод вышеуказанной команды:
Результат запуска playbook довольно понятен. На данный момент обратите особое внимание на значение changed = 1 в сводке PLAY RECAP, которое означает, что одно изменение было успешно выполнено на управляемом узле.
Давайте запустим следующую специальную команду, чтобы убедиться, что файл /tmp/foo.conf действительно создан на всех управляемых хостах:
Обратите внимание, что вы также можете запустить специальную команду Ansible, которая будет делать то же самое, что и playbook first- playbook.yml:
Чтобы узнать больше о файловом модуле, посетите его страницу документации Ansible:
Запуск нескольких сценариев с помощью Ansible Playbook
Вы создали только один сценарий, который содержит одну задачу в playbook first- playbook.yml. Playbook может содержать несколько сценариев, и каждый сценарий, в свою очередь, может содержать несколько задач.
Давайте создадим книгу с именем multiple-plays.yml со следующим содержимым:
В этой пьесе есть две пьесы:
Обратите внимание, что мы использовали модуль пакета при первом воспроизведении, поскольку это универсальный модуль для управления пакетами, и он автоматически определяет диспетчер пакетов по умолчанию на управляемых узлах. Мы использовали модуль apt во второй игре, так как мы запускаем его только на хосте Ubuntu ( node4 ).
Модули yum и dnf также существуют и они работают на системах CentOS и RHEL.
Мы также использовали модуль архива для создания сжатого с помощью gzip архива /tmp/logs.tar.gz, который содержит все файлы в каталоге /var/log.
Идите вперед и запустите playbook multi-plays.yml :
Все выглядит хорошо. Вы можете быстро проверить, существует ли архив /tmp/logs.tar.gz на всех узлах, выполнив следующую специальную команду:
Мы также рекомендуем вам проверить следующие страницы документации Ansible и проверить раздел примеров:
Проверка playbooks (перед запуском)
Хотя мы уже показали вам шаги по запуску плейбуков Ansible, всегда полезно проверить свой плейбук перед его запуском. Это гарантирует, что ваш playbook не содержит потенциальных ошибок.
Читать Лучший смартфон-Android 2020. Какой топовый Android-телефон сегодня можно купить?Обратите внимание, что сухой запуск playbook не зафиксирует никаких изменений на управляемых узлах.
Вы также можете проверить справочную страницу ansible-playbook для получения полного списка опций.
Повторное использование задач и учебников
Вы можете написать несколько сценариев, которые имеют общий список задач. В этом случае лучше создать файл, содержащий список всех общих задач, а затем вы сможете повторно использовать их в своих сборниках.
Для демонстрации создадим файл с именем group-tasks.yml , содержащий следующие задачи:
Теперь вы можете использовать модуль import_tasks для запуска всех задач в group-tasks.yml в вашей первой книге воспроизведения следующим образом:
Вы также можете использовать модуль import_playbook для повторного использования всей playbook. Например, вы можете создать новую книгу воспроизведения с именем reuse-playbook.yml со следующим содержимым:
Также обратите внимание, что вы можете импортировать пьесу только на новом уровне игры; то есть вы не можете импортировать игру в другую.
Вы также можете использовать модуль include для повторного использования задач и playbook. Например, вы можете заменить оператор import_playbook на оператор include следующим образом:
Выполнение выборочных задач и игр с помощью Ansible playbook
Вы можете выбрать не запускать всю книгу воспроизведения и вместо этого захотите запустить определенные задачи или игры в книге. Для этого можно использовать теги.
Например, вы можете пометить задачу install git в playbook multiple-plays.yml следующим образом:
Как видите, первые две игры были пропущены, и запустился только install git. Вы также можете увидеть changed = 0 в PLAY RECAP, потому что git уже установлен на node4.
Вы также можете применить теги к пьесе аналогичным образом.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Главное меню » Linux » Ansible. Принятие решений в Ansible
- Используйте операторы when для условного выполнения задач.
- Используйте инструкции блока для реализации обработки исключений.
- Используйте обработчики Ansible для запуска задач при изменении.
Излишне говорить, что вы должны быть знакомы со статьями Ansible, специальными командами и другими основами Ansible, чтобы понять эту статью.
В этой статье используется та же настройка, которая была упомянута в первой статье: 1 элемент управления Red Hat, 3 узла CentOS и 1 узел Ubuntu.
Выбор того, когда запускать задачи
Давайте начнем ставить условия, когда запускать определенную задачу с помощью Ansible.
Использование когда с фактами
Вы можете использовать условные выражения when для запуска задачи, только если выполняется определенное условие. Для демонстрации создайте новую книгу воспроизведения с именем ubuntu-server.yml со следующим содержимым:
Теперь запустите playbook:
В выходных данных playbook обратите внимание, как TASK [Detect Ubuntu Servers] пропущены первые три узла, поскольку все они работают под CentOS и работают только на node4, поскольку он работает под управлением Ubuntu.
Использование when с регистрами
Идите вперед и запустите playbook:
Обратите внимание, как работает TASK [Detect CentOS Servers] только на первых трех узлах и пропускается node4 (Ubuntu).
Тестирование нескольких условий с помощью when
Вы также можете проверить несколько условий одновременно, используя логические операторы. Например, следующая перезагрузка-centos8.yml Playbook использует логический и оператора для перезагрузки серверов, работающих под управлением CentOS версии 8:
Вы также можете использовать логический оператор или для запуска задачи, если выполняется какое-либо из условий. Например, следующая задача будет перезагружать серверы , на которых работает CentOS или RedHat :
Использование when с петлями
Если вы объедините условный оператор when с циклом, Ansible проверит условие для каждого элемента в цикле отдельно.
Например, следующий сценарий print-even.yml напечатает все четные числа в диапазоне (1,11):
Продолжайте и запустите playbook, чтобы увидеть список всех четных чисел в диапазоне (1,11):
Использование when с переменными
Вы также можете использовать условные операторы when с вашими собственными определенными переменными. Помните, что условные выражения требуют логических входных данных; то есть, для срабатывания условия тест должен быть истинным, поэтому вам нужно использовать фильтр bool с небулевыми переменными.
Чтобы продемонстрировать это, взгляните на следующий сборник сценариев isfree.yml :
Обратите внимание, что здесь я использовал фильтр bool для преобразования значения on_call в его логический эквивалент (no -> false).
Вы также можете проверить, установлена ли переменная или нет; например, следующая задача будет выполняться, только если определена переменная car :
Следующая задача использует сбой модуля потерпеть неудачу , если ключи переменная не определена:
Обработка исключений с помощью блоков
Поговорим об обработке исключений.
Группировка задач с блоками
Вы можете использовать блоки для группировки связанных задач. Для демонстрации взгляните на следующую книгу install-apache.yml :
Playbook запускается на хостах группы веб-серверов и имеет один блок с именем Установить и запустить Apache, который включает в себя две задачи:
Обратите внимание, что в playbook есть третья задача, которая не принадлежит блоку Install and start Apache.
Обработка сбоев с помощью блоков
Вы также можете использовать блоки для обработки ошибок задач, используя разделы rescue и always. Это очень похоже на обработку исключений в языках программирования, таких как try-catch в Java или try-except в Python.
Вы можете использовать раздел восстановления, чтобы включить все задачи, которые вы хотите запустить в случае сбоя одной или нескольких задач в блоке.
Для демонстрации давайте взглянем на следующий пример:
Обратите внимание, как вторая задача в блоке run a bad command генерирует ошибку, и, в свою очередь, третья задача в блоке никогда не получает возможности запустить. Задачи внутри спасательной секции будут работать , потому что вторая задача в блоке не удалась.
Вы также можете использовать ignore_errors: yes, чтобы гарантировать, что Ansible продолжит выполнение задач в playbook, даже если задача не удалась:
Обратите внимание, что в этом примере вы проигнорировали ошибки во второй задаче в блоке run a bad command, и поэтому третья задача была запущена. Кроме того, спасательный раздел не будет работать , как вы игнорировали ошибку во второй задаче в блоке.
Вы также можете добавить в блок раздел всегда. Задачи в разделе всегда будут выполняться всегда, независимо от того, произошел сбой блока или нет.
Чтобы продемонстрировать это, взгляните на следующую книгу воспроизведения handle-errors.yml, в которой есть все три раздела блока (block, rescue, always):
Идите вперед и запустите playbook:
Запуск задач при изменении с помощью обработчиков
Посмотрим, как менять обработчики и запускать задачи.
Запуск вашего первого обработчика
Вы можете использовать обработчики для запуска задач при изменении на ваших управляемых узлах. Чтобы продемонстрировать это, взгляните на следующий сборник handler-example.yml:
Первая задача Create engineers groupсоздает группу инженеров, а также уведомляет обработчика add destroyer.
Давайте запустим сценарий, чтобы увидеть, что произойдет:
Обратите внимание, что создание инженеров вызвало изменение на node1 и в результате запустило add destroyerобработчик.
Вы также можете запустить быструю специальную команду, чтобы убедиться, что пользователь destroyer действительно является членом группы инженеров:
Плейбуки и модули Ansible являются идемпотентными, что означает, что если на управляемых узлах произошло изменение конфигурации; он больше не повторится!
Чтобы полностью понять концепцию идемпотентности Ansible; запустите playbook handler-example.yml еще раз:
Как вы видете; на этот раз Create engineers group задача не вызвала и не сообщила об изменении, потому что группа инженеров уже существует на node1 и, как результат; обработчик add destroyer не запустился.
Контроль, когда сообщать об изменении
Вы можете использовать ключевое слово changed_when, чтобы указать, когда задача должна сообщать об изменении. Чтобы продемонстрировать это, взгляните на следующий сценарий control-change.yml:
Обратите внимание, как первая задача Run the date commandзапускает handler1. А теперь запустите playbook:
Теперь давайте отредактируем playbook, чтобы задача не сообщала об изменениях:
Теперь снова запустите playbook:
Как видите, на этот раз задача не сообщила об изменении, и в результате handler1 не был запущен.
Настройка сервисов с обработчиками
Обработчики особенно полезны, когда вы редактируете конфигурации служб с помощью Ansible. Это потому, что вы хотите перезапустить службу только при изменении ее конфигурации службы.
Чтобы продемонстрировать это, взгляните на следующую инструкцию configure-ssh.yml :
Обратите внимание, что мы использовали модуль blockinfile для вставки нескольких строк текста в файл конфигурации /etc/ssh/sshd_config. Задача также вызывает обработчик restart ssh по изменению.
Идите вперед и запустите playbook:
Все хорошо! Теперь давайте быстро взглянем на последние несколько строк в файле/etc/ssh/sshd_config:
Удивительно! Точно так, как вы ожидали. Имейте в виду, что если вы повторно запустите playbook configure-ssh.yml, Ansible не будет редактировать (или добавлять) файл /etc/ssh/sshd_config. Вы можете попробовать это сами.
Мы также рекомендуем вам взглянуть на страницы документации blockinfile и lineinfile, чтобы понять различия и использование каждого модуля:
Хорошо! На этом мы подошли к концу нашей статьи по принятию решений в Ansible.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Читайте также: