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

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

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

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

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

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

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

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

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

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

Для привязки инвентаризации Ansible к Cobbler скопируйте этот скрипт в /etc/ansible и chmod +x файл. Запустите cobblerd всякий раз, когда вы используете Ansible и используйте опцию командной строки -i (например, -i /etc/ansible/cobbler.py) для связи с Cobbler через XMLRPC API 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

Теги

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