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

• Пример: Сценарий внешнего инвентаризации 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).

Хотя Cobbler в основном используется для запуска установок ОС и управления DHCP и DNS, он имеет общий слой, который позволяет ему представлять данные для нескольких систем управления конфигурацией (даже одновременно), и некоторые администраторы называют его «лёгкой 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) в результате данные будут записаны в /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 предоставляет сопоставления экземпляров из нескольких групп:

Глобальная

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

Теги

Каждый экземпляр может иметь различные пары «ключ-значение», называемые тегами. Наиболее распространённый ключ тега — «Имя», хотя возможны любые значения. Каждая пара «ключ-значение» является собственной группой экземпляров, в которой специальные символы преобразуются в нижнее подчеркивание, в формате 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, чтобы получить информацию об этом конкретном экземпляре. Затем информация об этом экземпляре становится доступной в виде переменных для ваших playbook'ов. Каждая переменная имеет префикс 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.py для извлечения информации о ваших вычислительных экземплярах непосредственно из OpenStack.

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

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

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

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

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

Загрузите файл OpenStack RC:

source openstack.rc

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

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

./openstack.py --list

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

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

ansible -i openstack.py all -m ping

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

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

wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/openstack.py
chmod +x openstack.py
sudo cp openstack.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.py (или hosts) с параметром --refresh:

./openstack.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