Динамичный инвентаризация

• Пример: Скрипт внешнего инвентаризации 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) это приведет к записи следующих данных в /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 в кэше индекса, получить ID экземпляра, а затем выполнить вызов 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.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

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

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