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

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

Часто пользователю системы управления конфигурацией требуется хранить инвентарь в другой программной системе. Ansible предоставляет простую текстовую систему, как описано в Работа с инвентарём, но что если вам нужно использовать что-то другое?

Частые примеры включают извлечение инвентаря из поставщика облачных услуг, LDAP, Cobbler или дорогостоящего программного обеспечения CMDB.

Ansible легко поддерживает все эти варианты с помощью внешней системы инвентаризации. Каталог contrib/inventory содержит некоторые из них — включая варианты для EC2/Eucalyptus, Rackspace Cloud и OpenStack, примеры некоторых из которых будут описаны ниже.

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

Дополнительную информацию о написании собственного источника динамического инвентаризации можно найти в Разработка источников динамического инвентаризации.

Пример: Сценарий внешнего инвентаризации Cobbler

Ожидается, что многие пользователи Ansible с достаточным количеством физического оборудования также являются пользователями Cobbler. (Примечание: Cobbler изначально был написан Майклом ДеХааном и сейчас возглавляется Джеймсом Каммаратой, который также работает в Ansible, Inc).

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

Для связи инвентаризации Ansible с Cobbler (необязательно), скопируйте этот сценарий в /etc/ansible и chmod +x файл. Теперь cobblerd должен работать при использовании Ansible, и вам потребуется использовать параметр командной строки 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), в результате для системы «foo» будут записаны следующие данные в /etc/motd:

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

Глобальный

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

ID экземпляра

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

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

Загрузите файл конфигурации OpenStack RC:

source openstack.rc

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

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

./openstack_inventory.py --list

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

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

ansible -i openstack_inventory.py all -m ping

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

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

wget https://raw.githubusercontent.com/ansible/ansible/devel/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/devel/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

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

Помимо Cobbler и EC2, скрипты инвентаризации также доступны для:

BSD Jails
DigitalOcean
Google Compute Engine
Linode
OpenShift
OpenStack Nova
Ovirt
SpaceWalk
Vagrant (not to be confused with the provisioner in vagrant, which is preferred)
Zabbix

Разделы о том, как использовать их более подробно, будут добавлены со временем, но, посмотрев в каталог «contrib/inventory» в репозитории Ansible, вы легко поймёте, как их использовать. Процесс для скрипта инвентаризации AWS такой же.

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

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

Если Ansible получает указанный в -i путь к каталогу (или так настроено в 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