Перейти к содержимому

Ansible galaxy что это

  • автор:

Коллекции — Основы автоматизации в Ansible

Коллекции в Ansible — формат распространения связанного набора плейбуков, ролей, модулей и плагинов. Он появился после того, как количество встроенных модулей внутрь Ansible стало настолько огромным, что их поддержка резко усложнилась. Все встроенные модули перенесли в коллекции Ansible Collections . Часть этих модулей распространяются с Ansible сразу, другие же устанавливаются как роли через Ansible Galaxy.

Список установленных коллекций можно посмотреть так:

# Не полный вывод Collection Version ----------------------------- ------- amazon.aws 2.1.0 ansible.netcommon 2.5.0 ansible.posix 1.3.0 ansible.utils 2.4.3 ansible.windows 1.9.0 cloud.common 2.1.0 community.crypto 2.1.0 community.digitalocean 1.14.0 community.dns 2.0.4 community.docker 2.1.1 community.general 4.3.0 community.google 1.0.0 community.grafana 1.3.0 community.kubernetes 2.0.1 community.mongodb 1.3.2 community.network 3.0.0 community.postgresql 1.6.0 community.rabbitmq 1.1.0 community.skydive 1.0.0 community.vmware 1.17.0 community.windows 1.9.0 community.zabbix 1.5.1 containers.podman 1.9.0 google.cloud 1.0.2 hetzner.hcloud 1.6.0 kubernetes.core 2.2.2 

Коллекция ansible.builtin здесь не указана, так как это единственная коллекция модулей, встроенная прямо в ядро Ansible.

Принцип именования коллекций такой же как и у ролей. Первая часть — неймспейс, вторая имя коллекции. Но в отличие от роли, у коллекций есть и третье имя, модуль, который используется. Посмотрим на примере базы данных PostgreSQL. Ниже задача, которая управляет базой данных :

- hosts: all tasks: - name: Создание новой базы данных community.postgresql.postgresql_db: name: hexlet-development - name: Создание дампа существующей базы данных community.postgresql.postgresql_db: name: hexlet-production state: dump target: /tmp/hexlet.production.sql 

Или другой пример — управление таблицами в существующей базе данных:

- hosts: all tasks: - name: Создание таблицы community.postgresql.postgresql_table: db: hexlet-development name: users 

PostgeSQL поставляется вместе с Ansible, поэтому его можно использовать напрямую, как и остальные коллекции из списка выше. Если коллекция не входит в стандартную поставку, то ее можно установить через ansible-galaxy . Ниже пример с Nginx .

install nginxinc.nginx_core 

Коллекция nginxinc.nginx_core содержит внутри набор ролей, для установки и настройки Nginx. Для примера:

- hosts: all roles: # Установка Nginx - nginxinc.nginx_core.nginx 

Или более сложный вариант , с конфигурацией.

Автоматическая установка

Ansible поддерживает автоматическую установку коллекции по такому же принципу как это делается с ролями. Для этого создается файл requirements.yml, например, в том месте где запускается ansible . Туда добавляется список нужных коллекций:

collections: # Install a collection from Ansible Galaxy - name: geerlingguy.php_roles version: 0.9.3 

Затем выполняется установка:

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

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

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

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

Эффективная разработка и сопровождение Ansible-ролей

In case of using different SCM the most important aspects are: correct work of target configuration, simplicity lifecycle support of DSL code written for target SCM and having different tests for things which is under control of SCM. This article shows more efficient way for development, testing and support for Ansible-roles; including continuous integration, code-review, guideline compliance.

Глоссарий

Ansible — система управления конфигурациями, написанная на Python, с использованием декларативного языка разметки для описания конфигураций.
Molecule – программное обеспечение (ПО), созданное для разработки и тестирования Ansible ролей в различных средах.
Ansible Galaxy – вебсайт, где пользователи могут публиковать роли для совместного использования, а также инструмент командной строки для установки, создания и управления ролями.
GitHub, GitLab – сайт и система управления репозиториями кода для Git.
GitLab Runner – часть GitLab проекта, используемая для процессов непрерывной интеграции и непрерывной доставки.
Travis-CI – веб-сервис для сборки и тестирования различного программного обеспечения, использующий GitHub в качестве хостинга исходного кода.

Введение

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

  • Низкий порог вхождения
  • Обширная документация
  • Простота расширения сторонними модулями
  • Отсутствие агентов на конечных машинах
  • YAML в качестве DSL

Ansible и повторное использование кода

Так называемые роли – родной механизм для повторного использования кодовой базы. Роль представляет собой отдельно выделенный, самостоятельный фрагмент кода, который приведет целевую систему в ожидаемое состояние.
Galaxy веб-сайт (https://galaxy.ansible.com) представляет собой витрину готовых ролей, уже разработанных кем-либо.
Ansible роль может быть как импортирована с galaxy (ansible-galaxy install .) так и создана с нуля (ansible-galaxy init).
Типовая структура роли, созданной при помощи ansible-galaxy

├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── README.md ├── tasks │ └── main.yml ├── templates └── vars └── main.yml

В рамках данной структуры и описываются все необходимые действия по приведению части системы в ожидаемое состояние.
После финализации данной роли можно осуществить публикацию её на GitHub с последующим импортом в ansible-galaxy. Но при такой упрощенной системе публикации нет никакого процесса контроля качества данной роли.

Соответствие стилевым рекомендациям

Одним из самых простых механизмов проверки качества кода является использование статического анализатора кода. Наиболее эффективными инструментами для Ansible являются:

  • yamllint (https://pypi.org/project/yamllint/)
  • ansible-lint (https://pypi.org/project/ansible-lint/)

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

Платформа для тестирования

Для тестирования Ansible ролей, на сегодняшний день, molecule является наиболее удобным инструментом. Который, в свою очередь поддерживает множественные интеграции с различными средами, которые могут выступать в роли целевых платформ; такие как: Docker, AWS , Microsoft Azure, Google Cloud Platform и др.
Интегрировать molecule-тесты можно в любой момент, выполнив инициализацию нового тестового сценария (molecule init scenario -r ). После данной инициализации будет создана структура для тестов с параметрами по умолчанию (galaxy – для решения зависимостей, docker – как целевая платформа для разворачивания тестовой среды, default – как имя тестового сценария, testinfra – как тестовый фреймворк для проведения интеграционных тестов).
Типовая структура роли после инициализации тестового сценария molecule:

├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── molecule │ └── default │ ├── Dockerfile.j2 │ ├── INSTALL.rst │ ├── molecule.yml │ ├── playbook.yml │ └── tests │ └── test_default.py ├── README.md ├── tasks │ └── main.yml ├── templates └── vars └── main.yml

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

Непрерывная интеграция (CI)

Travis-CI является одной из самых доступных систем непрерывной интеграции для проектов с открытым исходным кодом. Для подключения данной системы достаточно просто разместить файл .travis.yml в корне репозитория и активировать CI на веб-сайте https://travis-ci.org

Содержимое .travis.yml файла для вышеописанной роли может быть следующем:

--- dist: xenial sudo: required language: python python: - "2.7" services: - docker before_install: - git clone -b $ https://github.com/lean-delivery/ansible-lint-rules.git ~/ansible-lint-rules install: - pip install --upgrade ansible==2.5.5 ansible-lint==3.4.21 docker-py==1.10.6 molecule==2.13.1 pyOpenSSL PyYAML==3.12 - ansible --version - molecule --version script: - ansible-lint -c .ansible-lint `find . -regex ".*\.\(yml\)"` - molecule test notifications: webhooks: https://galaxy.ansible.com/api/v1/notifications/

После активации CI при последующем изменении кода в репозитории запустится процесс тестирования в рамках вышеописанного molecule-сценария:

Иногда бывает необходимо проводить тестирование в непубличных средах. Например, вы хотите провести тестирование не только в докере, но и в других облачных сервисах, при этом вы хотите препятствовать утечке API ключа, который понадобится для запуска тестовых сред. В этом случае можно использовать немного более сложную топологию интеграции и подключить GitLab CI к GitHub репозиториям.
Для этого вам необходимо на веб-сайте https://gitlab.com подключить ваш GitHub репозиторий как “CI/CD for external repo”. После этого у вас появится зеркало вашего репозитория, цель которого лишь запускать ваш код на сборку и тестирование, руководствуясь инструкциями из файла .gitlab-ci.yml. В данном случае CI топология будет аналогична CI с использованием Travis-CI, за исключением возможности подключения GitLab Runner, который размещается в вашей приватной сети (возможность использовать публичные GitLab Runner остаётся).

Вместо заключения

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

Полезные ссылки

  1. Molecule
  2. Примеры Ansible ролей
  3. Интеграция GitLab CI и GitHub
  4. Travis-CI
  5. Дополнительные ansible-lint правила

Abstract licensed under Creative Commons Attribution-ShareAlike 3.0 license

Команда ansible-galaxy: опции, ключи и примеры использования

Общие команды – Общие команды, присущие различным операционным системам.

ansible-galaxy

  • Install a role:
  • List installed roles:
  • Search for a given role:
  • Create a new role:

Изображение Выучи 10 хороших привычек для работы в UNIX от IBM

Примеры кода, демонстрирующие общие подходы в программировании или же решающие небольшие прикладные задачи. Языки программирования и библиотеки, позволяющие эффективно решать задачи разработки. Объектно-ориентированное программирование, функциональное программирование и прочие подходы и …

Фото Код

Трюки Bash

Полезные заметки по работе с командной строкой: bash и прочие *sh. Однострочники, скрипты, позволяющие решать большие и малые задачи администрирования и настройки Юникс систем. Zsh для современного MacOS, Bash для …

Фото Трюки Bash

Заметки о настройке различных IT-штуковин. Настройка, допиливание, полировка. Конфигурируем приложения и тюнингуем сервера. Полезные параметры и ключи запуска программ. Увеличиваем скорость, уменьшаем отклик, ускоряем работу и улучшаем результаты работы. Объясняем …

Фото Настройки

Терминал/Консоль

Команды и инструкции терминала (консоли) Linux, MacOS, Windows и прочих операционных систем. Трюки и особенности командных оболочек, скрипты для администрирования Unix. Программирование и скриптование Windows и Linux, тонкая настройка Macos. …

Фото Терминал/Консоль

Также может быть вам интересно:

  • Как получить дерево директорий на Bash одним однострочником
  • Python: Функции
  • Python: Встроенные типы данных (list, set, dict, etc)
  • Python: типы данных, переменные, логическое ветвление и циклы
  • Как сделать свою middleware в Django (с примерами)

Свежее на «Цифре»
MessageId или как дебажить систему с минимумом проблем
Программы, 09.09.2023
Проверочный список для выпуска промышленных приложений с иллюстрациями
Работа и управление, 30.07.2023
В Google Pixel и Windows Snipping Tool есть возможность восстановления обрезанных изображений
Новости, 23.03.2023
Два подарка «под ёлочку» от Heroes of Might and Magic
Новости, 25.12.2022
Вышел Pulsar – редактор кода на основе Atom
Новости, 25.12.2022
Ленивый backup PostgreSQL
Программы, 17.12.2022
Google анонсировала OSV-Scanner: сканер уязвимостей в программных проектах
Новости, 16.12.2022

Фото Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

На днях группа бывших разработчиков Gitea решили создать на базе хостинга кода Gitea свою версию проекта – «Forgejo». Причиной тому …

Фото Пользователи и их создание в Django - своя регистрация на сайте

Пользователи и их создание в Django — своя регистрация на сайте

Если вашим сайтом должны активно пользоваться несколько человек, то полезно их различать, а значит — надо уметь создавать пользователей, либо …

Фото Новый синтаксис старой команды with в Python 3.10

Новый синтаксис старой команды with в Python 3.10

Как же долго моё чувство прекрасного страдало… Но в Python 3.10 появился новый парсер синтаксических конструкций Python!

Фото Добавляем постраничную пагинацию на Django сайт

Добавляем постраничную пагинацию на Django сайт

На сайтах часто встречаются многостраничные объекты: список товаров, список заметок и т.д. Поэтому важно уметь добавить навигацию по страницам на …

Фото Новый оператор match-case в Python

Новый оператор match-case в Python

В новой версии Python (3.10) появится новый оператор. Новый оператор сопоставления по шаблону (match-case).

Фото Нет слов, одни. однострочники

Нет слов, одни. однострочники

На днях вышел пост со списком полезных однострочников для JavaScript программистов. Памятуя Perl-овую молодость, заглянул туда.

Фото Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если …

Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать …

Фото Разграничение прав доступа на Django сайте

Разграничение прав доступа на Django сайте

Почти на любом веб-сайте необходимо разделять пользователей на группы и предоставлять им разные возможности. В Django есть довольно серьёзная система …

Знакомство с Ansible. Часть 5. Примеры использования Ansible Galaxy

Мы с вами уже очень кратко познакомились с Ansible – поговорили о том, что это вообще такое, разобрались с базовыми основами его использования. В последней публикации про Ansible мы с вами разобрали даже не самый простой пример playbook. В заключении цикла статей про Ansible я расскажу о том, что такое Ansible Galaxy.

Что такое Ansible Galaxy

Ansible Galaxy – это еще один инструмент Ansible, которые еще дальше автоматизирует и упрощает использование этого инструмента. Основная черта Ansible Galaxy – использование ролей. Например, мы говорим, что на определенной группе хостов нужно установить стэк LAMP. И все – все остальные заботы берет на себя Ansible Galaxy.

Как я уже сказал ранее Ansible Galaxy использует концепцию ролей, т.е. вы указываете ему какие роли должны быть настроены на хосте (или группе) хостов и Ansible Galaxy выполняет всю необходимую работу. Ролей можно указать несколько, тогда Ansible Galaxy выполнит настройку всех ролей из списка.

Для работы с Ansible Galaxy используется одноименная утилита командной строки:

ansible-galaxy -h
roman@ansible:~$ ansible-galaxy -h usage: ansible-galaxy [-h] [--version] [-v] TYPE . Perform various Role and Collection related operations. positional arguments: TYPE collection Manage an Ansible Galaxy collection. role Manage an Ansible Galaxy role. options: --version show program's version number, config file location, configured module search path, module location, executable location and exit -h, --help show this help message and exit -v, --verbose Causes Ansible to print more debug messages. Adding multiple -v will increase the verbosity, the builtin plugins currently evaluate up to -vvvvvv. A reasonable level to start is -vvv, connection debugging might require -vvvv. roman@ansible:~$ 

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

Простой пример использования Ansible Galaxy

В этом примере я буду использовать файл инвентаризации вот из этой предыдущей публикации.

Далее предлагаю перейти к самому простому сценарию использования Ansible Galaxy. В этом примере использую Ansible Galaxy я выполню установку Apache.

Непосредственно перед началом написания playbook необходимо установить роль для apache:

ansible-galaxy install geerlingguy.apache
roman@ansible:~$ ansible-galaxy install geerlingguy.apache Starting galaxy role install process - downloading role 'apache', owned by geerlingguy - downloading role from https://github.com/geerlingguy/ansible-role-apache/archive/3.3.0.tar.gz - extracting geerlingguy.apache to /home/roman/.ansible/roles/geerlingguy.apache - geerlingguy.apache (3.3.0) was installed successfully roman@ansible:~$ 

Важно различать установку роли Ansible Galaxy для последующего использования для настройки хостов или групп и непосредственную настройку хоста или группы в соответствии с указанной ролью. В примере выше мы просто добавили Ansible Galaxy возможность конфигурировать эту роль на хостах или группе. Мы не выполняли установку Apache на текущем хосте. Про настройку хостов или групп в соответствии с ролью мы поговорим чуть ниже.

Если установка завершилась успешно, то вы также должны увидеть роль в перечне всех установленных ролей:

ansible-galaxy list
roman@ansible:~$ ansible-galaxy list # /home/roman/.ansible/roles - geerlingguy.apache, 3.3.0 [WARNING]: - the configured path /usr/share/ansible/roles does not exist. [WARNING]: - the configured path /etc/ansible/roles does not exist. roman@ansible:~$ 

Для того, чтобы указать Ansible Galaxy о том, что следует выполнить настройку роли необходимо объявить соответствующий блок – roles. В этом блоке вы указываете список ролей, настройку которых нужно выполнить. Например, ниже я приведу пример playbook для установки и настройки роли apache:

--- - hosts: front become: yes roles: - geerlingguy.apache

Теперь инициируем процесс настройки роли:

ansible-playbook -i inv.ini apache.yml
roman@ansible:~$ ansible-playbook -i inv.ini apache.yml PLAY [front] *************************************************************************************** TASK [Gathering Facts] ***************************************************************************** ok: [tst1] TASK [geerlingguy.apache : Include OS-specific variables.] ***************************************** ok: [tst1] TASK [geerlingguy.apache : Include variables for Amazon Linux.] ************************************ skipping: [tst1] TASK [geerlingguy.apache : Define apache_packages.] ************************************************ ok: [tst1] TASK [geerlingguy.apache : include_tasks] ********************************************************** included: /home/roman/.ansible/roles/geerlingguy.apache/tasks/setup-Debian.yml for tst1 TASK [geerlingguy.apache : Update apt cache.] ****************************************************** changed: [tst1] TASK [geerlingguy.apache : Ensure Apache is installed on Debian.] ********************************** changed: [tst1] TASK [geerlingguy.apache : Get installed version of Apache.] *************************************** ok: [tst1] TASK [geerlingguy.apache : Create apache_version variable.] **************************************** ok: [tst1] TASK [geerlingguy.apache : Include Apache 2.2 variables.] ****************************************** skipping: [tst1] TASK [geerlingguy.apache : Include Apache 2.4 variables.] ****************************************** ok: [tst1] TASK [geerlingguy.apache : Configure Apache.] ****************************************************** included: /home/roman/.ansible/roles/geerlingguy.apache/tasks/configure-Debian.yml for tst1 TASK [geerlingguy.apache : Configure Apache.] ****************************************************** ok: [tst1] => (item=) TASK [geerlingguy.apache : Enable Apache mods.] **************************************************** changed: [tst1] => (item=rewrite) changed: [tst1] => (item=ssl) TASK [geerlingguy.apache : Disable Apache mods.] *************************************************** skipping: [tst1] TASK [geerlingguy.apache : Check whether certificates defined in vhosts exist.] ******************** skipping: [tst1] TASK [geerlingguy.apache : Add apache vhosts configuration.] *************************************** changed: [tst1] TASK [geerlingguy.apache : Add vhost symlink in sites-enabled.] ************************************ changed: [tst1] TASK [geerlingguy.apache : Remove default vhost in sites-enabled.] ********************************* skipping: [tst1] TASK [geerlingguy.apache : Ensure Apache has selected state and enabled on boot.] ****************** ok: [tst1] RUNNING HANDLER [geerlingguy.apache : restart apache] ********************************************** changed: [tst1] PLAY RECAP ***************************************************************************************** tst1 : ok=16 changed=6 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0 roman@ansible:~$

Обратите внимание на то, что я не указывал какой менеджер пакетов использовать – apt, yum или dnf. Ansible Galaxy самостоятельно определил дистрибутив (Ubuntu) и использовал соответствующий менеджер пакетов. Соответственно, это добавляет ему универсальности – не нужно разрабатывать отдельные playbook для разных дистрибутивов. Второй момент, на который я бы хотел обратить ваше внимание, это ряд дополнительных действий. Настройка Apache, включение его автоматического запуска и т.д. Ansible Galaxy выполняет эти действия за нас с вами. Даже выполняется проверка – запущен ли Apache успешно или нет.

Пожалуй, для базового примера этого достаточно. А теперь давайте усложним задачу – выполним установку и настройку брандмауэра, а также установку сервера nginx. В следующем разделе я более детально покажу этот сценарий.

Расширенный пример использования Ansible Galaxy

В предыдущем примере я показал, как выполняется настройка роли apache. Теперь усложним пример – убедимся, что брандмауэр активировал, настроены исключения и установлен nginx.

Полный перечень параметров для настройки nginx через AnsibleGalaxy приведен вот тут.

Полный перечень параметров для настройки firewall через AnsibleGalaxy приведен вот тут.

Для этого примера я буду использовать следующую структуру каталога:

tree
roman@ansible:~/nginxfwd$ tree . ├── inventory │ └── inv.ini ├── playbook.yml └── requirements └── requirements.yml 2 directories, 2 files roman@ansible:~/nginxfwd$ 

Файл инвентаризации будет расположен по пути inventory/inv.ini.

Основную логику playbook я вынесу в одноименный файл – playbook.yml

Необходимые роли для Ansible Galaxy в этот раз я не буду устанавливать вручную, а покажу пример того, как перечень ролей можно вынести во внешний файл. Файл я размещу вот тут – requirements/requirements.yml.

Содержимое файла inventory/inv.ini:

[front] tst1 [front:vars] ansible_host=10.10.10.107

Перечень ролей я выне в файл requirements/requirements.yml:

--- - src: geerlingguy.firewall - src: geerlingguy.nginx

Установим нужные роли Ansible Galaxy:

ansible-galaxy install -r requirements/requirements.yml
roman@ansible:~/nginxfwd$ ansible-galaxy install -r requirements/requirements.yml Starting galaxy role install process - downloading role 'firewall', owned by geerlingguy - downloading role from https://github.com/geerlingguy/ansible-role-firewall/archive/2.5.1.tar.gz - extracting geerlingguy.firewall to /home/roman/.ansible/roles/geerlingguy.firewall - geerlingguy.firewall (2.5.1) was installed successfully - downloading role 'nginx', owned by geerlingguy - downloading role from https://github.com/geerlingguy/ansible-role-nginx/archive/3.1.4.tar.gz - extracting geerlingguy.nginx to /home/roman/.ansible/roles/geerlingguy.nginx - geerlingguy.nginx (3.1.4) was installed successfully roman@ansible:~/nginxfwd$

Теперь мы выполнили всю необходимую подготовку и можем приступать к написанию playbook. Я сразу приведу полный текст playbook:

--- - hosts: front become: yes roles: - geerlingguy.firewall - geerlingguy.nginx vars: firewall_allowed_tcp_ports: - "22" - "80" - "443" nginx_vhosts: [] nginx_remove_default_vhost: True nginx_docroot: /var/www/html

Этот небольшой playbook на самом деле выполняет довольно много работы. Мы в этом убедимся на живом примере. Также хочу обратить ваше внимание на то, что для настройки ролей я объявил некоторый перечень переменных. Переменная firewall_allowed_tcp_ports указывает – для каких портов необходимо сделать исключения в брандмауэре. Переменные с префиксом nginx учитываются при настройке роли nginx на группе хостов и выполняют дополнительную настройку сервиса nginx.

Запустим этот runbook:

ansible-playbook -i inventory/inv.ini playbook.yml

Вывод команды получился очень большой. Я приведу лишь его последнюю часть:

TASK [geerlingguy.nginx : Copy nginx configuration in place.] ************************************** changed: [tst1] TASK [geerlingguy.nginx : Ensure nginx service is running as configured.] ************************** ok: [tst1] RUNNING HANDLER [geerlingguy.firewall : restart firewall] ****************************************** changed: [tst1] RUNNING HANDLER [geerlingguy.nginx : restart nginx] ************************************************ changed: [tst1] RUNNING HANDLER [geerlingguy.nginx : reload nginx] ************************************************* changed: [tst1] PLAY RECAP ***************************************************************************************** tst1 : ok=21 changed=10 unreachable=0 failed=0 skipped=15 rescued=0 ignored=0 

Для того, чтобы Ansible Galaxy выполнил такой большой объем работ нам потребовалось написать все с десяток инструкций. Однако, за кадром Ansible Galaxy выполнил много вещей – настроил правила iptables, установил nginx, настроил его автозапуск, убедился, что сервис активен и т.д.

Если теперь перейти на один из хостов группы front, то можно убедиться, что сервис nginx активен и в правилах iptable Ansible Galaxy выполнил необходимые настройки:

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *