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

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

Мы перевели один из managed-проектов на 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. Но это уже отдельная история.