AWX и dynamic inventory plugin: VMware vSphere без ручного ведения ini-файлов

Есть класс проблем, которые не выглядят проблемами до момента когда становятся невыносимыми. Статический ini-инвентарь Ansible - из этой категории. Сначала хостов двадцать, потом пятьдесят, потом кто-то завёл новые ВМ во vSphere и забыл добавить их в файл. Через неделю выясняется, что playbook не отработал на половине машин. Все виноваты, никто не виноват.

Мы перевели один из сопровождаемых проектов на dynamic inventory plugin для VMware vSphere. Вот что из этого получилось.

Откуда взялась проблема

Клиент - промышленная инфраструктура на vSphere 6.7, порядка восьмидесяти ВМ разной степени жизненности: продакшн, staging, несколько тестовых сред, ВМ под задачи разработки. AWX у них стоит с прошлого года, разворачивали сами. До недавнего времени инвентарь жил в нескольких ini-файлах: production.ini, staging.ini, dev.ini. Файлы хранились в Git, AWX синхронизировал проект и подтягивал их.

Поддерживать эти файлы - ручная работа. ВМ создаётся во vSphere, инженер не всегда сразу правит инвентарь. Иногда помнит, иногда нет. Иногда помнит но пишет IP вместо hostname или кладёт в неправильную группу. Всё это - источник ошибок, которые обнаруживаются в самый неподходящий момент.

Что появилось в AWX

AWX активно развивается в 2019 году, и версии начала года принесли нормальную поддержку Inventory Source с типом vmware_vm_inventory. Это не старый скрипт-способ (когда inventory-скрипт дёргается отдельно), а нативный inventory plugin на базе нового Inventory Plugin API Ansible. Разница принципиальная: plugin работает как часть Ansible, а не как внешний скрипт, у него есть нормальная конфигурация через YAML, фильтрация по тегам и атрибутам vSphere, и кеширование результатов.

AWX добавил UI для настройки таких источников напрямую через интерфейс: заходишь в Inventory, добавляешь Inventory Source типа VMware vCenter, указываешь credential с адресом vCenter и учёткой, и AWX периодически синхронизирует список хостов. Можно настроить автосинхронизацию при запуске Job Template - тогда перед каждым прогоном плейбука инвентарь обновляется автоматически.

Как настраивали

Сначала создали Credential типа VMware vCenter в AWX - это отдельный тип credential, появившийся в недавних версиях: хост vCenter, логин, пароль. Данные шифруются в базе AWX, никуда не утекают.

Дальше в Inventory добавили новый Inventory Source:

• Source - VMware vCenter
• Credential - только что созданный
• Update on launch - включено
• Overwrite - включено, чтобы удалённые ВМ убирались из инвентаря автоматически

В разделе Source Variables указываешь YAML с дополнительными параметрами плагина. Для нас это выглядело примерно так:

with_tags: true
hostnames:
  - config.name
properties:
  - name
  - config.name
  - config.guestId
  - runtime.powerState
  - value.moid
filters:
  - runtime.powerState == "poweredOn"

Фильтр по powerState сразу исключил выключенные ВМ из инвентаря - их раньше тоже держали в ini-файлах «на всякий случай», и они иногда вносили путаницу.

Группировка через теги vSphere

Вот здесь и кроется главная польза. В vSphere у клиента уже была (не очень последовательно ведущаяся) тегирование ВМ: теги типа env:production, role:db, role:app. AWX через plugin подхватывает эти теги и автоматически создаёт группы в инвентаре.

То есть если инженер создаёт ВМ во vSphere и вешает на неё тег env:staging и role:app - при следующей синхронизации AWX она автоматически появляется в группах tag_env_staging и tag_role_app. Плейбук, который таргетирует группу tag_env_staging, её подхватит без каких-либо правок.

Это поменяло рабочий процесс. Теперь инженер, который заводит новую ВМ, должен правильно её тегировать в vSphere - и это всё. AWX сам разберётся где ей быть. Отдельного шага «добавить в инвентарь» больше нет.

Что пришлось поправить

Не всё прошло гладко.

Наименование групп. Группы из динамического инвентаря называются иначе, чем группы в старых ini-файлах. В ini было [production_web], в динамическом - tag_env_production и tag_role_web отдельно. Плейбуки, которые явно указывали группу production_web, пришлось переписать под новую логику. Несколько часов работы, ничего страшного, но учесть надо.

Хосты без тегов. Часть ВМ во vSphere не имела тегов вообще. AWX их подхватил, но они упали в группу all без какой-либо дополнительной классификации. Эти машины пришлось разобрать вручную - расставить теги или принять решение что с ними делать. Это одноразовая работа, но она обнажила «зоопарк» ВМ, о существовании которых кто-то забыл.

Переменные хостов. В ini-файлах для части хостов были host variables - специфичные для хоста переменные прямо в файле. В динамическом инвентаре эти переменные можно задавать через host_vars в репозитории или через custom attributes в самом vSphere. Мы пошли по пути host_vars в Git - так оно версионируется и видно кто что менял.

Промежуточный итог

Первая синхронизация после настройки показала несколько хостов, которых в ini-файлах не было. Кто-то создал тестовые ВМ и забыл добавить в инвентарь. Это само по себе полезный результат.

Главный выигрыш - убрали ручной шаг из процесса. Новая ВМ появляется в инвентаре AWX автоматически как только её тегируют во vSphere. Это не требует от инженера помнить ещё об одном файле в ещё одном репозитории.

Тегирование ВМ в vSphere теперь стало обязательным шагом при создании машины - по сути это минимальная CMDB внутри vSphere. Политику назвать систематической пока сложно - договорились о наборе обязательных тегов, но следить за соблюдением нет автоматики. Это следующий шаг: скрипт проверки или policy через vSphere Tags API. Но это уже отдельная история.