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

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

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

  • Явное использование скрипта инвентаризации OpenStack
  • Неявное использование скрипта инвентаризации OpenStack
  • Обновление кэша
• Другие скрипты инвентаризации
• Использование каталогов инвентаризации и нескольких источников инвентаризации
• Статические группы динамических групп

Если ваш инвентарь Ansible меняется со временем, с хостами, которые включаются и выключаются в ответ на бизнес-потребности, статические решения по инвентаризации, описанные в Как создать свой инвентарь, не подойдут. Вам может потребоваться отслеживать хосты из нескольких источников: облачные провайдеры, LDAP, Cobbler и/или корпоративные системы CMDB.

Ansible интегрирует все эти варианты через динамическую внешнюю систему инвентаризации. Ansible поддерживает два способа подключения к внешнему инвентарю: Плагины инвентаризации и inventory scripts.

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

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

Если вы предпочитаете графический интерфейс для работы с динамическим инвентарём, база данных инвентаризации Red Hat Ansible Tower синхронизируется со всеми вашими динамическими источниками инвентаризации, предоставляет веб- и REST-доступ к результатам и предлагает графический редактор инвентаря. Имея базу данных всех ваших хостов, вы можете сопоставить историю прошлых событий и увидеть, у каких хостов были сбои на последних запусках плейбуков.

Пример скрипта инвентаризации: 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 }}"

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

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

Если вы используете облако на базе OpenStack, вместо ручного ведения файла инвентаризации вы можете использовать openstack_inventory.py динамический инвентарь, чтобы извлечь информацию о ваших вычислительных экземплярах напрямую из OpenStack.

Вы можете загрузить последнюю версию скрипта инвентаризации OpenStack здесь.

Вы можете использовать скрипт инвентаризации явно (передав -i openstack_inventory.py аргумент Ansible) или неявно (разместив скрипт в /etc/ansible/hosts).

Явное использование скрипта инвентаризации OpenStack

Загрузите последнюю версию скрипта динамической инвентаризации OpenStack и сделайте его исполняемым:

wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py
chmod +x openstack_inventory.py

Используйте файл RC OpenStack:

source openstack.rc

Вы можете подтвердить, что файл успешно использован, выполнив простое командное задание, например nova list, и убедившись, что оно не возвращает ошибок.

Вы можете вручную проверить скрипт динамического инвентаря OpenStack, чтобы убедиться, что он работает как ожидается:

./openstack_inventory.py --list

Через несколько мгновений вы должны увидеть вывод JSON с информацией о ваших вычислительных экземплярах.

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

ansible -i openstack_inventory.py all -m ansible.builtin.ping

Неявное использование скрипта инвентаризации OpenStack

Загрузите последнюю версию скрипта динамической инвентаризации OpenStack, сделайте его исполняемым и скопируйте его в /etc/ansible/hosts:

wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py
chmod +x openstack_inventory.py
sudo cp openstack_inventory.py /etc/ansible/hosts

Загрузите файл конфигурации образца, измените его в соответствии со своими потребностями и скопируйте его в /etc/ansible/openstack.yml:

wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack.yml
vi openstack.yml
sudo cp openstack.yml /etc/ansible/

Вы можете вручную проверить скрипт динамической инвентаризации OpenStack, чтобы убедиться, что он работает как ожидается:

/etc/ansible/hosts --list

Через несколько мгновений вы должны увидеть вывод JSON с информацией о ваших вычислительных экземплярах.

Обновление кэша

Обратите внимание, что скрипт динамической инвентаризации OpenStack будет кэшировать результаты, чтобы избежать многократных обращений к API. Чтобы явно очистить кэш, вы можете запустить скрипт openstack_inventory.py (или hosts) с параметром --refresh:

./openstack_inventory.py --refresh --list

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

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

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

Если местоположение, указанное для -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