Динамический инвентарь и инвентарные плагины

[Maksim_DevOps]

Представь, что ты автоматизируешь парк серверов, который живёт своей жизнью. Утром было 3 веб-ноды, к обеду автоскейлинг поднял ещё 7, а к вечеру половину погасил. Ты можешь героически руками дописывать IP в файл inventory.ini, но это путь в ад: список устаревает быстрее, чем ты его сохраняешь. В контейнерной среде ещё веселее - контейнеры рождаются и умирают пачками, и фиксировать их в статическом файле бессмысленно.

Ровно эту боль решает ansible динамический инвентарь. Вместо того чтобы хранить список хостов вручную, ты говоришь Ansible: "сходи в облако (или в Docker, или в Kubernetes) и спроси у него актуальный список прямо сейчас". Источник правды - сама инфраструктура, а не текстовый файл, который кто-то забыл обновить.

Статический против динамического: в чём разница

Статический инвентарь - это просто файл (INI или YAML), где хосты и группы прописаны руками. Он отлично подходит для лабы и для парка, который меняется раз в квартал. Динамический инвентарь - это исполняемый источник, который Ansible опрашивает в момент запуска и получает свежий список.

Раньше dynamic inventory делали через скрипты: писали программу на Python (или чём угодно), которая по флагу

Код: Выделить всё

--list

выдавала JSON с хостами и группами. Эти скрипты до сих пор работают и считаются легаси - если увидишь в старом проекте файл вроде

Код: Выделить всё

ec2.py

в инвентаре, это оно. Скрипт должен быть исполняемым и возвращать строго определённую структуру JSON. Сегодня так почти не пишут: скрипты тяжело сопровождать, у каждого свой формат конфига и свои переменные окружения.

Современный путь - inventory plugin. Ansible inventory plugin это модуль внутри коллекции, который умеет ходить в конкретный источник (AWS, Docker, GCP, OpenStack, VMware) и отдавать хосты единообразно. Конфигурируется он не кодом, а маленьким YAML-файлом. Плюсы очевидны: общий синтаксис, кеширование из коробки, переиспользование подключений и человеческая документация. Скрипты отдавали готовый JSON и всё; плагины же дают единый язык для вычисляемых групп и переменных.



Включаем плагины: enable_plugins в ansible.cfg

Чтобы Ansible вообще трогал твои YAML-файлы инвентаря, нужный плагин должен быть разрешён. По умолчанию включён только плагин

Код: Выделить всё

auto

плюс пара базовых (host_list, yaml, ini). Остальные включаются явно в

Код: Выделить всё

ansible.cfg

:

Код: Выделить всё

[defaults]
inventory = ./inventory

[inventory]
enable_plugins = auto, host_list, yaml, ini, amazon.aws.aws_ec2, community.docker.docker_containers, constructed

Дальше важная деталь, на которой спотыкаются все новички: имя конфиг-файла. Плагин подхватит файл, только если имя совпадает с ожидаемым суффиксом. Для Docker-плагина файл должен оканчиваться на

Код: Выделить всё

docker.yml

или

Код: Выделить всё

docker.yaml

, для EC2 - на

Код: Выделить всё

aws_ec2.yml

/

Код: Выделить всё

aws_ec2.yaml

. Если назовёшь файл

Код: Выделить всё

hosts.yml

, ничего не заведётся, и ты будешь час гадать почему.

Внутри файла обязателен ключ

Код: Выделить всё

plugin

с FQCN плагина. Сначала установи нужные коллекции:

Код: Выделить всё

ansible-galaxy collection install community.docker amazon.aws

Docker-инвентарь: ansible docker на практике

Классический пример из книги - инвентарь по локальным контейнерам. Связка ansible docker полезна, когда ты гоняешь тестовое окружение в контейнерах и хочешь катать на них плейбуки как на обычных хостах. Создаём файл

Код: Выделить всё

inventory/docker.yml

:

Код: Выделить всё

---
plugin: community.docker.docker_containers
docker_host: unix://var/run/docker.sock
connection_type: docker_api
verbose_output: false
keyed_groups:
  - prefix: image
    key: docker_image
compose:
  ansible_user: "'root'"

Здесь

Код: Выделить всё

connection_type: docker_api

говорит подключаться к контейнерам через Docker API (без SSH внутри контейнера), а

Код: Выделить всё

keyed_groups

автоматически раскидает контейнеры по группам вида

Код: Выделить всё

image_nginx

,

Код: Выделить всё

image_redis

на основе образа. Проверяем, что Ansible видит контейнеры:

Код: Выделить всё

ansible-inventory -i inventory/docker.yml --graph

keyed_groups и compose: вычисляемые группы и переменные

Два ключа делают плагины по-настоящему мощными, и они работают одинаково почти во всех инвентарных плагинах.

keyed_groups создаёт группы динамически из данных хоста. Например, в облаке у каждой машины есть теги. Хочешь, чтобы все ноды с тегом Role=web попали в группу

Код: Выделить всё

role_web

? Описываешь правило, и Ansible сам собирает группы из живых метаданных - тебе не надо вести список вручную.

compose вычисляет переменные хоста через Jinja2. Типичный кейс - подменить адрес подключения: в облаке у инстанса есть и публичный, и приватный IP, и ты решаешь, по какому ходить. Обрати внимание на двойные кавычки в

Код: Выделить всё

compose

: значение это Jinja2-выражение, поэтому строковый литемрал надо ещё раз закавычить внутри.

Пример облачного плагина amazon.aws.aws_ec2, файл

Код: Выделить всё

inventory/aws_ec2.yml

:

Код: Выделить всё

---
plugin: amazon.aws.aws_ec2
regions:
  - eu-central-1
filters:
  instance-state-name: running
keyed_groups:
  - prefix: role
    key: tags.Role
    separator: "_"
  - prefix: az
    key: placement.availability_zone
compose:
  ansible_host: private_ip_address

Тот же подход у

Код: Выделить всё

google.cloud.gcp_compute

,

Код: Выделить всё

openstack.cloud.openstack

,

Код: Выделить всё

vmware.vmware.esxi_hosts

- меняется только источник и набор полей, а логика keyed_groups/compose одна.

Constructed: дособираем группы из чего угодно

Отдельный герой - плагин

Код: Выделить всё

constructed

. Он не ходит в облако, а берёт уже собранный инвентарь (из других источников или статики) и достраивает поверх него вычисляемые группы и переменные. Это и есть то, что называют constructed inventory. Удобно, когда облачный плагин дал тебе хосты с переменными, а тебе нужны группы по сложному условию.

Файл

Код: Выделить всё

inventory/constructed.yml

:

Код: Выделить всё

---
plugin: constructed
strict: false
groups:
  webservers: "'web' in (group_names | join(','))"
  high_mem: ansible_memtotal_mb is defined and ansible_memtotal_mb > 8000
keyed_groups:
  - prefix: distro
    key: ansible_distribution | lower

Здесь

Код: Выделить всё

groups

создаёт группу по булеву Jinja2-условию, а constructed работает после сбора фактов, поэтому может опираться на

Код: Выделить всё

ansible_*

переменные. Чтобы плагины срабатывали в нужном порядке, держи их в одном каталоге - Ansible читает файлы по алфавиту, и

Код: Выделить всё

constructed.yml

логично идёт после

Код: Выделить всё

aws_ec2.yml

. Можно скормить весь каталог сразу:

Код: Выделить всё

ansible-inventory -i inventory/ --graph
ansible-inventory -i inventory/ --list

Типичные грабли

• Файл назван не так. Самая частая ошибка. Плагин молча игнорирует файл с неподходящим именем. Сверяйся с суффиксом из документации плагина.
• Плагин не в enable_plugins. Установил коллекцию, написал конфиг, а инвентарь пустой - почти всегда забыли строку в

  Код: Выделить всё

  [inventory]

  секции ansible.cfg.
• Кавычки в compose.

  Код: Выделить всё

  compose: ansible_user: root

  упадёт, потому что root будет трактоваться как переменная. Нужно

  Код: Выделить всё

  "'root'"

  .
• Нет прав/кредов. Для AWS нужны ключи (env или профиль), для Docker - доступ к сокету. Если ansible-inventory ничего не вернул, проверь доступ к API руками.
• Забыл проверить графом. Не запускай плейбук вслепую. Сначала

  Код: Выделить всё

  ansible-inventory --graph

  , убедись, что хосты и группы те самые.

Мини-лаба

Повтори руками, чтобы отложилось:

• Подними 2-3 контейнера:

  Код: Выделить всё

  docker run -d --name web1 nginx

  , аналогично web2 и redis.
• Установи коллекцию:

  Код: Выделить всё

  ansible-galaxy collection install community.docker

  .
• Включи плагин в ansible.cfg и создай

  Код: Выделить всё

  inventory/docker.yml

  из примера выше.
• Запусти

  Код: Выделить всё

  ansible-inventory -i inventory/docker.yml --graph

  и найди группы

  Код: Выделить всё

  image_nginx

  и

  Код: Выделить всё

  image_redis

  .
• Добавь

  Код: Выделить всё

  constructed.yml

  с группой по имени и скорми каталог целиком через

  Код: Выделить всё

  -i inventory/

  .

На RHEL/Fedora всё это ставится поверх

Код: Выделить всё

dnf install ansible-core

; на Ubuntu/Debian - через

Код: Выделить всё

apt

, на RED OS/Astra - из их репозиториев или pip. Сама логика инвентарных плагинов от дистрибутива не зависит.

Контрольные вопросы

• Чем inventory plugin лучше старого inventory-скрипта и почему скрипты считают легаси?
• Почему файл с конфигом Docker-плагина обязан называться так, чтобы оканчиваться на docker.yml, и что будет иначе?
• В чём разница между keyed_groups и compose, и зачем в compose двойные кавычки вокруг строкового значения?
• Что делает плагин constructed и почему он умеет опираться на ansible_* факты?

Итог

Когда хосты живут в облаке или в контейнерах, статический файл проигрывает: список устаревает мгновенно. Дай Ansible самому спросить инфраструктуру через inventory plugin, разрешив его в

Код: Выделить всё

enable_plugins

. Группы и переменные собирай динамически через keyed_groups и compose, добивай логику плагином constructed, а перед запуском всегда сверяйся через

Код: Выделить всё

ansible-inventory --graph

. На EX294 динамический инвентарь спрашивают реже статики, но понимать enable_plugins и формат конфига полезно, чтобы не зависнуть, если задача всё же придёт.

[grpc_pro]

Спасибо, наконец дошло почему мой docker.yml не подхватывался - назвал файл inventory.yml и плагин его просто игнорил. Переименовал в docker.yml и сразу заработало.

[queue2]

А constructed можно навесить поверх aws_ec2 в одном каталоге? Правильно понимаю что порядок по алфавиту, поэтому aws_ec2.yml читается раньше constructed.yml и факты уже доступны?