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

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

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

Вот пример того, как мгновенно развернуть 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