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

• Хосты и группы
• Переменные хостов
• Переменные групп
• Группы групп и переменные групп
• Группы по умолчанию
• Выделение данных, специфичных для хостов и групп
• Как объединяются переменные
• Список параметров поведения инвентаря
• Типы подключений, не основанные на 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:

Разрешено размещать системы в нескольких группах, например, сервер может быть одновременно веб-сервером и сервером базы данных. Если вы это делаете, обратите внимание, что переменные будут взяты из всех групп, членами которых они являются. Порядок приоритета переменных подробно описан в последующей главе.

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

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

[webservers]
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

Переменные групп

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

Способ 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. Каждый хост всегда будет принадлежать как минимум двум группам. Хотя all и ungrouped всегда присутствуют, они могут быть неявными и не отображаться в списках групп, таких как group_names.

Выделение данных, специфичных для хостов и групп

Рекомендуемая практика в Ansible – не хранить переменные в основном файле инвентаря.

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

Эти файлы переменных в формате 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

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

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

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

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

• группа 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 с удалёнными хостами.

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

ansible_connection

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

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

ansible_host

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

ansible_port

Номер порта SSH, если он не 22

ansible_user

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

Специфично для подключения SSH:

ansible_ssh_pass

Пароль 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_pass

Эквивалентно ansible_sudo_pass или ansible_su_pass, позволяет установить пароль для масштабирования привилегий (никогда не храните эту переменную в виде простого текста; всегда используйте хранилище. См. Переменные и хранилища)

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