Найти в Дзене
Infra as Code по-русски

Ansible inventory: что это и как настроить (Часть 1)

Ansible inventory — это список ваших хостов и их групп. В этой статье (Часть 1) разберём, зачем нужен inventory, какие есть форматы (INI и YAML) с живыми примерами, как работать с группами, children, диапазонами хостов, подключать несколько источников через -i, и организовать inventory в каталоге. Все примеры — с понятными кусочками кода и разбором типичных ошибок. Inventory — это «карта инфраструктуры» для Ansible: список хостов, их групп.
Зачем: Итог: без корректного inventory Ansible «не знает», куда подключаться и как объединять хосты. Возьмём хосты из нашего инвентаря. ### App example ###
[app_dev_example]
app-1.dev.example
app-2.dev.example
app-3.dev.example ### App dev ###
[app_dev:children]
app_dev_example ### App all ###
[app:children]
app_dev YAML (более декларативно, хорошо ложится на каталоги с group_vars/host_vars) # hosts.yml
all:
children:
app_dev_example:
hosts:
app-1.dev.example:
app-2.dev.example:
app-3.dev.example:
app_dev:
Оглавление

Аннотация

Ansible inventory — это список ваших хостов и их групп. В этой статье (Часть 1) разберём, зачем нужен inventory, какие есть форматы (INI и YAML) с живыми примерами, как работать с группами, children, диапазонами хостов, подключать несколько источников через -i, и организовать inventory в каталоге. Все примеры — с понятными кусочками кода и разбором типичных ошибок.

Что такое inventory и зачем он нужен

Inventory — это «карта инфраструктуры» для Ansible: список хостов, их групп.
Зачем:

  • Определяет цели для плейбуков (-l groupname или по паттернам).
  • Позволяет кластеризовать окружения: dev/stage/prod.
  • Даёт масштабируемость: группы, наследование (children), несколько источников.

Итог: без корректного inventory Ansible «не знает», куда подключаться и как объединять хосты.

2) Форматы INI и YAML: базовые примеры

Возьмём хосты из нашего инвентаря.

INI (классика, сразу понятные диапазоны и children)

### App example ###
[app_dev_example]
app-1.dev.example
app-2.dev.example
app-3.dev.example
### App dev ###
[app_dev:children]
app_dev_example
### App all ###
[app:children]
app_dev

YAML (более декларативно, хорошо ложится на каталоги с group_vars/host_vars)

# hosts.yml
all:
children:
app_dev_example:
hosts:
app-1.dev.example:
app-2.dev.example:
app-3.dev.example:
app_dev:
children:
app_dev_example:
app:
children:
app_dev:

Важно: синтаксис :children — это INI; в YAML используется ключ children:.

Группы в инвентарях: встроенные и пользовательские

  • Встроенные:
    all — корневая группа, содержит всё.
    ungrouped — хосты, не попавшие ни в одну пользовательскую группу.
  • Пользовательские: вы создаёте сами (например, app_dev_example, app_dev, kafka), чтобы отражать архитектуру/окружения/роли.

Типичная ошибка: называть группы с пробелами или нестандартными символами. Используйте a-z, цифры, _ и -.

Добавление хостов в несколько групп

INI: один и тот же хост можно повторить в разных секциях:

[app_dev_example]
app-1.dev.example
[monitoring]
app-1.dev.example

YAML: просто перечислите один и тот же хост под разными группами:

all:
children:
app_dev_example:
hosts:
app-1.dev.example:
monitoring:
hosts:
app-1.dev.example:

Зачем это нужно на практике?

  • Разные роли для одного узла. Один сервер может быть и приложением, и точкой мониторинга: app-1.dev.example лежит в группах app_dev_example и monitoring.
  • Раздельные настройки. В group_vars/app_dev_example.yml — параметры приложения, в group_vars/monitoring.yml — агенты и правила алёртов.
  • Точечные запуски. Обновляем только приложение: -l app_dev_example. Настраиваем только мониторинг: -l monitoring.

Группировка групп: отношения родитель/потомок (children)

INI:

[app_dev:children]
app_dev_example
[kafka:children]
app_dev

YAML:

all:
children:
app_dev:
children:
app_dev_example:
kafka:
children:
app_dev:

Идея: объединяйте логические подгруппы в более крупные слои (окружение → платформа → роль).

Зачем это нужно?

  • Слои иерархии. Собираем «мелкие» группы в «крупные»: app_dev_example → app_dev → kafka. Так удобно запускать плейбуки «на всё приложение» или «на весь стек».
  • Общие настройки на уровень выше. В group_vars/app_dev.yml кладём параметры, общие для всех апп-серверов dev. Дочерние группы унаследуют их автоматически.
  • Переиспользование. Сегодня kafka — это только app_dev, завтра добавим app_stage в те же parents без переписывания плейбуков.

Диапазон хостов: как добавить и зачем

Зачем: быстро описать серию однотипных узлов.
INI умеет нативно:

[app_dev_example]
app-[1:3].dev.example # развернётся в app-1..app-3

Можно указать такой шаблон прямо в команде запуска:

ansible 'app-[1:3].dev.example' -m ping -i hosts.ini

Это удобно, когда нужно быстро обратиться к серии машин, не меняя сам файл инвентаря.

В YAML ключи — это имена хостов; безопаснее явно перечислять или сгенерировать hosts (скриптом/динамическим плагином). Если очень нужно — используйте диапазоны в целевой выборке при запуске плейбука, а не внутри YAML-файла.

Несколько источников инвентаря

Иногда удобно слить два инвентаря на запуске (например, общее + окружение):

ansible-playbook get_logs.yml -i staging -i production
  • Ansible объединит хосты и группы.
  • При совпадении переменных действует приоритет порядка загрузки; финальное значение — «последний победил».

Подводный камень: одинаковые имена хостов в разных источниках → внимательно следите за тем, какие группы и переменные в итоге применились. Проверяйте через:

ansible-inventory -i staging -i production --graph
ansible-inventory -i staging -i production --list --yaml

Организация inventory в каталоге (и консолидация)

Что такое «консолидация»?
Это когда мы
складываем несколько файлов или папок инвентаря за один запуск, а Ansible склеивает их в единый список хостов и групп.
Например, есть общий пул inventory/common/ и окружение inventory/prod/. На запуске пишем:

ansible-playbook site.yml -i inventory/common -i inventory/prod

В итоге вы получите один общий инвентарь: хосты и группы из common плюс хосты и группы из prod. Удобно, когда часть настроек общая, а часть — специфична для окружения.

Проверка себя (быстрые команды)

# Посмотреть граф групп/хостов
ansible-inventory -i inventory/prod --graph
# Полный список в YAML
ansible-inventory -i inventory/prod --list --yaml
# Пинг группы
ansible app_dev -m ping -i inventory/prod

Типичные ошибки и фиксы

  • «Группа не видит хостов» → проверьте children vs :children, формат файла и отступы (YAML).
  • «Пустая группа в графе» → нет ни hosts, ни children.
  • «Диапазон не разворачивается в YAML» → используйте INI/CLI паттерны или явное перечисление.
  • «Смешал много источников и всё поехало» → проверьте --list --yaml, порядок -i, уберите дубликаты.

Почему это работает

  • Единый снимок инвентаря. На старте Ansible берёт все указанные источники (-i …) и собирает из них одну структуру: хосты, группы, «родители/дети».
  • Группы — это метки. Хост может иметь несколько меток (групп). Поэтому app-1.dev.example спокойно живёт и в app_dev_example, и в monitoring.
  • children = иерархия меток. Когда вы пишете app_dev: children: app_dev_example, вы говорите: «в app_dev входят все хосты из app_dev_example». Поэтому запуск на app_dev охватит и «дочек».
  • Разворачивание диапазонов (INI). Запись app-[1:3].dev.example превращается в три имени: app-1, app-2, app-3. Это ускоряет описание однотипных узлов.
  • Приоритет переменных (коротко). Если переменная foo определена и в group_vars/app_dev_example.yml, и в host_vars/app-1.yml, то победит host_vars (более конкретно). Это делает поведение предсказуемым: чем уже область — тем выше приоритет.

Что сделали

  • Определили, что такое inventory и зачем он нужен.
  • Разобрали форматы INI и YAML на одном примере.
  • Показали группы, children, хост в нескольких группах.
  • Обсудили диапазоны и где они реально работают.
  • Научились подключать несколько источников -i.
  • Показали, как организовать каталог с inventory.

Сделать прямо сейчас (чеклист)

  • Создай каталог inventory/dev и положи туда hosts.ini из примера.
  • Прогоняй ansible-inventory --graph и --list --yaml, чтобы поймать ошибки.
  • Если нужны диапазоны — используй INI или CLI-паттерны.
  • Раздели общий и окруженческий инвентари и попробуй запуск с -i common -i dev.
  • Зафиксируй путь к инвентарю в ansible.cfg.

CTA

Сохраняйте статью, чтобы не потерять примеры, и заглядывайте за продолжением — впереди паттерны выбора, переменные и динамические инвентари.