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

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

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

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

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

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

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

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

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

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

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

Хотя он в основном используется для запуска установок ОС и управления DHCP и DNS, Cobbler имеет общий уровень, который может представлять данные для нескольких систем управления конфигурацией (даже одновременно) и служить «лёгкой 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 }}"

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

Пример скрипта инвентаризации: 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. Мы рекомендуем использовать плагины инвентаризации вместо этого.

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

Если Ansible указанному местоположению -i является каталог (или так настроено в 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