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

• Пример скрипта инвентаризации: Cobbler
• Пример скрипта инвентаризации: AWS EC2
• Пример скрипта инвентаризации: OpenStack
  • Явное использование скрипта инвентаризации OpenStack
  • Неявное использование скрипта инвентаризации OpenStack
  • Обновление кэша
• Другие скрипты инвентаризации
• Использование каталогов инвентаризации и нескольких источников инвентаризации
• Статические группы динамических групп

Если ваш инвентарь Ansible меняется со временем, с хостами, которые включаются и выключаются в ответ на бизнес-требования, статические решения инвентаризации, описанные в Как создать свой инвентарь, не подойдут. Возможно, вам нужно отслеживать хосты из нескольких источников: облачные провайдеры, LDAP, Cobbler и/или корпоративные системы CMDB.

Ansible интегрирует все эти варианты через динамическую внешнюю систему инвентаризации. Ansible поддерживает два способа подключения к внешнему инвентарю: Плагины инвентаризации и скрипты инвентаризации.

Плагины инвентаризации используют самые свежие обновления ядра Ansible. Мы рекомендуем плагины вместо скриптов для динамического инвентаризации. Вы можете создать собственный плагин для подключения к дополнительным источникам динамического инвентаризации.

Вы всё ещё можете использовать скрипты инвентаризации, если вы этого хотите. При реализации плагинов инвентаризации мы гарантировали обратную совместимость через плагин скрипта инвентаризации. Примеры ниже иллюстрируют, как использовать скрипты инвентаризации.

Если вам нужен графический интерфейс для управления динамическим инвентарём, база данных инвентаризации Red Hat Ansible Tower синхронизируется со всеми вашими источниками динамического инвентаризации, предоставляет веб- и REST-доступ к результатам и предлагает графический редактор инвентаризации. Имея базу данных всех ваших хостов, вы можете сопоставить историю прошлых событий и увидеть, какие хосты испытывали сбои во время последних запусков плейбуков.

Пример скрипта инвентаризации: Cobbler

Ansible бесшовно интегрируется с Cobbler, сервером установки Linux, первоначально написанным Майклом ДеХааном и сейчас возглавляемым Джеймсом Каммаратой, работающим в Ansible.

Хотя Cobbler в первую очередь используется для запуска установок ОС и управления DHCP и DNS, у него есть общий уровень, который может представлять данные для нескольких систем управления конфигурацией (даже одновременно) и служить «лёгкой CMDB».

Чтобы связать ваш инвентарь Ansible с Cobbler, скопируйте этот скрипт в /etc/ansible и chmod +x файл. Запустите cobblerd всякий раз, когда вы используете Ansible, и используйте опцию командной строки -i (например, -i /etc/ansible/cobbler.py) для связи с Cobbler с помощью API XMLRPC Cobbler.

Добавьте файл cobbler.ini в /etc/ansible, чтобы Ansible знал, где находится сервер Cobbler, и можно было использовать некоторые улучшения кэша. Например:

[cobbler]

# Set Cobbler's hostname or IP address
host = http://127.0.0.1/cobbler_api

# API calls to Cobbler can be slow. For this reason, we cache the results of an API
# call. Set this to the path you want cache files to be written to. Two files
# will be written to this directory:
#   - ansible-cobbler.cache
#   - ansible-cobbler.index

cache_path = /tmp

# The number of seconds a cache file is considered valid. After this many
# seconds, a new API call will be made, and the cache file will be updated.

cache_max_age = 900

Сначала протестируйте скрипт, запустив /etc/ansible/cobbler.py напрямую. Вы должны увидеть некоторые данные JSON, но, возможно, пока в них ничего нет.

Давайте разберём, что это делает. В Cobbler рассмотрим сценарий, похожий на следующий:

cobbler profile add --name=webserver --distro=CentOS6-x86_64
cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3"
cobbler system edit --name=foo --dns-name="foo.example.com" --mgmt-classes="atlanta" --ksmeta="c=4"
cobbler system edit --name=bar --dns-name="bar.example.com" --mgmt-classes="atlanta" --ksmeta="c=5"

В примере выше система ‘foo.example.com’ непосредственно доступна для ansible, но также доступна при использовании имён групп ‘webserver’ или ‘atlanta’. Поскольку Ansible использует SSH, он связывается с системой foo по адресу ‘foo.example.com’, только никогда просто ‘foo’. Аналогично, если вы попытаетесь выполнить «ansible foo», он не найдёт систему… но «ansible ‘foo*’» найдёт, потому что имя DNS системы начинается с ‘foo’.

Скрипт предоставляет больше, чем информацию о хостах и группах. Кроме того, в качестве бонуса, когда модуль ‘setup’ выполняется (что происходит автоматически при использовании плейбуков), переменные ‘a’, ‘b’ и ‘c’ автоматически заполняются в шаблонах:

# file: /srv/motd.j2
Welcome, I am templated with a value of a={{ a }}, b={{ b }}, and c={{ c }}

Что можно выполнить так:

ansible webserver -m setup
ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd"

Итак, используя шаблон выше (motd.j2), это приведёт к записи следующих данных в /etc/motd для системы ‘foo’:

Welcome, I am templated with a value of a=2, b=3, and c=4

И на системе ‘bar’ (bar.example.com):

Welcome, I am templated with a value of a=2, b=3, and c=5

И технически, хотя нет веской причины для этого, это тоже работает:

ansible webserver -m shell -a "echo {{ a }}"

Другими словами, вы можете использовать эти переменные в аргументах/действиях.

Пример скрипта инвентаризации: AWS EC2

Если вы используете Amazon Web Services EC2, ведение файла инвентаризации может быть не лучшим подходом, так как хосты могут появляться и исчезать со временем, управляться внешними приложениями, или вы можете даже использовать автоматическое масштабирование AWS. По этой причине вы можете использовать скрипт внешней инвентаризации EC2.

Вы можете использовать этот скрипт двумя способами. Самый простой способ — использовать опцию командной строки Ansible -i и указать путь к скрипту после обозначения его как исполняемого:

ansible -i ec2.py -u ubuntu us-east-1d -m ping

Второй вариант — скопировать скрипт в /etc/ansible/hosts и chmod +x его. Также необходимо скопировать файл ec2.ini в /etc/ansible/ec2.ini. Затем вы можете запустить ansible как обычно.

Для успешного вызова API к AWS необходимо настроить Boto (Python-интерфейс к AWS). Это можно сделать несколькими способами, но самый простой — экспортировать две переменные среды:

export AWS_ACCESS_KEY_ID='AK123'
export AWS_SECRET_ACCESS_KEY='abc123'

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

cd contrib/inventory
./ec2.py --list

Через некоторое время вы должны увидеть весь свой инвентарь EC2 по всем регионам в JSON.

Если вы используете профили Boto для управления несколькими учётными записями AWS, вы можете передать --profile PROFILE имя скрипту ec2.py. Пример профиля:

[profile dev]
aws_access_key_id = <dev access key>
aws_secret_access_key = <dev secret key>

[profile prod]
aws_access_key_id = <prod access key>
aws_secret_access_key = <prod secret key>

Затем вы можете запустить ec2.py --profile prod для получения инвентаризации для учётной записи prod, хотя этот вариант не поддерживается ansible-playbook. Вы также можете использовать переменную AWS_PROFILE, например: AWS_PROFILE=prod ansible-playbook -i ec2.py myplaybook.yml.

Поскольку каждый регион требует свой собственный вызов API, если вы используете только небольшой набор регионов, вы можете отредактировать файл ec2.ini и прокомментировать регионы, которыми вы не пользуетесь.

В файле ec2.ini есть другие опции конфигурации, включая контроль кэша и переменные назначения. По умолчанию, файл ec2.ini настроен для всех облачных сервисов Amazon, но вы можете прокомментировать любые функции, которые не применимы. Например, если у вас нет RDS или elasticache, вы можете установить их в False:

[ec2]
...

# To exclude RDS instances from the inventory, uncomment and set to False.
rds = False

# To exclude ElastiCache instances from the inventory, uncomment and set to False.
elasticache = False
...

В основе своей, файлы инвентаризации — это просто сопоставление между именем и целевым адресом. Значения ec2.ini по умолчанию настроены для запуска Ansible извне EC2 (например, с вашего ноутбука) — и это не самый эффективный способ управления EC2.

Если вы запускаете Ansible изнутри EC2, внутренние имена DNS и IP-адреса могут быть более целесообразны, чем общедоступные имена DNS. В этом случае вы можете изменить destination_variable в ec2.ini на частное имя DNS экземпляра. Это особенно важно при работе с Ansible внутри частной подсети внутри VPC, где единственный способ доступа к экземпляру — через его частный IP-адрес. Для экземпляров VPC, vpc_destination_variable в ec2.ini предоставляет возможность использовать ту переменную boto.ec2.instance, которая больше всего подходит для вашего случая.

Скрипт внешней инвентаризации EC2 предоставляет сопоставления для экземпляров из нескольких групп:

Global

Все экземпляры находятся в группе ec2.

Идентификатор экземпляра

Это группы из одного экземпляра, так как идентификаторы экземпляров уникальны. Например, i-00112233 i-a1b1c1d1.

Регион

Группа всех экземпляров в регионе AWS. Например, us-east-1 us-west-2.

Зона доступности

Группа всех экземпляров в зоне доступности. Например, us-east-1a us-east-1b.

Группа безопасности

Экземпляры принадлежат одной или нескольким группам безопасности. Группа создаётся для каждой группы безопасности, при этом все символы, кроме букв и цифр, преобразуются в нижнее подчеркивание (_). Каждая группа начинается с security_group_. В настоящее время дефисы (-) также преобразуются в нижнее подчеркивание (_). Вы можете изменить это, используя параметр replace_dash_in_groups в ec2.ini (это менялось между версиями, поэтому проверьте ec2.ini для деталей). Например, security_group_default security_group_webservers security_group_Pete_s_Fancy_Group.

Теги

Каждый экземпляр может иметь различные пары ключ/значение, называемые тегами. Наиболее распространённым ключом тега является ‘Name’, но возможно всё что угодно. Каждая пара ключ/значение — это своя группа экземпляров, опять же со специальными символами, преобразованными в нижнее подчеркивание, в формате tag_KEY_VALUE. Например, tag_Name_Web может использоваться как есть, tag_Name_redis-master-001 преобразуется в tag_Name_redis_master_001 tag_aws_cloudformation_logical-id_WebServerGroup преобразуется в tag_aws_cloudformation_logical_id_WebServerGroup.

Когда Ansible взаимодействует с конкретным сервером, скрипт инвентаризации EC2 снова вызывается с параметром --host HOST. Это ищет HOST в кэше индекса для получения идентификатора экземпляра, а затем выполняет вызов API к AWS для получения информации об этом конкретном экземпляре. Затем информация об этом экземпляре становится доступной как переменные для ваших плейбуков. Каждая переменная начинается с префикса ec2_. Вот некоторые доступные переменные:

• ec2_architecture
• ec2_description
• ec2_dns_name
• ec2_id
• ec2_image_id
• ec2_instance_type
• ec2_ip_address
• ec2_kernel
• ec2_key_name
• ec2_launch_time
• ec2_monitored
• ec2_ownerId
• ec2_placement
• ec2_platform
• ec2_previous_state
• ec2_private_dns_name
• ec2_private_ip_address
• ec2_public_dns_name
• ec2_ramdisk
• ec2_region
• ec2_root_device_name
• ec2_root_device_type
• ec2_security_group_ids
• ec2_security_group_names
• ec2_spot_instance_request_id
• ec2_state
• ec2_state_code
• ec2_state_reason
• ec2_status
• ec2_subnet_id
• ec2_tag_Name
• ec2_tenancy
• ec2_virtualization_type
• ec2_vpc_id

Оба ec2_security_group_ids и ec2_security_group_names — это списки всех групп безопасности, разделённые запятыми. Каждый тег EC2 — это переменная в формате ec2_tag_KEY.

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

cd contrib/inventory
./ec2.py --host ec2-12-12-12-12.compute-1.amazonaws.com

Обратите внимание, что скрипт инвентаризации AWS кэширует результаты, чтобы избежать повторных вызовов API, и эта настройка кэша настраивается в ec2.ini. Чтобы явно очистить кэш, вы можете запустить скрипт ec2.py с параметром --refresh-cache.

./ec2.py --refresh-cache

Пример скрипта инвентаризации: OpenStack

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

Вы можете скачать последнюю версию скрипта инвентаризации OpenStack здесь.

Вы можете использовать скрипт инвентаризации явно (передав аргумент -i openstack_inventory.py в Ansible) или неявно (разместив скрипт по адресу /etc/ansible/hosts).

Явное использование скрипта динамической инвентаризации OpenStack

Загрузите последнюю версию скрипта динамической инвентаризации OpenStack и сделайте его исполняемым:

wget https://raw.githubusercontent.com/ansible/ansible/stable-2.9/contrib/inventory/openstack_inventory.py
chmod +x openstack_inventory.py

Инициализируйте файл RC OpenStack:

source openstack.rc

Вы можете подтвердить, что файл успешно инициализирован, выполнив простую команду, например, nova list, и убедившись, что она не возвращает ошибок.

Вы можете протестировать скрипт динамической инвентаризации OpenStack вручную, чтобы убедиться, что он работает как ожидается:

./openstack_inventory.py --list

Через некоторое время вы должны увидеть вывод в формате JSON с информацией о ваших вычислительных экземплярах.

После подтверждения корректной работы скрипта динамической инвентаризации вы можете указать Ansible использовать скрипт openstack_inventory.py в качестве файла инвентаризации, как показано ниже:

ansible -i openstack_inventory.py all -m ping

Неявное использование скрипта OpenStack inventory

Загрузите последнюю версию скрипта динамической инвентаризации OpenStack, сделайте его исполняемым и скопируйте его в /etc/ansible/hosts:

wget https://raw.githubusercontent.com/ansible/ansible/stable-2.9/contrib/inventory/openstack_inventory.py
chmod +x openstack_inventory.py
sudo cp openstack_inventory.py /etc/ansible/hosts

Загрузите файл конфигурации, измените его в соответствии с вашими потребностями и скопируйте его в /etc/ansible/openstack.yml:

wget https://raw.githubusercontent.com/ansible/ansible/stable-2.9/contrib/inventory/openstack.yml
vi openstack.yml
sudo cp openstack.yml /etc/ansible/

Вы можете протестировать скрипт динамической инвентаризации OpenStack вручную, чтобы убедиться, что он работает как ожидается:

/etc/ansible/hosts --list

Через некоторое время вы должны увидеть вывод в формате JSON с информацией о ваших вычислительных экземплярах.

Обновление кэша

Обратите внимание, что скрипт динамической инвентаризации OpenStack кэширует результаты, чтобы избежать повторных вызовов API. Чтобы явно очистить кэш, вы можете запустить скрипт openstack_inventory.py (или hosts) с параметром --refresh:

./openstack_inventory.py --refresh --list

Другие скрипты инвентаризации

Все включенные скрипты инвентаризации можно найти в каталоге contrib/inventory. Общее использование аналогично для всех скриптов инвентаризации. Вы также можете написать свой собственный скрипт инвентаризации.

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

Если местоположение, указанное для -i в Ansible, является каталогом (или как настроено в ansible.cfg), Ansible может использовать несколько источников инвентаризации одновременно. При этом можно смешивать динамические и статически управляемые источники инвентаризации в одном запуске Ansible. Гибридное облако мгновенно!

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

~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

Вы можете заменить этот список своим собственным, настроив список inventory_ignore_extensions в ansible.cfg или задав переменную среды ANSIBLE_INVENTORY_IGNORE. В обоих случаях значение должно быть списком шаблонов, разделённым запятыми, как показано выше.

Любые подкаталоги group_vars и host_vars в каталоге инвентаризации будут интерпретироваться как ожидается, что делает каталоги инвентаризации мощным способом организации различных наборов конфигураций. Дополнительную информацию см. в разделе Использование нескольких источников инвентаризации.

Статические группы динамических групп

При определении групп групп в статическом файле инвентаризации дочерние группы также должны быть определены в статическом файле инвентаризации, иначе Ansible вернёт ошибку. Если вы хотите определить статическую группу динамических дочерних групп, определите динамические группы как пустые в статическом файле инвентаризации. Например:

[tag_Name_staging_foo]

[tag_Name_staging_bar]

[staging:children]
tag_Name_staging_foo
tag_Name_staging_bar