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

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

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

Ansible интегрирует все эти варианты через динамическую внешнюю систему инвентаризации. Ansible поддерживает два способа подключения к внешнему инвентарю: Плагины инвентаризации и inventory scripts <https://github.com/ansible/ansible/tree/stable-2.7/contrib/inventory>.

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

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

Если вы хотите графический интерфейс для работы с динамической инвентаризацией, база данных инвентаризации 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 autoscaling. По этой причине вы можете использовать скрипт внешней инвентаризации 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. Это позволяет получить ID экземпляра, найдя 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_inventory.py для прямого извлечения информации о ваших вычислительных экземплярах из OpenStack.

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

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

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

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

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

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

wget https://raw.githubusercontent.com/ansible/ansible/stable-2.7/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.7/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. Общее использование аналогично для всех сценариев инвентаризации. Также вы можете написать свой собственный сценарий инвентаризации.

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

Если заданный в 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