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

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

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

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

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

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

Примечание

Следующие фрагменты YAML включают многоточие, чтобы указать, что они являются частью большего файла YAML. Подробнее о синтаксисе YAML вы можете узнать на странице Основы YAML.

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

Вы можете создать свой файл инвентаря в одном из многих форматов, в зависимости от имеющихся у вас плагинов инвентаря. Наиболее распространенные форматы — INI и YAML. Базовый INI /etc/ansible/hosts может выглядеть так:

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. Каждый хост всегда будет принадлежать как минимум двум группам (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 объединяет данные из нескольких групп.

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

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

В формате 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. Это может быть полезно, когда вы хотите одновременно нацеливаться на обычно отдельные среды, такие как staging и production, для определенного действия.

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

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

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

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

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

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 загружает источники инвентаризации в порядке ASCII в соответствии с именами файлов. Если вы определяете родительские группы в одном файле или каталоге, а дочерние группы — в других файлах или каталогах, файлы, определяющие дочерние группы, должны загружаться первыми. Если родительские группы загружаются первыми, вы увидите ошибку Unable to parse /path/to/source_of_parent_groups as an inventory source.

Например, если у вас есть файл с именем groups-of-groups который определяет группу production с дочерними группами, определенными в файле с именем on-prem, Ansible не сможет обработать группу production. Чтобы избежать этой проблемы, вы можете управлять порядком загрузки, добавляя префиксы к файлам:

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-on-prem                # add static hosts and groups
  04-groups-of-groups       # add parent groups

Примеры организации инвентаризации и группировки хостов см. в Примерах настройки инвентаризации.

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

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

Для простоты мы документируем добавление переменных в основной файл инвентаризации. Однако более надежный подход к описанию вашей политики системы — хранение переменных в отдельных файлах переменных хостов и групп. Установка переменных в основном файле инвентаризации — это только сокращение. См. Организацию переменных хостов и групп для руководств по хранению значений переменных в отдельных файлах в каталоге «host_vars». См. Организацию переменных хостов и групп для получения подробных сведений.

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

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

В формате 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

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

[targets]

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

Примечание

Если вы перечислите нестандартные порты SSH в вашем файле конфигурации SSH, подключение openssh найдет и использует их, но подключение paramiko не будет.

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

Вы также можете определить псевдонимы в вашей инвентаризации с помощью переменных хоста:

В формате 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

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

При объявлении в строке хоста значения INI интерпретируются как структуры литералов Python (строки, числа, кортежи, списки, словари, булевы значения, None). Строки хостов принимают несколько параметров key=value в строке. Поэтому им нужен способ указать, что пробел является частью значения, а не разделителем. Значения, содержащие пробелы, могут быть заключены в кавычки (одинарные или двойные). Подробности см. в правилах синтаксического разбора Python shlex.
При объявлении в секции :vars, значения 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:

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

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

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

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

Ansible загружает файлы переменных хостов и групп, выполняя поиск путей, относящихся к файлу инвентаризации или файлу playbook. Если ваш файл инвентаризации по адресу /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 для некоторых переменных групп.

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

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

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

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

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

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

Примечание

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

Вы можете изменить это поведение, задав переменную группы ansible_group_priority для изменения порядка объединения групп на одном уровне (после разрешения порядка родитель/дочерний). Чем больше число, тем позже она будет объединена, что придаст ей больший приоритет. Эта переменная по умолчанию 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/, поскольку переменная используется при загрузке group_vars.

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

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

Когда вы передаёте несколько источников инвентаризации в командной строке, Ansible объединяет переменные в том порядке, в котором вы передаёте эти параметры. Если [all:vars] в инвентаризации staging определяет myvar = 1 и инвентаризация production определяет myvar = 2, то:

Передача -i staging -i production для выполнения playbook с myvar = 2.
Передача -i production -i staging для выполнения playbook с 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, воспроизведение будет выполнено с myvar = 3.

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

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

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

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

Примечание

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

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

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

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

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

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

Масштабирование привилегий (см. Масштабирование привилегий Ansible для получения дополнительной информации):

ansible_become: Эквивалентно ansible_sudo или ansible_su, позволяет принудительно выполнить повышение привилегий
ansible_become_method: Позволяет установить метод повышения привилегий
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). По умолчанию команды форматируются с использованием синтаксиса sh-стиля. Установка значения csh или fish заставит команды, выполняемые на целевых системах, следовать синтаксису соответствующей оболочки вместо этого.

ansible_python_interpreter: Путь к 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=<connector>, тип подключения может быть изменён. Полный список доступных плагинов и примеры см. в списке плагинов.

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

См. также Примеры настройки Ansible, который демонстрирует инвентаризацию вместе с книгами задач и другими артефактами Ansible.

Пример: Один инвентарь на одну среду

Если вам нужно управлять несколькими средами, иногда целесообразно определять только хосты одной среды в одном инвентаре. Таким образом, например, случайно изменить состояние узлов в среде «тест», когда вы хотели обновить некоторые серверы «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

В этом файле указаны только хосты, которые являются частью среды «тест». Определите машины «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 находятся в ЦОД1, а db02.test.example.com — в ЦОД2:

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

[dc2]
db02.test.example.com

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

См. также

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

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