Ansible galaxy что это

Знакомство с 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. Надеюсь, что смог донести до вас назначение этого инструмента и его основы.

Эффективная разработка и сопровождение 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

Выполнять различные операции, связанные с ролью и коллекцией.

Synopsis

usage: ansible-galaxy [-h] [--version] [-v] TYPE . 

Description

команда для управления ролями Ansible в общих репозиториях, значение по умолчанию — Ansible Galaxy https://galaxy.ansible.com.

Common Options

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

показать это справочное сообщение и выйти

подробный режим (-vvv для получения дополнительной информации, -vvvv для включения отладки соединения)

Actions

collection

Выполните действие над коллекцией Ansible Galaxy. Должен сочетаться с дополнительным действием, таким как init/install, как указано ниже.

collection download

—clear-response-cache

Очистите существующий кэш ответов сервера.

Не используйте кеш ответов сервера.

Включите предварительные версии. Предварительные выпуски семантического управления версиями по умолчанию игнорируются.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Не загружайте collection(s), указанный в качестве зависимостей.

Каталог для загрузки коллекций.

Файл, содержащий список коллекций для загрузки.

Сервер Galaxy API URL

collection init

Создает каркас роли или коллекции, соответствующий формату метаданных Galaxy. Требуется имя роли или коллекции. Имя коллекции должно быть в формате . .

Путь к скелету коллекции, на котором должна основываться новая коллекция.

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

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Принудительная перезапись существующей роли или коллекции

Сервер Galaxy API URL

collection build

Создайте артефакт коллекции Ansible Galaxy, который можно хранить в центральном репозитории, таком как Ansible Galaxy. По умолчанию эта команда создает из текущего рабочего каталога. При желании вы можете передать входной путь коллекции (где файл galaxy.yml is).

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

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Принудительная перезапись существующей роли или коллекции

Сервер Galaxy API URL

collection publish

Опубликуйте коллекцию в Ansible Galaxy. Для публикации требуется путь к архиву коллекции.

Время ожидания завершения процесса импорта коллекции.

Не ждите результатов проверки импорта.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Сервер Galaxy API URL

collection install

—clear-response-cache

Очистите существующий кэш ответов сервера.

Принудительно перезаписать существующую коллекцию и ее зависимости.

Не используйте кеш ответов сервера.

Включите предварительные версии. Предварительные выпуски семантического управления версиями по умолчанию игнорируются.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Обновите установленные артефакты коллекции. Это также обновит зависимости, если не указан параметр –no-deps.

Игнорировать ошибки проверки сертификата SSL.

Принудительная перезапись существующей роли или коллекции

Игнорировать ошибки во время установки и продолжить со следующей указанной коллекции. Это не будет игнорировать ошибки конфликта зависимостей.

Не загружайте коллекции, указанные как зависимости.

Путь к каталогу, содержащему ваши коллекции.

Файл, содержащий список устанавливаемых коллекций.

Сервер Galaxy API URL

collection list

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

Формат для отображения списка коллекций.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Один или несколько каталогов для поиска коллекций в дополнение к каталогу по умолчанию COLLECTIONS_PATHS. Разделите несколько путей с помощью ‘:’.

Сервер Galaxy API URL

collection verify

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

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Игнорировать ошибки во время проверки и продолжить работу со следующей указанной коллекцией.

Один или несколько каталогов для поиска коллекций в дополнение к каталогу по умолчанию COLLECTIONS_PATHS. Разделите несколько путей с помощью ‘:’.

Файл, содержащий список коллекций, подлежащих проверке.

Сервер Galaxy API URL

role

Выполните действие над ролью Ansible Galaxy. Должен сочетаться с дополнительным действием, таким как delete/install/init, как указано ниже.

role init

Создает каркас роли или коллекции, соответствующий формату метаданных Galaxy. Требуется имя роли или коллекции. Имя коллекции должно быть в формате . .

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

Не запрашивать галактику API при создании ролей

Путь к скелету роли, на котором должна основываться новая роль.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Инициализировать с использованием альтернативного типа роли. Допустимые типы включают: «контейнер», «apb» и «сеть».

Игнорировать ошибки проверки сертификата SSL.

Принудительная перезапись существующей роли или коллекции

Сервер Galaxy API URL

role remove

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

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Путь к каталогу, содержащему ваши роли. По умолчанию это первый доступный для записи, настроенный через DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles.

Сервер Galaxy API URL

role delete

Удалить роль из Ansible Galaxy.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Сервер Galaxy API URL

role list

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

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Путь к каталогу, содержащему ваши роли. По умолчанию это первый доступный для записи, настроенный через DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles.

Сервер Galaxy API URL

role search

поиск ролей на сервере Ansible Galaxy

список тегов галактики для фильтрации

список платформ ОС для фильтрации

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Сервер Galaxy API URL

role import

используется для импорта роли в Ansible Galaxy

Имя ветки для импорта. По умолчанию используется ветка репозитория по умолчанию (обычно master)

Не ждите результатов импорта.

Имя, которое должна иметь роль, если оно отличается от имени репозитория.

Проверьте статус самого последнего запроса на импорт для данного github_user/github_repo.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Сервер Galaxy API URL

role setup

Настройте интеграцию с Github или Travis для ролей Ansible Galaxy.

Перечислите все свои интеграции.

Удалите интеграцию, соответствующую предоставленному значению идентификатора. Используйте —list, чтобы увидеть значения ID.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Путь к каталогу, содержащему ваши роли. По умолчанию это первый доступный для записи, настроенный через DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles.

Сервер Galaxy API URL

role info

распечатывает подробную информацию об установленной роли, а также информацию, доступную от галактики API.

Не запрашивать галактику API при создании ролей

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Путь к каталогу, содержащему ваши роли. По умолчанию это первый доступный для записи, настроенный через DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles.

Сервер Galaxy API URL

role install

—force-with-deps

Принудительная перезапись существующей роли и ее зависимостей.

Ключ Ansible Galaxy API, который можно найти по адресу https://galaxy.ansible.com/me/preferences .

Игнорировать ошибки проверки сертификата SSL.

Принудительная перезапись существующей роли или коллекции

Используйте tar вместо параметра архива scm при упаковке роли.

Игнорировать ошибки и продолжить со следующей указанной ролью.

Не загружайте роли, перечисленные в качестве зависимостей.

Путь к каталогу, содержащему ваши роли. По умолчанию это первый доступный для записи, настроенный через DEFAULT_ROLES_PATH: ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles.

Файл, содержащий список устанавливаемых ролей.

Сервер Galaxy API URL

Environment

Могут быть указаны следующие переменные среды.

ANSIBLE_CONFIG — переопределить файл конфигурации ansible по умолчанию.

Для большинства опций в ansible.cfg доступно гораздо больше.

Files

/etc/ansible/ansible.cfg — Файл конфигурации, если он присутствует

~/.ansible.cfg — файл конфигурации пользователя, переопределяет конфигурацию по умолчанию, если она присутствует.

Author

Ansible изначально был написан Майклом DeHaan..

Полный список участников см. в файле AUTHORS .

License

Ansible выпускается на условиях лицензии GPLv3+.

See also

З14153З, К25387К, Т36246Т, В45910В, З51656З, К63919К, Т75101Т, В84849В, З96959З,

Коллекции — Основы автоматизации в 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 студентов

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