Инвентаризация

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

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

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

Список параметров поведенческой инвентаризации

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