Работа с динамическим инвентарём

Пример скрипта инвентаризации: Cobbler

Ansible бесшовно интегрируется с Cobbler, сервером установки Linux, первоначально написанным Майклом ДеХаном, а сейчас под руководством Джеймса Каммараты, работающего в Ansible.

Хотя Cobbler в основном используется для запуска установок операционных систем и управления DHCP и DNS, он имеет общий уровень, который может представлять данные для нескольких систем управления конфигурацией (даже одновременно) и служить «лёгкой CMDB».

Чтобы связать ваш инвентарь Ansible с Cobbler, скопируйте этот скрипт в /etc/ansible и chmod +x файл. Запустите cobblerd всякий раз, когда вы используете Ansible, и используйте -i параметр командной строки (например, -i /etc/ansible/cobbler.py) для взаимодействия с Cobbler с помощью API XMLRPC Cobbler.

Добавьте cobbler.ini файл в /etc/ansible, чтобы Ansible знал, где находится сервер Cobbler, и можно было использовать некоторые улучшения кэша. Например:

[cobbler]

# Set Cobbler's hostname or IP address
host = http://127.0.0.1/cobbler_api

# API calls to Cobbler can be slow. For this reason, we cache the results of an API
# call. Set this to the path you want cache files to be written to. Two files
# will be written to this directory:
#   - ansible-cobbler.cache
#   - ansible-cobbler.index

cache_path = /tmp

# The number of seconds a cache file is considered valid. After this many
# seconds, a new API call will be made, and the cache file will be updated.

cache_max_age = 900

Сначала протестируйте скрипт, запустив /etc/ansible/cobbler.py непосредственно. Вы должны увидеть вывод некоторых JSON-данных, но возможно, в нём пока ничего нет.

Давайте разберёмся, что это делает. В Cobbler предположим сценарий, похожий на следующий:

cobbler profile add --name=webserver --distro=CentOS6-x86_64
cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3"
cobbler system edit --name=foo --dns-name="foo.example.com" --mgmt-classes="atlanta" --ksmeta="c=4"
cobbler system edit --name=bar --dns-name="bar.example.com" --mgmt-classes="atlanta" --ksmeta="c=5"

В приведённом примере система «foo.example.com» непосредственно доступна ansible, а также доступна при использовании имён групп «webserver» или «atlanta». Поскольку Ansible использует SSH, он связывается с системой foo по адресу «foo.example.com» только, никогда просто «foo». Аналогично, если вы попробуете «ansible foo», он не найдёт систему… но «ansible ‘foo*’» сработает, потому что имя DNS системы начинается с «foo».

Скрипт предоставляет не только информацию о хостах и группах. В дополнение, как бонус, при запуске модуля «setup» (который запускается автоматически при использовании плейбуков) переменные «a», «b» и «c» будут автоматически заполнены в шаблонах:

# file: /srv/motd.j2
Welcome, I am templated with a value of a={{ a }}, b={{ b }}, and c={{ c }}

Что можно выполнить так:

ansible webserver -m setup
ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd"

Таким образом, с вышеприведённым шаблоном (motd.j2) в результате следующие данные запишутся в /etc/motd для системы «foo»:

Welcome, I am templated with a value of a=2, b=3, and c=4

А на системе «bar» (bar.example.com):

Welcome, I am templated with a value of a=2, b=3, and c=5

И теоретически, хотя особой причины для этого нет, это тоже работает:

ansible webserver -m ansible.builtin.shell -a "echo {{ a }}"

Иными словами, вы можете использовать эти переменные и в аргументах/действиях.

Другие скрипты инвентаризации

В Ansible 2.10 и более поздних версиях скрипты инвентаризации переместились в связанные коллекции. Многие из них теперь находятся в репозитории ansible-community/contrib-scripts. Мы рекомендуем использовать Плагины инвентаризации вместо них.

Использование каталогов инвентаризации и нескольких источников инвентаризации

Если местоположение, заданное -i в Ansible, является каталогом (или так настроено в ansible.cfg), Ansible может использовать несколько источников инвентаризации одновременно. При этом можно смешивать как динамические, так и статически управляемые источники инвентаризации в одном запуске Ansible. Мгновенная гибридная облачная среда!

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

~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

Вы можете заменить этот список своим собственным, настроив inventory_ignore_extensions список в ansible.cfg, или задав переменную окружения ANSIBLE_INVENTORY_IGNORE. Значение в обоих случаях должно быть перечислением шаблонов через запятую, как показано выше.

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

Статические группы динамических групп

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

[tag_Name_staging_foo]

[tag_Name_staging_bar]

[staging:children]
tag_Name_staging_foo
tag_Name_staging_bar