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

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

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

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

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

Файл инвентаря может быть в одном из нескольких форматов, в зависимости от используемых вами плагинов инвентаря. Наиболее распространенные форматы — 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:

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:

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

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

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

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

• Что — Приложение, стек или микросервис. (Например, серверы баз данных, веб-серверы и т. д.).
• Где — Дата-центр или регион, для работы с локальным 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:

Дополнительные примеры организации инвентарей и группировки хостов можно найти в примерах настройки инвентаря.

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

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

В INI:

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

В YAML:

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

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

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

Добавление переменных в инвентарь

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

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

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

[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

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

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

Вы также можете определить псевдонимы в своём инвентаре:

В 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. Это работает только для хостов со статическими IP-адресами или при подключении через туннели.

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

Назначение переменной многим машинам: переменные групп

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

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

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

В 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:

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:

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

У дочерних групп есть несколько свойств, которые следует отметить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помните, что если в инвентаризациях есть конфликты переменных, они разрешаются в соответствии с правилами, описанными в Как происходят слияния переменных и Приоритет переменных: куда поместить переменную?. Порядок слияния контролируется порядком параметров источника инвентаризации. Если [all:vars] в эталонной инвентаризации определяет myvar = 1, а производственная инвентаризация определяет myvar = 2, в книге задач будет выполняться с myvar = 2. Результат будет обратным, если книга задач будет запущена с -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, в книге задач будет выполняться с myvar = 3.

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

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

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

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

ansible_connection

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

Общие для всех подключений:

ansible_host

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

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.

Эскалация привилегий (см. Эскалация привилегий в 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 в опции sudo_flags

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

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 модулей, которые будут выполняться на этом хосте.

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-демона.

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

- 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

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

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

Пример: Одна инвентаризация на среду

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

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

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

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

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

- hosts: dbservers
  tasks:
  - name: allow access from 10.0.0.1
    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

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