Как создать инвентаризацию

Ansible автоматизирует задачи на управляемых узлах, или «хостах», вашей инфраструктуры с помощью списка или группы списков, известных как инвентаризация. Ansible формирует инвентаризацию из одного или нескольких «источников инвентаризации». Одним из таких источников может быть список имён хостов, переданный в командной строке, но большинство пользователей Ansible создают файлы инвентаризации. Инвентаризация определяет управляемые узлы, автоматизируемые вами, и переменные, связанные с этими хостами. Вы также можете указывать группы. Группы позволяют ссылаться на несколько связанных хостов, чтобы выбрать их для автоматизации или массово определить переменные. После определения инвентаризации используйте шаблоны, чтобы выбрать хосты или группы, на которых Ansible будет выполнять задачи.

Самая простая инвентаризация — это один файл со списком хостов и групп. По умолчанию этот файл находится в /etc/ansible/hosts. Вы можете указать другой источник или источники инвентаризации в командной строке с помощью параметра -i <path or expression> или системы конфигурации.

Плагины инвентаризации Ansible поддерживают широкий спектр форматов и источников, благодаря чему инвентаризация становится гибкой и настраиваемой. По мере роста инвентаризации для организации хостов и групп может потребоваться несколько файлов. Помимо файла /etc/ansible/hosts, можно воспользоваться следующими распространёнными вариантами:

Вы можете динамически формировать инвентаризацию. Например, можно использовать плагин инвентаризации для составления списка ресурсов у одного или нескольких облачных провайдеров либо из других источников. См. раздел Работа с динамической инвентаризацией.
Можно использовать несколько источников инвентаризации, включая динамическую инвентаризацию и статические файлы. См. раздел Передача нескольких источников инвентаризации.
Можно создать каталог с несколькими статическими или динамическими источниками инвентаризации. См. раздел Организация инвентаризации в каталоге.

Основы инвентаризации: форматы, хосты и группы
Передача нескольких источников инвентаризации
Организация инвентаризации в каталоге
- Управление порядком загрузки инвентаризации
Добавление переменных в инвентаризацию
Назначение переменной одному компьютеру: переменные хоста
- Псевдонимы инвентаризации
Определение переменных в формате INI
Назначение переменной нескольким компьютерам: переменные группы
- Наследование значений переменных: переменные групп для групп групп
Организация переменных хостов и групп
Как объединяются переменные
- Управление порядком загрузки переменных инвентаризации
Подключение к хостам: параметры поведения инвентаризации
- Типы подключений, отличные от SSH
Примеры настройки инвентаризации

В следующих фрагментах YAML многоточие (…) указывает на то, что фрагменты являются частью более крупного файла YAML. Подробнее о синтаксисе YAML см. в разделе Основы YAML.

Основы инвентаризации: форматы, хосты и группы

Вы можете создать файл инвентаризации в одном из множества форматов — в зависимости от используемых плагинов инвентаризации. Наиболее распространены форматы INI и YAML, поскольку Ansible поддерживает их встроенными средствами. В этом введении рассматриваются эти два формата, однако возможны и многие другие форматы и источники.

Пример базового /etc/ansible/hosts в формате INI:

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

Заголовки в квадратных скобках — это имена групп. Используйте имена групп, чтобы классифицировать хосты и определять, какими хостами, когда и для каких целей вы управляете. Имена групп должны соответствовать тем же рекомендациям, что и создание допустимых имён переменных.

Тот же базовый файл инвентаризации в формате YAML:

ungrouped:
  hosts:
    mail.example.com:
webservers:
  hosts:
    foo.example.com:
    bar.example.com:
dbservers:
  hosts:
    one.example.com:
    two.example.com:
    three.example.com:

Группы по умолчанию

Даже если вы не определите в инвентаризации ни одной группы, Ansible создаст две группы по умолчанию: all и ungrouped. Группа all содержит все хосты. Группа ungrouped содержит все хосты, не входящие ни в одну другую группу. Каждый хост всегда принадлежит как минимум двум группам (all и ungrouped либо all и ещё одной группе). Например, в приведённой выше базовой инвентаризации хост mail.example.com принадлежит группам all и ungrouped. Хост two.example.com принадлежит группам all и dbservers. Хотя all и ungrouped присутствуют всегда, они могут быть неявными и не отображаться в списках групп, например в group_names.

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

Хост можно включить более чем в одну группу. Например, рабочий веб-сервер в центре обработки данных в Атланте можно включить в группы [prod], [atlanta] и [webservers]. Вы можете создавать группы по следующим критериям:

Что — приложение, стек или микросервис (например, серверы баз данных, веб-серверы и так далее).
Где — центр обработки данных или регион, чтобы взаимодействовать с локальными DNS, хранилищем и так далее (например, восток, запад).
Когда — этап разработки, чтобы избежать тестирования на рабочих ресурсах (например, prod, test).

В следующем примере предыдущая инвентаризация YAML дополнена критериями «что», «когда» и «где»:

ungrouped:
  hosts:
    mail.example.com:
webservers:
  hosts:
    foo.example.com:
    bar.example.com:
dbservers:
  hosts:
    one.example.com:
    two.example.com:
    three.example.com:
east:
  hosts:
    foo.example.com:
    one.example.com:
    two.example.com:
west:
  hosts:
    bar.example.com:
    three.example.com:
prod:
  hosts:
    foo.example.com:
    one.example.com:
    two.example.com:
test:
  hosts:
    bar.example.com:
    three.example.com:

Как видно из примера, one.example.com входит в группы dbservers, east и prod.

Группировка групп: отношения родительских и дочерних групп

Вы можете создавать отношения родительских и дочерних групп. Родительские группы также называются вложенными группами или группами групп. Например, если все ваши рабочие хосты уже входят в такие группы, как atlanta_prod и denver_prod, можно создать группу production, включающую эти меньшие группы. Такой подход упрощает обслуживание: чтобы добавить хосты в родительскую группу или удалить их из неё, достаточно изменить дочерние группы.

Для создания отношений родительских и дочерних групп воспользуйтесь одним из следующих способов:

В формате INI используйте суффикс :children.
В формате YAML используйте запись children:.

В следующем примере показана та же инвентаризация, что и выше, но она упрощена за счёт родительских групп для групп prod и test:

ungrouped:
  hosts:
    mail.example.com:
webservers:
  hosts:
    foo.example.com:
    bar.example.com:
dbservers:
  hosts:
    one.example.com:
    two.example.com:
    three.example.com:
east:
  hosts:
    foo.example.com:
    one.example.com:
    two.example.com:
west:
  hosts:
    bar.example.com:
    three.example.com:
prod:
  children:
    east:
test:
  children:
    west:

Обратите внимание на следующие свойства дочерних групп:

Любой хост, входящий в дочернюю группу, автоматически становится членом родительской группы.
У группы может быть несколько родительских и дочерних групп, но циклические отношения недопустимы.
Хост может входить в несколько групп, но во время выполнения Ansible обрабатывает только один экземпляр хоста. Ansible объединяет данные из нескольких групп.
Хосты и группы всегда являются «глобальными». Если определить хост или группу несколько раз в разных «ветвях» или «экземплярах», хост или группа останутся той же сущностью. Повторное определение хоста или группы либо добавляет к ним новые сведения, либо перезаписывает конфликтующие сведения последним определением.

Добавление диапазонов хостов

Некоторые плагины, например YAML и INI, поддерживают добавление диапазонов хостов. Если у вас много хостов с похожими именами, вы можете добавить их диапазоном, а не перечислять каждое имя отдельно:

В формате INI:

[webservers]
www[01:50].example.com

В формате YAML:

# ...
  webservers:
    hosts:
      www[01:50].example.com:

При определении числового диапазона хостов можно задать шаг (приращение между номерами последовательности):

В формате INI:

[webservers]
www[01:50:2].example.com

В формате YAML:

# ...
  webservers:
    hosts:
      www[01:50:2].example.com:

Пример выше соответствует поддоменам www01, www03, www05, …, www49, но не www00, www02, www50 и так далее, поскольку шаг (приращение) равен 2.

Для числовых шаблонов можно по желанию добавлять или удалять начальные нули. Диапазоны включают граничные значения. Можно также задавать буквенные диапазоны:

[databases]
db-[a:f].example.com

Передача нескольких источников инвентаризации

Вы можете одновременно использовать несколько источников инвентаризации (статические файлы, каталоги, скрипты динамической инвентаризации или любые источники, поддерживаемые плагинами инвентаризации). Для этого укажите несколько источников инвентаризации в командной строке (см. ниже) или в конфигурации — задав ANSIBLE_INVENTORY либо в ansible.cfg (DEFAULT_HOST_LIST). Эта возможность полезна, когда для определённого действия нужно одновременно выбрать обычно разделённые среды, например промежуточную и рабочую.

Чтобы выбрать два источника инвентаризации из командной строки:

ansible-playbook get_logs.yml -i staging -i production

Организация инвентаризации в каталоге

Вы можете объединить несколько источников инвентаризации в одном каталоге. Самый простой способ — создать каталог с несколькими файлами вместо одного файла инвентаризации. Поддерживать один файл становится трудно, когда он разрастается. Если у вас несколько команд и проектов автоматизации, создание отдельного файла инвентаризации для каждой команды или проекта позволит всем легко находить нужные им хосты и группы. В зависимости от настроек и способа запуска Ansible файлы по-прежнему можно использовать по отдельности или в подмножествах.

В этих файлах можно использовать любые форматы или настройки плагинов (например, YAML или INI). В этом случае каталог становится вашим «единым» источником инвентаризации, а Ansible объединяет несколько источников, найденных в нём. По умолчанию Ansible игнорирует некоторые каталоги и расширения, но это поведение можно изменить в конфигурации (INVENTORY_IGNORE_PATTERNS и INVENTORY_IGNORE_EXTS).

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

inventory/
  openstack.yml          # configure inventory plugin to get hosts from OpenStack cloud
  dynamic-inventory.py   # add additional hosts with dynamic inventory script
  on-prem                # add static hosts and groups
  parent-groups          # add static hosts and groups

Вы можете выбрать этот каталог инвентаризации следующим образом:

ansible-playbook example.yml -i inventory

Вы также можете задать каталог инвентаризации в файле ansible.cfg. Подробнее см. раздел Настройка Ansible.

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

Управление порядком загрузки инвентаризации

Ansible загружает источники инвентаризации в указанном вами порядке. По мере обработки исходных файлов он определяет хосты, группы и переменные, добавляя в конце группы all и ungrouped, если это необходимо.

В зависимости от используемых плагинов инвентаризации может потребоваться изменить порядок источников, чтобы родительские и дочерние группы или хосты были доступны плагинам в ожидаемом виде. В противном случае может возникнуть ошибка разбора. Например, плагины инвентаризации YAML и INI удаляют пустые группы (группы без связанных хостов) после обработки каждого источника.

Если определить переменную несколько раз, Ansible перезапишет предыдущее значение. Используется последнее определение.

Добавление переменных в инвентаризацию

В инвентаризации можно определять переменные, связанные с конкретным хостом или группой. Для начала проще всего добавлять переменные непосредственно к хостам и группам в источнике инвентаризации YAML или INI.

Для простоты в этом руководстве описано, как добавлять переменные в источник инвентаризации. Однако вы также можете использовать плагины переменных, чтобы добавлять переменные из множества других источников. По умолчанию Ansible поставляется с плагином host_group_vars, позволяющим определять переменные в отдельных файлах переменных хостов и групп. Использование отдельных файлов — более надёжный способ описания политик системы, чем определение переменных в источнике инвентаризации. Рекомендации по хранению значений переменных в отдельных файлах в каталогах «host_vars» и «group_vars» см. в разделе Организация переменных хостов и групп.

Назначение переменной одному компьютеру: переменные хоста

Вы можете легко назначить переменную одному хосту, а затем использовать её в плейбуках. Это можно сделать непосредственно в файле инвентаризации.

В формате INI:

[atlanta]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909

В формате YAML:

atlanta:
  hosts:
    host1:
      http_port: 80
      maxRequestsPerChild: 808
    host2:
      http_port: 303
      maxRequestsPerChild: 909

Переменные хоста хорошо подходят для уникальных значений, например нестандартных портов SSH. Добавьте их в инвентаризацию Ansible, указав номер порта после имени хоста через двоеточие:

badwolf.example.com:5309

С помощью переменных хоста можно определять «переменные подключения». Переменные подключения настраивают плагины connection, shell и become, позволяя выполнять задачи на хосте. Например:

[targets]

localhost              ansible_connection=local
other1.example.com     ansible_connection=ssh        ansible_user=myuser
other2.example.com     ansible_connection=ssh        ansible_user=myotheruser

Псевдонимы инвентаризации

inventory_hostname — это уникальный идентификатор хоста в Ansible. Им может быть IP-адрес или имя хоста, а также просто «псевдоним» или краткое имя хоста.

В формате INI:

jumper ansible_port=5555 ansible_host=192.0.2.50

В формате YAML:

# ...
  hosts:
    jumper:
      ansible_port: 5555
      ansible_host: 192.0.2.50

В этом примере при запуске Ansible для хоста с псевдонимом «jumper» выполняется подключение к 192.0.2.50 через порт 5555. Дополнительную настройку подключений к хостам см. в разделе параметры поведения инвентаризации.

Эта возможность также полезна, если нужно выбирать один и тот же хост несколько раз, однако помните, что задачи могут выполняться параллельно:

В формате INI:

jumper1 ansible_port=5555 ansible_host=192.0.2.50
jumper2 ansible_port=5555 ansible_host=192.0.2.50

В формате YAML:

# ...
  hosts:
    jumper1:
      ansible_port: 5555
      ansible_host: 192.0.2.50
    jumper2:
      ansible_port: 5555
      ansible_host: 192.0.2.50

Определение переменных в формате INI

Ansible по-разному интерпретирует значения, переданные в формате INI с использованием синтаксиса key=value, в зависимости от того, где они объявлены:

Если значение объявлено в строке хоста, Ansible интерпретирует значение INI как литеральную структуру Python (например, строку, число, кортеж, список, словарь, логическое значение или None). В строках хостов допускается несколько параметров key=value на строку. Поэтому необходимо обозначить, что пробел является частью значения, а не разделителем. Значения, содержащие пробелы, можно заключать в кавычки (одинарные или двойные). Подробности см. в разделе правил разбора shlex в Python.
Если значение объявлено в разделе :vars, Ansible интерпретирует значение INI как строку. Например, var=FALSE создаёт строку со значением «FALSE». В отличие от строк хостов, разделы :vars допускают только одну запись на строку, поэтому всё, что следует после =, становится значением записи.

Если переменная из инвентаризации INI должна иметь определённый тип (например, строковый или логический), всегда явно задавайте тип с помощью фильтра в задаче. Не полагайтесь на типы, заданные в инвентаризации INI, при использовании переменных.

Чтобы избежать путаницы с фактическим типом переменной, используйте для источников инвентаризации формат YAML. Плагин инвентаризации YAML последовательно и правильно обрабатывает значения переменных.

Назначение переменной нескольким компьютерам: переменные группы

Если все хосты в группе используют одно и то же значение переменной, эту переменную можно назначить сразу всей группе.

В формате INI:

[atlanta]
host1
host2

[atlanta:vars]
ntp_server=ntp.atlanta.example.com
proxy=proxy.atlanta.example.com

В формате YAML:

atlanta:
  hosts:
    host1:
    host2:
  vars:
    ntp_server: ntp.atlanta.example.com
    proxy: proxy.atlanta.example.com

Переменные групп — удобный способ одновременно назначать переменные нескольким хостам. Однако перед выполнением Ansible всегда преобразует переменные в плоскую структуру на уровне хостов, включая переменные инвентаризации. Если хост входит в несколько групп, Ansible считывает значения переменных из всех этих групп. Если одной переменной назначены разные значения в разных группах, Ansible выбирает используемое значение в соответствии с внутренними правилами объединения.

Наследование значений переменных: переменные групп для групп групп

Вы можете назначать переменные как родительским группам (вложенным группам или группам групп), так и дочерним. Синтаксис одинаков: :vars для формата INI и vars: для формата YAML:

В формате INI:

[atlanta]
host1
host2

[raleigh]
host2
host3

[southeast:children]
atlanta
raleigh

[southeast:vars]
some_server=foo.southeast.example.com
halon_system_timeout=30
self_destruct_countdown=60
escape_pods=2

[usa:children]
southeast
northeast
southwest
northwest

В формате YAML:

usa:
  children:
    southeast:
      children:
        atlanta:
          hosts:
            host1:
            host2:
        raleigh:
          hosts:
            host2:
            host3:
      vars:
        some_server: foo.southeast.example.com
        halon_system_timeout: 30
        self_destruct_countdown: 60
        escape_pods: 2
    northeast:
    northwest:
    southwest:

Переменные дочерней группы имеют более высокий приоритет, чем переменные родительской группы (и переопределяют их).

Организация переменных хостов и групп

Хотя переменные можно определять в источнике инвентаризации, для определения альтернативных источников переменных можно также использовать плагины переменных.

Плагин переменных, поставляемый с Ansible по умолчанию, — host_group_vars — позволяет использовать отдельные файлы переменных хостов и групп. Этот способ помогает проще организовать значения переменных. В этих файлах можно также использовать списки и хеш-данные, чего нельзя сделать в основном файле инвентаризации.

Для плагина host_group_vars файлы переменных хостов и групп должны использовать синтаксис YAML. Допустимые расширения файлов: «.yml», «.yaml», «.json» или отсутствие расширения. Если вы впервые работаете с YAML, см. раздел Синтаксис YAML.

Плагин host_group_vars загружает файлы переменных хостов и групп, выполняя поиск относительно источника инвентаризации или файла плейбука. Если файл инвентаризации находится в /etc/ansible/hosts и содержит хост с именем «foosball», принадлежащий группам raleigh и webservers, этот хост будет использовать переменные из файлов YAML в следующих расположениях:

/etc/ansible/group_vars/raleigh # can optionally end in '.yml', '.yaml', or '.json'
/etc/ansible/group_vars/webservers
/etc/ansible/host_vars/foosball

Например, если вы группируете хосты в инвентаризации по центрам обработки данных, а в каждом центре обработки данных используются собственные серверы NTP и баз данных, можно создать файл с именем /etc/ansible/group_vars/raleigh, чтобы хранить переменные для группы raleigh:

---
ntp_server: acme.example.org
database_server: storage.example.org

Можно также создавать каталоги с именами групп или хостов. Ansible считывает все файлы в этих каталогах в лексикографическом порядке. Ниже приведён пример для группы «raleigh»:

/etc/ansible/group_vars/raleigh/db_settings
/etc/ansible/group_vars/raleigh/cluster_settings

Все хосты группы «raleigh» получают доступ к переменным, определённым в этих файлах. Этот способ очень удобен для организации переменных, когда один файл становится слишком большим или когда требуется использовать Ansible Vault для некоторых переменных группы.

Плагин переменных host_group_vars Ansible также может добавлять каталоги group_vars/ и host_vars/ в каталог плейбука при использовании ansible-playbook. Однако не все команды Ansible связаны с плейбуком (например, ansible или ansible-console). Для таких команд можно использовать параметр --playbook-dir, чтобы указать каталог в командной строке. Если источники плагинов переменных расположены относительно каталога плейбука и каталога инвентаризации, переменные, загруженные Ansible относительно каталога плейбука, переопределяют переменные, загруженные относительно источника инвентаризации.

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

Как объединяются переменные

Примечание

Ansible объединяет переменные из разных источников и применяет приоритет одних переменных над другими в соответствии с набором правил. Например, переменные, расположенные выше в инвентаризации, могут переопределять переменные, расположенные ниже. Подробнее см. раздел Приоритет переменных: где следует размещать переменную?.

Перед выполнением плейбука Ansible объединяет переменные и преобразует их в плоскую структуру для конкретного хоста. Благодаря этому Ansible может сосредоточиться на хосте и задаче, а группы не используются вне инвентаризации и сопоставления хостов. По умолчанию Ansible перезаписывает переменные, в том числе определённые для группы или хоста (см. раздел DEFAULT_HASH_BEHAVIOUR). Порядок и приоритет сущностей инвентаризации (от низшего к высшему):

В следующем списке приведён порядок приоритета сущностей инвентаризации от низшего к высшему:

all группа (так как она является «родителем» всех остальных групп)
родительская группа
дочерняя группа
хост

По умолчанию Ansible объединяет группы на одном уровне родительской и дочерней иерархии в алфавитном порядке. Переменные из последней загруженной группы перезаписывают переменные из предыдущих групп. Например, Ansible объединяет a_group с b_group, а совпадающие переменные из b_group перезаписывают переменные в a_group.

Вы можете настроить это поведение объединения, задав переменную группы ansible_group_priority. Она переопределяет алфавитную сортировку при объединении групп одного уровня (после того как Ansible определит порядок родительских и дочерних групп). Чем больше значение, тем позже Ansible объединит группу и тем выше будет её приоритет. Если переменная не задана, по умолчанию используется значение 1. Например:

a_group:
  vars:
    testvar: a
    ansible_group_priority: 10
b_group:
  vars:
    testvar: b

В этом примере, если приоритет обеих групп одинаков, результатом обычно будет testvar == b. Однако, поскольку мы задаём для a_group более высокий приоритет, результатом становится testvar == a.

Задать ansible_group_priority можно только в источнике инвентаризации, но не в group_vars/. Ansible использует эту переменную при загрузке каталога group_vars/.

Управление порядком загрузки переменных инвентаризации

В этом разделе описано, как управлять приоритетом переменных, задавая порядок загрузки источников инвентаризации. Источники можно передавать в определённом порядке в командной строке или добавлять префиксы к именам файлов источников в каталоге.

При использовании нескольких источников инвентаризации помните, что Ansible разрешает конфликты переменных согласно правилам, описанным в разделах Как объединяются переменные и Приоритет переменных: где следует размещать переменную?. Чтобы получить нужное значение переменной, вы можете управлять порядком объединения переменных из источников инвентаризации.

Если передать несколько источников инвентаризации в командной строке, Ansible объединит переменные в порядке передачи этих параметров. Если раздел [all:vars] в инвентаризации промежуточной среды определяет myvar = 1, а инвентаризация рабочей среды определяет myvar = 2, верно следующее:

Если передать -i staging -i production, Ansible запустит плейбук с myvar = 2.
Если передать -i production -i staging, Ansible запустит плейбук с myvar = 1.

Если поместить несколько источников инвентаризации в каталог, Ansible объединит их в алфавитном порядке по именам файлов. Управлять порядком загрузки можно, добавив к файлам префиксы:

inventory/
  01-openstack.yml          # configure inventory plugin to get hosts from Openstack cloud
  02-dynamic-inventory.py   # add additional hosts with dynamic inventory script
  03-static-inventory       # add static hosts
  group_vars/
    all.yml                 # assign variables to all hosts

Если 01-openstack.yml задаёт myvar = 1 для группы all, 02-dynamic-inventory.py задаёт myvar = 2, а 03-static-inventory задаёт myvar = 3, Ansible запустит плейбук с myvar = 3.

Дополнительные сведения о плагинах инвентаризации и скриптах динамической инвентаризации см. в разделах Плагины инвентаризации и Работа с динамической инвентаризацией.

Подключение к хостам: параметры инвентаризации поведения

Как описано выше, можно задать следующие переменные, чтобы управлять взаимодействием Ansible с удалёнными хостами.

Подключение к хосту:

Примечание

Ansible не предоставляет канал для взаимодействия пользователя с процессом ssh, который позволил бы вручную ввести пароль для расшифровки ключа ssh при использовании плагина подключения ssh (используемого по умолчанию). Настоятельно рекомендуется использовать ssh-agent.

ansible_connection: Указывает тип подключения к хосту. Это может быть имя любого плагина подключения Ansible. Типы протокола SSH — ssh или paramiko. По умолчанию используется ssh.

Общие параметры для всех подключений:

ansible_host: Указывает разрешаемое имя или IP-адрес хоста для подключения, если он отличается от псевдонима, который вы хотите ему присвоить. Не задавайте для него зависимость от inventory_hostname. Если вам действительно нужно что-то подобное, используйте inventory_hostname_short, чтобы это работало с делегированием.
ansible_port: Номер порта подключения, если он отличается от порта по умолчанию (22 для ssh).
ansible_user: Имя пользователя для подключения (входа) на хост.
ansible_password: Пароль для аутентификации на хосте. (Никогда не храните эту переменную в открытом виде. Всегда используйте хранилище. См. Безопасный просмотр переменных, зашифрованных в хранилище.)

Параметры, специфичные для плагина подключения SSH:

ansible_ssh_private_key_file: Файл закрытого ключа, используемый SSH. Это полезно, если вы используете несколько ключей и не хотите использовать агент SSH.
ansible_ssh_common_args: Ansible всегда добавляет эту настройку к командной строке по умолчанию для sftp, scp и ssh. Это полезно для настройки ProxyCommand для определённого хоста или группы.
ansible_sftp_extra_args: Ansible всегда добавляет эту настройку к командной строке sftp по умолчанию.
ansible_scp_extra_args: Ansible всегда добавляет эту настройку к командной строке scp по умолчанию.
ansible_ssh_extra_args: Ansible всегда добавляет эту настройку к командной строке ssh по умолчанию.
ansible_ssh_pipelining: Указывает, следует ли использовать конвейеризацию SSH. Это может переопределить настройку pipelining в ansible.cfg.
ansible_ssh_executable (добавлено в версии 2.2): Эта настройка переопределяет поведение по умолчанию, при котором используется системный ssh. Она может переопределить настройку ssh_executable в разделе ssh_connection файла ansible.cfg.

Повышение привилегий (подробности см. в разделе Повышение привилегий в Ansible):

ansible_become: Эквивалент ansible_sudo или ansible_su; позволяет принудительно включить повышение привилегий.
ansible_become_method: Позволяет задать метод повышения привилегий, соответствующий плагину become.
ansible_become_user: Эквивалент ansible_sudo_user или ansible_su_user; позволяет задать пользователя, от имени которого выполняется повышение привилегий.
ansible_become_password: Эквивалент ansible_sudo_password или ansible_su_password; позволяет задать пароль для повышения привилегий. (Никогда не храните эту переменную в открытом виде. Всегда используйте хранилище. См. Безопасный просмотр переменных, зашифрованных в хранилище.)
ansible_become_exe: Эквивалент ansible_sudo_exe или ansible_su_exe; позволяет задать исполняемый файл для выбранного метода повышения привилегий.
ansible_become_flags: Эквивалент ansible_sudo_flags или ansible_su_flags; позволяет задать флаги, передаваемые выбранному методу повышения привилегий. Их также можно задать глобально в ansible.cfg, в параметре become_flags раздела privilege_escalation.

Параметры среды удалённого хоста:

ansible_shell_type: Указывает тип оболочки целевой системы. Не используйте эту настройку, если только вы не задали для ansible_shell_executable оболочку, несовместимую с Bourne (sh). По умолчанию Ansible формирует команды с использованием синтаксиса в стиле sh. Если задать csh или fish, команды, выполняемые Ansible в целевых системах, будут соответствовать синтаксису этих оболочек.

ansible_python_interpreter: Указывает путь к Python на целевом хосте. Это полезно для систем, в которых установлено несколько версий Python, а также для систем, где Python находится не в /usr/bin/python, например *BSD, или где /usr/bin/python указывает не на Python серии 2.X. Мы не используем механизм /usr/bin/env, поскольку для этого требуется правильно настроенный путь удалённого пользователя, а также предполагается, что исполняемый файл python называется python, хотя он может называться, например, python2.6.
ansible_*_interpreter: Работает для любых языков, например Ruby или Perl, аналогично ansible_python_interpreter. Эта переменная заменяет строку shebang модулей, которые будут выполняться на этом хосте.

Добавлено в версии 2.1.

ansible_shell_executable: Эта настройка задаёт оболочку, которую управляющий узел Ansible будет использовать на целевой машине. Она переопределяет executable в ansible.cfg, значением по умолчанию которого является /bin/sh. Изменяйте это значение, только если использовать /bin/sh невозможно (то есть если /bin/sh не установлен на целевой машине или его нельзя запустить с помощью sudo).

Примеры файла хостов в формате Ansible-INI:

some_host         ansible_port=2222     ansible_user=manager
aws_host          ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
freebsd_host      ansible_python_interpreter=/usr/local/bin/python
ruby_module_host  ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

Типы подключений, отличные от SSH

Как указано в предыдущем разделе, по умолчанию Ansible выполняет плейбуки через SSH, однако этот тип подключения не является единственным. Тип подключения можно изменить с помощью параметра для конкретного хоста ansible_connection=<connection plugin name>. Полный список доступных плагинов и примеры см. в разделе Список плагинов.

Примеры настройки инвентаря

См. также Пример настройки Ansible, где показаны инвентарь, плейбуки и другие артефакты Ansible.

Пример: отдельный инвентарь для каждой среды

Если вам нужно управлять несколькими средами, рассмотрите возможность включать в каждый инвентарь только хосты одной среды. Так будет сложнее, например, случайно изменить состояние узлов в среде «test», когда вы хотели обновить несколько серверов в среде «staging».

Для упомянутого выше примера можно создать файл inventory_test:

[dbservers]
db01.test.example.com
db02.test.example.com

[appservers]
app01.test.example.com
app02.test.example.com
app03.test.example.com

Этот файл включает только хосты, относящиеся к среде «test». Можно определить машины среды «staging» в другом файле с именем inventory_staging:

[dbservers]
db01.staging.example.com
db02.staging.example.com

[appservers]
app01.staging.example.com
app02.staging.example.com
app03.staging.example.com

Чтобы применить плейбук с именем site.yml ко всем серверам приложений в тестовой среде, используйте следующую команду:

ansible-playbook -i inventory_test -l appservers site.yml

Пример: группировка по функциям

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

- hosts: dbservers
  tasks:
  - name: Allow access from 10.0.0.1
    ansible.builtin.iptables:
      chain: INPUT
      jump: ACCEPT
      source: 10.0.0.1

Пример: группировка по расположению

Другие задачи могут зависеть от местоположения определённого хоста. Предположим, что db01.test.example.com и app01.test.example.com находятся в DC1, а db02.test.example.com — в DC2:

[dc1]
db01.test.example.com
app01.test.example.com

[dc2]
db02.test.example.com

На практике вам может понадобиться сочетать все эти подходы. Например, в один день может потребоваться обновить все узлы в определённом центре обработки данных, а в другой — все серверы приложений независимо от их местоположения.

См. также

Плагины инвентаря: Получение инвентаря из динамических или статических источников
Работа с динамическим инвентарём: Получение инвентаря из динамических источников, например облачных провайдеров
Введение в команды ad hoc: Примеры основных команд
Работа с плейбуками: Знакомство с языком настройки, развёртывания и оркестрации Ansible.
Общение: Есть вопросы? Нужна помощь? Хотите поделиться идеями? Посетите руководство по общению Ansible

© 2012–2018 Michael DeHaan
© 2018–2025 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/projects/ansible/latest/inventory_guide/intro_inventory.html