Работа с инвентарём

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

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

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

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

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

mail.example.com

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

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

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

Версия YAML будет выглядеть так:

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

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

Вы можете помещать системы в более чем одну группу, например, сервер может быть одновременно веб-сервером и принадлежать определённому дата-центру. Например, вы можете создавать группы для отслеживания:

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

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

all:
  hosts:
    mail.example.com:
  children:
    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.

Вы также можете использовать вложенные группы для упрощения prod и test в этом инвентаре, для того же результата:

all:
  hosts:
    mail.example.com:
  children:
    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:

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

Хосты и нестандартные порты

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

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

badwolf.example.com:5309

Предположим, у вас есть только статические 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:

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

В YAML:

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

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

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

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

[targets]

localhost              ansible_connection=local
other1.example.com     ansible_connection=ssh        ansible_user=mpdehaan
other2.example.com     ansible_connection=ssh        ansible_user=mdehaan

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

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

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

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

Версия YAML:

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

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

Переменные также можно применить к целой группе сразу:

Способ 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

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

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

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

[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

all:
  children:
    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:

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

• Любой хост, который является членом дочерней группы, автоматически является членом родительской группы.
• Переменные дочерней группы будут иметь более высокий приоритет (переопределение) переменных родительской группы.
• Группы могут иметь несколько родителей и детей, но не циклические связи.
• Хосты также могут быть в нескольких группах, но будет только **один** экземпляр хоста, объединяющий данные из нескольких групп.

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

Существует две группы по умолчанию: all и ungrouped. all содержит каждый хост. ungrouped содержит все хосты, которые не имеют других групп, кроме all. Каждый хост всегда будет принадлежать как минимум 2 группам. Хотя all и ungrouped всегда присутствуют, они могут быть неявными и не отображаться в списках групп, как group_names.

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

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

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

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

Допустим, например, что ваш файл инвентаря находится в /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

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

Подсказка: каталоги group_vars/ и host_vars/ могут находиться в каталоге с playbook или в каталоге инвентаризации. Если оба пути существуют, переменные в каталоге playbook переопределят переменные, заданные в каталоге инвентаризации.

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

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

Как происходит слияние переменных

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

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

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

Начиная с версии Ansible 2.4, пользователи могут использовать переменную группы ansible_group_priority для изменения порядка слияния групп одного уровня (после разрешения порядка родитель/дочерний). Чем больше число, тем позже она будет объединена, придавая ей более высокий приоритет. Эта переменная по умолчанию равна 1, если не задана. Например:

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

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

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

В качестве расширенного случая вы можете одновременно нацеливаться на несколько источников инвентаризации (каталоги, динамические скрипты инвентаризации или файлы, поддерживаемые плагинами инвентаризации), указав несколько параметров инвентаризации из командной строки или настроив ANSIBLE_INVENTORY. Это может быть полезно, когда вы хотите одновременно нацелиться на разные среды, например, staging и production, для определённого действия.

Укажите два источника из командной строки так:

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

Помните, что если в инвентарях есть конфликты переменных, они разрешаются в соответствии с правилами, описанными в Как происходит слияние переменных и Приоритет переменных: Где следует поместить переменную?. Порядок слияния контролируется порядком параметров источника инвентаризации. Если [all:vars] в инвентаре staging определяет myvar = 1, а production инвентарь определяет myvar = 2, playbook будет запущен с myvar = 2. Результат будет обратным, если playbook запущен с -i production -i staging.

Объединение источников инвентаризации с каталогом

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

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

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

ansible-playbook example.yml -i inventory

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

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, playbook будет запущен с myvar = 3.

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

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

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

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

ansible_connection

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

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

ansible_host

Имя хоста для подключения, если оно отличается от псевдонима, который вы хотите ему присвоить.

ansible_port

Номер порта подключения, если он не по умолчанию (22 для ssh)

ansible_user

Имя пользователя для подключения к хосту

ansible_password

Пароль для аутентификации на хосте (никогда не храните эту переменную в открытом виде; всегда используйте vault. См. Переменные и Vault)

Указанные параметры для подключения 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.

Масштабирование привилегий (подробнее см. Масштабирование привилегий 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, позволяет установить пароль для масштабирования привилегий (никогда не храните эту переменную в открытом виде; всегда используйте vault. См. Переменные и Vault)

ansible_become_exe

Аналогично ansible_sudo_exe или ansible_su_exe, позволяет установить исполняемый файл для выбранного метода масштабирования.

ansible_become_flags

Аналогично ansible_sudo_flags или ansible_su_flags, позволяет установить флаги, передаваемые выбранному методу масштабирования. Это также может быть установлено глобально в ansible.cfg в опции sudo_flags

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

ansible_shell_type

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

ansible_python_interpreter

Путь к интерпретатору Python на целевом хосте. Это полезно для систем с несколькими Python или Python, не расположенным по адресу /usr/bin/python, например, в *BSD, или когда /usr/bin/python не является интерпретатором Python версии 2.X. Мы не используем механизм /usr/bin/env, так как это требует правильной настройки переменной PATH у удалённого пользователя и предполагает, что исполняемый файл python имеет имя python, тогда как исполняемый файл может называться, например, python2.6.

ansible_*_interpreter

Подходит для любых языков, таких как ruby или perl, и работает так же, как ansible_python_interpreter. Это заменяет shebang модулей, которые будут выполняться на этом хосте.

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 выполняет playbook'и через SSH, но не ограничивается этим типом соединения. С помощью параметра, специфичного для хоста, ansible_connection=<connector>, тип соединения можно изменить. Доступны следующие подключения без SSH:

local

Это соединение может быть использовано для развертывания playbook на самой управляющей машине.

docker

Это соединение развертывает playbook непосредственно в контейнеры Docker с использованием локального клиента Docker. Следующие параметры обрабатываются этим соединением:

ansible_host

Имя контейнера Docker, к которому нужно подключиться.

ansible_user

Имя пользователя для работы внутри контейнера. Пользователь должен существовать внутри контейнера.

ansible_become

Если установлено значение true, то будет использоваться become_user, чтобы работать внутри контейнера.

ansible_docker_extra_args

Может быть строкой с любыми дополнительными аргументами, понятными Docker, которые не относятся к конкретной команде. Этот параметр в основном используется для настройки удаленного демона Docker для использования.

Вот пример того, как мгновенно развернуть playbook в созданных контейнерах:

- name: create jenkins container
  docker_container:
    docker_host: myserver.net:4243
    name: my_jenkins
    image: jenkins

- name: add container to inventory
  add_host:
    name: my_jenkins
    ansible_connection: docker
    ansible_docker_extra_args: "--tlsverify --tlscacert=/path/to/ca.pem --tlscert=/path/to/client-cert.pem --tlskey=/path/to/client-key.pem -H=tcp://myserver.net:4243"
    ansible_user: jenkins
  changed_when: false

- name: create directory for ssh keys
  delegate_to: my_jenkins
  file:
    path: "/var/jenkins_home/.ssh/jupiter"
    state: directory