Как запустить playbook ansible

Плейбук — Основы автоматизации в Ansible

Одним из основных понятий в Ansible является плейбук. Это просто yaml-файл, в котором мы указываем, какие задачи и на каких серверах будут выполняться. Пример такого файла playbook.yml:

# На какой группе серверов - hosts: webservers tasks: - name: install redis server # apt-get update && apt-get install redis-server ansible.builtin.apt: # имя модуля Ansible name: redis-server state: present update_cache: yes - name: remove redis server # apt-get remove redis-server ansible.builtin.apt: name: redis-server state: absent 

В этом плейбуке на группе хостов webservers выполняются две задачи (таски). Первая — это установка redis-server, и вторая — его удаление. Структура любой задачи такая:

• имя задачи — необязательный параметр, в котором описывается задача. Нужна только для вывода во время выполнения плейбука.
• модуль и его параметры – определяет команду, которая будет выполнена на указанной группе серверов. В примере выше это модуль apt, который запускает пакетный менеджер apt входящий в стандартную поставку Ubuntu. С его помощью устанавливаются и удаляются программы.

Имя модуля в задачах задается с префиксом ansible.builtin. Ansible позволяет создавать свои модули у которых имена могут совпадать со встроенными модулями. Поэтому разработчики ввели пространства имен, позволяющие избежать неоднозначностей (какой модуль имелся ввиду?).

Каждый модуль принимает параметры. В первой задаче три параметра:

• name: redis-server — имя пакета.
• state: present — состояние, в которое требуется привести модуль. Ansible убедится, что этот пакет есть, либо доустановит его.
• update_cache: yes — выполняет команду apt-get update для того, чтобы обновить информацию о пакетах в индексе. Во второй задаче обновлять индекс не требуется. Достаточно указать состояние state: absent , чтобы Ansible просто удалил redis-сервер.

В плейбуке может быть сколько угодно задач, но каждая задача работает только с одним модулем. Будьте внимательны.

Для запуска плейбука используется команда ansible-playbook , которой мы передаем путь к файлу playbook.yml и указываем inventory-файл:

# В отличие от ad-hoc режима, группа хостов указывается внутри плейбука ansible-playbook playbook.yml -i inventory.ini 

При запуске этой команды первая же задача упадет с ошибкой Failed to lock apt for exclusive operation. Из этой ошибки следует, что команда выполняется без прав администратора и не может выполнить установку программ. Чтобы это изменить, можно заходить на сервер под root, что очень часто неприемлемо, и так лучше не делать. Поэтому в Ansible существует механизм переключения пользователя уже внутри. Он называется become. В простейшем случае достаточно прописать become: yes в нужные задачи:

- hosts: webservers tasks: - name: install redis server ansible.builtin.apt: name: redis-server state: present update_cache: yes become: yes # - name: remove redis server ansible.builtin.apt: name: redis-server state: absent become: yes # 

По умолчанию become использует sudo и переключает в root, поэтому у вашего пользователя должны быть необходимые права. Если понадобится другой пользователь, то его можно указать в параметре become_user . Естественно необходимо чтобы у вашего пользователя было sudo. Теперь задача отрабатывает. Обновление индекса и установка занимает некоторое время:

[install redis server] ********************************* changed: [157.230.82.133] TASK [remove redis server] ********************************** changed: [157.230.82.133] 

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Ansible Playbook Пробный запуск Playbook Run в режиме проверки

Ansible — это инструмент автоматизации ИТ с открытым исходным кодом, используемый для управления конфигурацией, развертывания приложений и автоматизации задач. Это позволяет системным администраторам с легкостью управлять большим количеством серверов. Ansible Playbook — это мощная функция Ansible, которая позволяет пользователям автоматизировать задачи и управлять конфигурациями.

При создании Playbook важно протестировать и проверить его перед выполнением в производственных системах. Ansible предлагает функцию пробного запуска для запуска playbook в режиме проверки, которая позволяет пользователям имитировать выполнение playbook без внесения каких-либо фактических изменений. В этой статье объясняется, что такое пробный прогон и как его использовать с Ansible Playbooks.

Что такое пробный прогон в Ansible?

Пробный прогон — это симуляция выполнения playbook, которая проверяет, действительна ли playbook и будет ли она иметь запланированный эффект, если ее выполнить. Это способ проверить ваш Playbook без внесения каких-либо реальных изменений в системы.

При запуске Playbook в режиме пробного запуска Ansible выполняет те же проверки, что и при обычном выполнении, но не вносит никаких изменений в системы. Вместо этого он показывает, какие изменения были бы внесены, если бы playbook был выполнен.

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

Как запустить Playbook в режиме проверки

Запустить плейбук в режиме проверки довольно просто. Все, что вам нужно сделать, это использовать флаг —check при запуске команды ansible-playbook. Флаг —check сообщает Ansible запустить playbook в режиме пробного запуска.

Вот пример того, как запустить playbook в режиме проверки:

$ ansible-playbook playbook.yml --check 

В этом примере мы запускаем плейбук playbook.yml в режиме проверки.

Если в плейбуке нет ошибок, Ansible отобразит сообщение о том, что плейбук успешно запущен в режиме проверки. Если в playbook есть ошибки, Ansible отобразит сообщение об ошибке, указывающее, что пошло не так.

Использование флага —diff

В дополнение к флагу —check вы также можете использовать флаг —diff для отображения различий между текущим состоянием систем и состоянием, которое было бы достигнуто при выполнении плейбука.

Вот пример использования флага —diff —

$ ansible-playbook playbook.yml --check --diff 

В этом примере мы запускаем плейбук playbook.yml в режиме проверки и отображаем различия между текущим состоянием систем и состоянием, которое было бы достигнуто, если бы плейбук был выполнен.

Флаг —diff может оказаться весьма полезным при отладке плейбуков, поскольку он может помочь выявить любые непреднамеренные изменения, которые могут произойти, если плейбук будет выполнен.

Использование флага —list-tasks

Еще один полезный флаг при запуске плейбука в режиме проверки — флаг —list-tasks. Этот флаг отображает задачи, которые были бы выполнены, если бы выполнялась книга воспроизведения, без их фактического выполнения.

Вот пример использования флага —list-tasks:

$ ansible-playbook playbook.yml --check --list-tasks 

В этом примере мы запускаем playbook.yml playbook в режиме проверки и отображаем задачи, которые были бы выполнены, если бы playbook был выполнен.

Флаг —list-tasks может быть полезен при попытке понять, какие задачи будет выполнять плейбук, не выполняя их фактически.

Использование флага —limit

Флаг —limit используется для ограничения выполнения playbook определенным набором систем. Это может быть полезно при тестировании Playbooks на подмножестве ваших систем.

Вот пример использования флага —limit –

$ ansible-playbook playbook.yml --check --limit server1 

В этом примере мы запускаем playbook playbook.yml в режиме проверки, но ограничиваем выполнение только системой server1.

Флаг —limit может быть весьма полезен при тестировании Playbooks на определенном наборе систем, не затрагивая другие системы.

Использование флага —tags

Флаг —tags используется для ограничения выполнения книги действий определенными задачами, помеченными указанным тегом. Это может быть полезно при тестировании конкретных задач в Playbook.

Вот пример использования флага —tags:

$ ansible-playbook playbook.yml --check --tags web 

В этом примере мы запускаем playbook playbook.yml в режиме проверки, но ограничиваем выполнение только задачами, помеченными веб-тегом.

Флаг —tags может быть полезен при тестировании определенных задач в плейбуке без выполнения всех задач в плейбуке.

Использование флага —skip-tags

Флаг —skip-tags используется для пропуска выполнения определенных задач, помеченных указанным тегом. Это может быть полезно при тестировании сборников пьес, в которых есть определенные задачи, которые вы хотите пропустить.

Вот пример использования флага —skip-tags:

$ ansible-playbook playbook.yml --check --skip-tags db 

В этом примере мы запускаем playbook playbook.yml в режиме проверки, но пропускаем выполнение задач, помеченных тегом db.

Флаг —skip-tags может быть полезен при тестировании плейбуков, в которых есть определенные задачи, которые вы хотите пропустить, не затрагивая другие задачи в плейбуке.

Дополнительные преимущества

Дополнительные преимущества режима пробного запуска Ansible Playbook включают в себя:

• Безопасное тестирование сборников сценариев. Запуск сборников сценариев в режиме проверки позволяет вам проверять выполняемые задачи и подтверждать их безопасность перед фактическим применением изменений в ваших системах. Это помогает избежать непредвиденных проблем и простоев.
• Отладка сборников сценариев. Режим пробного запуска также полезен при отладке сборников сценариев, поскольку позволяет выявлять и устранять проблемы без фактического внесения каких-либо изменений в ваши системы.
• Проверка соответствия. Если в вашей организации действуют строгие правила соответствия, важно протестировать ваши Playbooks в режиме проверки, чтобы убедиться, что они соответствуют требованиям соответствия, прежде чем развертывать их в рабочей среде.
• Уверенность в изменениях. Режим пробного запуска Ansible Playbook обеспечивает дополнительный уровень уверенности в изменениях, вносимых в ваши системы. Это гарантирует, что изменения не окажут негативного воздействия на ваши системы.

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

В дополнение к преимуществам, упомянутым выше, режим пробного запуска Ansible Playbook также предоставляет следующие преимущества:

• Экономия времени. Запуск Playbooks в режиме проверки может сэкономить время, избегая ненужных изменений в ваших системах. Это позволяет вам тестировать ваши Playbooks без внесения каких-либо реальных изменений, поэтому вы можете обнаружить ошибки на раннем этапе и внести исправления перед развертыванием Playbook в ваших системах.
• Повышенная точность. Режим пробного запуска помогает гарантировать точность ваших сборников сценариев и не приведет к непреднамеренным изменениям в ваших системах. Проверяя изменения до их применения, вы можете избежать ошибок, которые могут привести к простою или другим негативным последствиям для ваших систем.
• Простота в использовании. Режим пробного запуска Ansible Playbook прост в использовании и требует минимальной настройки. Все, что вам нужно сделать, это добавить флаг —check к вашей команде ansible-playbook, и Ansible запустит вашу книгу воспроизведения в режиме проверки.
• Совместимость. Режим пробного запуска Ansible Playbook совместим с широким спектром систем, включая Linux, macOS и Windows. Это делает его универсальным инструментом, который можно использовать для управления различными типами систем.
• Масштабируемость. Режим пробного запуска Ansible Playbook можно использовать для одновременного управления сотнями или даже тысячами систем. Это делает его идеальным для крупномасштабных ИТ-операций, требующих автоматизации и управления большим количеством систем.

Заключение

Режим пробного запуска или проверки Ansible Playbook — это важная функция, которая позволяет пользователям тестировать и проверять свои Playbooks перед их выполнением в производственных системах. Используя эту функцию, пользователи могут быть уверены, что их Playbooks не содержат ошибок, не вызывают непреднамеренных изменений и работают должным образом. В этой статье мы объяснили, что такое пробный прогон и как его использовать с Ansible Playbooks. Мы также рассмотрели несколько полезных флагов, которые можно использовать при запуске плейбука в режиме проверки. Используя эти флаги, пользователи могут ограничить выполнение playbook конкретными системами, задачами или тегами и отображать различия между текущим состоянием и состоянием, которое было бы достигнуто, если бы playbook был выполнен. В целом, функция пробного запуска — это мощный инструмент, который может помочь пользователям сэкономить время и избежать дорогостоящих ошибок.

Все права защищены. © Linux-Console.net • 2019-2023

Практика с удаленным управлением серверами при помощи Ansible

Статья также доступна на украинском (перейти к просмотру).

Оглавление

• Основные концепции Ansible Playbooks
• Реализация проекта
• Формирование задач
• Создание структуры каталогов и файлов
• Создание Inventory
• Проверка настроек и тестирования соединения
• Формирование директив файла playbook
• Тестирование файла playbook перед запуском
• Запуск и выполнение
• Выборочное тестирование результатов выполнения

В статье «Инструмент автоматизации Ansible» нами были рассмотрены основные концепции удаленного управления узлами сети с помощью Ansible и начальная настройка управляющего узла на ОС Ubuntu. В этой работе мы реализуем процесс автоматизированной начальной настройки серверов Ubuntu с использованием Ansible Playbooks.

Основные концепции Ansible Playbooks

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

• Объявлять конфигурации;
• Формировать шаги любого упорядоченного вручную процесса в нескольких группах узлов в определенной последовательности;
• Запускать для выполнения задачи синхронно или асинхронно.

Перечислим общие концепции правильного использования этого механизма.

Для описания задач и конфигураций целесообразно использовать язык YAML как имеющий более простой и понятный синтаксис по сравнению с, например, языком JSON. Для лучшего восприятия спецификаций проекта желательно разделить элементы файла playbook.yml пустой строкой. Применять комментирование перед каждым блоком или задачей. Это значительно ускорит дальнейшее их редактирование.

Предварительно продумать организацию имен в проекте. Каждая задача, блок или модуль должны иметь согласованные названия. Ansible имеет множество разнообразных функций и их расширений, что позволяет реализовать полноценный проект любой сложности. Однако здесь нужно опираться на принцип: чем проще, тем совершеннее. Это позволит избежать излишнего усложнения проекта.

Целесообразно сохранить свои проекты в любой из систем контроля версий. Это позволит эффективнее управлять ими в дальнейшем.
Для хранения конфиденциальной информации проекта лучше использовать методы шифрования текстовых данных Ansible Vault.
Во избежание многих ошибок желательно проводить постоянное тестирование проекта на всех этапах его подготовки разнообразными сервисами – Ansible Lint, assert и другие.

Реализация проекта

Реализация нашего проекта по начальной настройке серверов Ubuntu включает в себя несколько стадий. Перечислим их:

• Формирование задач;
• Создание структуры каталогов и файлов;
• Создание Inventory;
• Проверка настроек и тестирования соединения;
• Формирование директив файла playbook;
• Тестирование перед запуском;
• Запуск и исполнение;
• Выборочное тестирование результатов выполнения.

Формирование задач

Набор формируемых задач должен реализовать основную цель проекта – начальную настройку удаленных узлов, работающих на ОС Ubuntu 22. Согласно этому, такой набор будет выглядеть следующим образом:

• Установка менеджера пакетов aptitude, который более приспособлен для работы с Ansible по сравнению с apt;
• Создание и настройка администраторской группы для пользователей с правами sudo;
• Создание нового пользователя с соответствующими правами;
• Обеспечение возможности входа нового пользователя на каждый из узлов по ключу SSH;
• Отключение аутентификации на основе пароля пользователя root;
• Настройка брандмауэра UFW;
• Установка системных пакетов.

Создание структуры каталогов и файлов

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

Вариант первый. Репозиторий do-community/ansible-playbooks используется в первый раз. Тогда нужно клонировать его в локальную директорию узла управления Ansible. Это можно сделать с помощью следующей команды:

$ git clone https://github.com/do-community/ansible-playbooks.git

После чего перейти в соответствующую директорию:

$ cd ansible-playbooks

Вариант второй. Репозиторий был клонирован раньше. В этом случае необходимо получить доступ к существующей копии ansible-playbook и обновить содержимое репозитория с помощью соответствующей команды:

$ cd ansible-playbooks

В нашем случае, вместо названия ansible-playbooks для репозитория использовано название ansible.

После этого можно начинать создавать структуру каталогов. В первую очередь, создадим директорию нашего проекта с названием setup_all_node_ubuntu:

$ mkdir /etc/ansible/setup_all_node_ubuntu

После этого создадим директорию для хранения файла общих параметров для всех задач:

Создадим файл def.yml общих параметров с помощью редактора nano и добавим в него следующие записи:

create_user: admin copy_local_key: ">" sys_packages: [ 'curl', 'vim', 'git', 'ufw']

Первая запись определяет имя пользователя (admin), под которым будет производиться вход на удаленные узлы.

Вторая запись задает функции поиска и копирования и путь доступа к файлу с открытым ключом SSH. Согласно этому указанный ключ будет помещен в файл ~.ssh/authorized_keys для учетной записи admin для всех узлов.

Третья запись конкретизирует названия системных пакетов для установки.

Введем в терминале:

$ nano /etc/ansible/setup_all_node_ubuntu/all_vars/def.yml

Содержимое файла показано ниже.

Сохраним результат и выйдем из редактора (Ctrl+O, Ctrl+X).

Ключ SSH был сгенерирован нами незадолго до этого с помощью команды:

$ ssh-keygen

Подходящий закрытый ключ id_rsa находится в той же директории, что и открытый. Следует отметить, что указанный ключ был создан специально для учетной записи пользователя admin удаленных узлов и поэтому во избежание путаницы желательно такие ключи хранить в отдельно созданных каталогах или затем переименовать их с помощью команды rename.

Создание Inventory

В терминологии Ansible во Inventory понимается список удаленных узлов вместе с параметрами для входа. Местонахождение списка: /etc/ansible/hosts. Сформируем его:

$ sudo nano /etc/ansible/hosts

В открывшемся окне редактору внесем в файл соответствующие изменения.

Мы создали группу webservers, в которую внесли только один хост с именем server1. С помощью параметра ansible_host указали IP-адрес хоста и пароль доступа по SSH-соединению. В разделе all:vars мы можем указать любые общие параметры доступа для всех групп хостов. Например, имя пользователя, если оно одинаково для всех хостов. Мы также можем указать параметры отдельно для любой группы или хоста. Для этого достаточно ввести их в блоке под названием хоста или группы, взятой в квадратные скобки, например [server1]. После внесения изменений сохраним данные и выйдем из редактора.

Проверка настроек и тестирования соединения

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

$ ansible all --list-hosts

С помощью этой команды мы проверили список хостов, идентифицированный программой. Он совпадает с нашим списком – server1.

Далее, введем в терминале:

$ ansible-inventory --list -y

Здесь мы проверили полный список групп, хостов и правильность входных параметров. Как можно убедиться, он полностью отвечает действительности.

Теперь установим первое соединение с хостами из списка. Это позволит избежать в дальнейшем задержек в работе из-за необходимости подтверждения согласия на соединение, поскольку эти узлы уже будут идентифицированы ОС Ubuntu, как разрешенные. Для этого введем следующую команду:

$ ssh root@178.20.157.79

Ubuntu предлагает подтвердить достоверность хоста, что мы и делаем, набрав yes.

Как можно убедиться из сообщения на последнем ящике, адрес хоста из списка inventory был внесен в список разрешенных хостов Ubuntu, как мы и хотели.

Проверим это с помощью той же команды:

$ ssh root@178.20.157.79

Теперь сразу же предлагается ввести пароль, то есть хост идентифицирован. После ввода пароля происходит подключение, как показано ниже.

Закроем сеанс соединения с удаленным узлом с помощью команды exit и вернемся к управлению управляющим узлом.

Только после этого можно начинать тестирование соединения уже с помощью Ansible. Введем в терминале:

$ ansible all –m ping

В результате пингования команда вернула ответ «pong», то есть соединения со всеми хостами из списка Inventory являются работоспособными и могут быть использованы для управления узлами с помощью Ansible.

Мы теперь можем более подробно исследовать состояние каждого из хостов. Например, проверим состояние дисковых ресурсов на каждом из хостов:

$ ansible all -a "df -h"

Также теперь мы можем проверить время безотказной работы каждого из хостов или какого-то отдельного. Для этого введем команду:

$ ansible server1 -a "uptime"

Можно убедиться, что нам это удалось. Теперь можно переходить к формированию директив файла playbook.

Формирование директив файла playbook

Целесообразно в структуре проекта иметь несколько файлов директив с разными названиями. В нашем случае указанный файл будет называться playbook_one.yml. Сформируем его содержание в соответствии с задачами.

--- - hosts: all become: true vars_files: - all_vars/def.yml tasks: - name: Install package manager apt: name=aptitude update_cache=yes state=latest force_apt_get=yes # Group - name: Create admin group 'main' group: name: main state: present - name: Setting privileges sudo no passwd for 'main' lineinfile: path: /etc/sudoers state: present regexp: '^%main' line: '%main ALL=(ALL) NOPASSWD: ALL' validate: '/usr/sbin/visudo -cf %s' # User remote ubuntu - name: Create a new user ubuntu with rights sudo user: name: ">" state: present groups: main append: true create_home: true shell: /bin/bash - name: Setting up an authorization key for a user ubuntu authorized_key: user: ">" state: present key: ">" - name: Setting up root authentication without a password lineinfile: path: /etc/ssh/sshd_config state: present regexp: '^#?PermitRootLogin' line: 'PermitRootLogin prohibit-password' # UFW - name: Set permission to connect via SSH ufw: rule: allow name: OpenSSH - name: Deny any other connections ufw: state: enabled policy: deny direction: incoming # Packages - name: Update apt apt: update_cache=yes - name: Installing packages for the system apt: name=> state=latest

Директивы сформированы в соответствии с рекомендациями, приведенными нами в начале статьи. Каждая из задач имеет свое название, комментарий и т.д. Главный принцип, который мы придерживались, это максимальное упрощение проекта. Этому также способствовало наличие только одной группы серверов с одинаковыми параметрами. Теперь сформируем соответствующий файл с помощью следующей команды:

$ nano /etc/ansible/setup_all_node_ubuntu/playbook_one.yml

Сохраним файл и вернемся к терминалу.

Тестирование файла playbook перед запуском

Такое тестирование помогает избавиться от многих ошибок в playbook, в том числе и синтаксических. Одним из самых мощных механизмов для этого является модуль ansible-lint, который может быть установлен с помощью соответствующей команды. Введем в терминале:

$ apt install ansible-lint

Теперь мы можем использовать установленное приложение для тестирования нашего файла playbook. Для этого запустим команду:

$ ansible-lint /etc/ansible/setup_all_node_ubuntu/playbook_one.yml

Результат выполнения команды показан ниже.

Для анализа и устранения ошибок в директивах можно воспользоваться справочной информацией по программе по ссылке: ansible-lint default rules.

Кроме указанного выше механизма, для проверки корректности директив playbook еще до его запуска может использоваться команда их запуска ansible-playbook с соответствующими параметрами. Это следующие параметры: —list-tasks, —diff, —syntax-check, —check и —list-hosts. Например, просмотрим доступный для программы список задач.

ansible-playbook /etc/ansible/setup_all_node_ubuntu/playbook_one.yml --list-tasks

Можно убедиться в том, что набор задач идентифицирован правильно. Теперь проверим синтаксис:

Результат проверки – с синтаксисом в нашем playbook все хорошо.

Существуют и другие инструменты для проверки и тестирования директив. Они подробно описаны в документации Ansible: Validating Playbooks.

Запуск и выполнение

После прохождения всех проверок и устранения ошибок файл с директивами может быть запущен на выполнение. Для этого введем:

ansible-playbook /etc/ansible/setup_all_node_ubuntu/playbook_one.yml -l server1

Параметр -l происходит от limit, то есть ограничен. Это означает, что он позволяет указать только отдельные хосты или группы, которые иногда бывают необходимыми. В нашем случае указан один хост server1.

Результат выполнения команды показан ниже.

Судя по результатам, выполнение сценария на удаленном узле прошло успешно и соответствующие изменения на узлах произошли.

Выборочное тестирование результатов выполнения

Для выборочной проверки результатов внесенных изменений на удаленных узлах откроем сеанс соединения от имени нового пользователя с именем admin:

$ ssh admin@178.20.157.79

Можем убедиться, что соединение произошло, то есть создание нового пользователя прошло успешно. Теперь проверим статус брандмауэра на удаленном хосте:

$ sudo ufw status

Результат: настройка UFW успешно выполнена. А это была одна из последних задач сценария, говорящая о том, что сценарий выполнен полностью.

Дата-центр FREEhost.UA предоставляет качественный хостинг VDS и услуги аренды серверов с поддержкой 24/7. На нашем сайте Вы можете подобрать сервер для аренды под любые задачи.

Подписывайтесь на наш телеграм-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.

Смотрите наш канал Youtube на https://www.youtube.com/freehostua.
Мы в чем-то ошиблись, или что-то пропустили?

Напишите об этом в комментариях на сайте и в телеграм-канале. Мы с удовольствием ответим и обсудим Ваши замечания и предложения.

Использование Ansible Playbooks

В инструкции описано применение и работа с Ansible Playbook, а также кратко рассмотрена их структура.

Что такое Ansible Playbooks?

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

Часто плейбуки используют для выполнения начальной настройки серверов – добавления пользователей и каталогов, управлением пакетами программного обеспечения и файлами.

Playbook – это YAML-файл, который обычно имеет следующую структуру:

--- - hosts: [target hosts] remote_user: [yourname] tasks: - [task 1] - [task 2]

Например, следующий playbook будет входить на все серверы группы marketingservers и обеспечивать запуск веб-сервера Apache:

--- - hosts: [marketingservers] remote_user: webadmin tasks: - name: Ensure the Apache daemon has started service: name=httpd state=started become: yes become_method: sudo

В плейбуке выше приведен пример задания (task):

tasks: - name: Ensure the Apache daemon has started service: name=httpd state=started become: yes become_method: sudo

Каждое задание должно иметь имя, которое впоследствии регистрируется и может помочь отслеживать прогресс. После строки имени (name) находится модуль, который будет запущен, в данном случае это служебный модуль. Другие атрибуты разрешают больше опций, в примере Ansible разрешается использовать привилегии sudo.

Запуск Ansible Playbook

Запустить готовый плейбук можно используя следующую команду:

ansible-playbook playbook.yml
ansible-playbook nginx.yml

Однако, если есть необходимость отфильтровать список хостов, чтобы сценарий применялся только к одному из этих хостов, можно добавить флаг и указать подмножество хостов в файле:

ansible-playbook -l host_subset playbook.yml
ansible-playbook -l host3 nginx.yml

Регистрация результатов

Когда вы устанавливаете и настраиваете службы вручную, почти всегда необходимо знать результат действий. Настроить эту функциональность можно с помощью регистрации.

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

Таким образом, если необходимо проверить, выполнилась ли задача или нет и принять решение о последующих шагах, необходимо использовать функциональность регистрации.

Например, укажем playbook загрузить файл index.php, если он существует. Если эта задача не выполнится, то начнется загрузка файла index.html:

--- - hosts: droplets tasks: - name: Installs nginx web server apt: pkg=nginx state=installed update_cache=true notify: - start nginx - name: Upload default index.php for host copy: src=static_files/index.php dest=/usr/share/nginx/www/ mode=0644 register: php ignore_errors: True - name: Remove index.html for host command: rm /usr/share/nginx/www/index.html when: php|success - name: Upload default index.html for host copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644 when: php|failed handlers: - name: start nginx service: name=nginx state=started

Этот сценарий пытается загрузить файл PHP на хост. Ansible регистрирует успех операции в переменной с именем php. Если эта операция прошла успешно, следующая задача – удалить файл index.html. Если операция завершилась неудачно, будет загружен файл index.html.