Работа с динамической инвентаризацией

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

Ansible без проблем интегрируется с Cobbler — сервером установки Linux, первоначально написанным Майклом Дехааном и ныне развиваемым Джеймсом Каммаратой, который работает в Ansible.

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

Чтобы связать инвентаризацию Ansible с Cobbler, скопируйте этот скрипт в /etc/ansible и chmod +x файл. Запускайте cobblerd каждый раз при использовании Ansible и указывайте параметр командной строки -i (например, -i /etc/ansible/cobbler.py), чтобы взаимодействовать с Cobbler через XMLRPC API 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