Использование инвентори-плагинов из Ansible Content Collections в Ansible Tower

ИТ-среды становятся все сложнее и сложнее. В этих условиях для системы ИТ-автоматизации критически важно иметь актуальную информацию обо узлах, которые присутствуют в сети и подлежат обработке. В Red Hat Ansible Automation Platform этот вопрос решается через так называемые инвентори (inventory) – списки управляемых узлов.

В своей простейшей форме инвентори представляет собой статический файл. Это идеальный вариант, когда вы начинаете работать с Ansible, но по мере расширения автоматизации, его становится недостаточно.

И вот почему:

1. Как обновлять и поддерживать в актуальном состоянии полный список контролируемых узлов, когда что-то постоянно меняется, когда рабочие нагрузки – а вслед за ними и узлы, на которых они выполняются – то возникают, то исчезают?
2. Как классифицировать компоненты ИТ-инфраструктуры, чтобы прицельно выбирать узлы для применения той или иной автоматизации?

Ответы на оба эти вопроса дает динамический инвентори (dynamic inventory) – скрипт или плагин, который ищет подлежащие автоматизации узлы, обращаясь к источнику истины (source of truth). Кроме того, динамический инвентори автоматически классифицирует узлы по группам, чтобы вы могли точнее отбирать целевые системы для выполнения той или иной автоматизации Ansible.

Инвентори-плагины дают пользователю Ansible возможность обращаться к внешним платформам для динамического поиска целевых узлов и использовать эти платформы в качестве источника истины при формировании инвентори. Стандартный список источников в Ansible включает облачные платформы AWS EC2, Google GCP и Microsoft Azure, также для Ansible есть и множество других инвентори-плагинов.

Ansible Tower поставляется вместе с рядом инвентори-плагинов, которые работают прямо «из коробки» и помимо выше перечисленных облачных платформ обеспечивают интеграцию с VMware vCenter, Red Hat OpenStack Platform и Red Hat Satellite. Для этих плагинов достаточно предоставить учетные данные для подключения к целевой платформе, после чего их можно использовать как источник инвентори-данных в Ansible Tower.

Помимо штатных плагинов из комплекта поставки Ansible Tower есть и другие инвентори-плагины, поддерживаемые силами сообщества Ansible. С переходом на Red Hat Ansible Content Collections эти плагины стали включаться в соответствующие коллекции.

В этом посте мы для примера разберем работу с инвентори-плагином для ServiceNow, популярной платформы управления ИТ-сервисами, в CMDB которой заказчики часто хранят сведения обо всех своих устройствах. Кроме того, CMDB может содержать полезный для автоматизации контекст, например, сведения о владельцах серверов, уровнях обслуживания (production/non-production), установленных обновлениях и окнах технического обслуживания. Инвентори-плагин Ansible умеет работать с CMDB ServiceNow и входит в состав коллекции servicenow на портале galaxy.ansible.com.

Git-репозиторий

Чтобы использовать в Ansible Tower инвентори-плагин из коллекции, его надо задать в качестве источника проекта. В Ansible Tower проект – это интеграция с какой-то системой управления версиями, вроде репозитория git, которую можно использовать для синхронизации не только плейбуков автоматизации, но и переменных, а также списков инвентори.

Наш репозиторий на самом деле очень простой:

├── collections
│   └── requirements.yml
└── servicenow.yml

Файл servicenow.yml содержит подробности для инвентори плагина. В нашем случае мы просто указываем таблицу в CMDB ServiceNow, которую хотим использовать. А также задаем поля, которые будут добавляться в качестве переменных узла, плюс определенную информации по группам, которые хотим создать.

$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
  - key: sn_sys_class_name | lower
	prefix: ''
	separator: ''
  - key: sn_os | lower
	prefix: ''
	separator: ''

Обратите внимание, что здесь никак не конкретизируется инстанс ServiceNow, к которому мы будем подключаться, и не задаются никакие учетные данные для подлкючения. Все это мы позднее настроим в Ansible Tower.

Файл collections/requirements.yml нужен для того, чтобы Ansible Tower мог скачать нужную коллекцию и получить тем самым нужный инвентори-плагин. Иначе пришлось бы вручную устанавливать и поддерживать эту коллекцию на всех наших узлах Ansible Tower.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

После того, как мы отправили эту конфигурацию в систему контроля версий, в Ansible Tower можно создавать проект, ссылающийся на соответствующий репозиторий. В примере ниже Ansible Tower увязывается с нашим репозиторием на github. Обратите внимание на SCM URL: он позволяет прописать учетную запись для подключения к частному репозиторию, а также задать конкретную ветвь, метку или коммит для извлечения.

Создаем credentials для ServiceNow

Как уже говорилось, конфигурация в нашем репозитории не содержит учетных данных для подключения к ServiceNow и не конкретизирует инстанс ServiceNow, с которым мы будем общаться. Поэтому для задания этих данных мы создадим credentials в Ansible Tower. Согласно документации инвентори-плагина ServiceNow, существует ряд переменных окружения, с помощью которых мы и зададим параметры подключения, например, так:

= username
    	The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE

    	set_via:
      	env:
      	- name: SN_USERNAME

В этом случае, если переменная окружения SN_USERNAME задана, то инвентори-плагин будет использовать ее как учетную запись для подключения к ServiceNow.

Еще нам надо задать переменные SN_INSTANCE и SN_PASSWORD.

Однако в Ansible Tower нет credentials такого типа, где можно было бы указать эти данные для ServiceNow. Зато Ansible Tower позволяет нам определять настраиваемые типы credentials, подробнее об этом можно почитать в статье «Ansible Tower Feature Spotlight: Custom Credentials».

В нашем случае input-конфигурация для настраиваемых credentials для ServiceNow выглядит следующим образом:

fields:
  - id: SN_USERNAME
	type: string
	label: Username
  - id: SN_PASSWORD
	type: string
	label: Password
	secret: true
  - id: SN_INSTANCE
	type: string
	label: Snow Instance
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

Эти credentials будут экспонироваться как переменные окружения с тем же именем. Это описывается в конфигурации injector-а:

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

Итак, мы определили нужный нам тип credential, теперь можно добавить учетную запись ServiceNow и задать инстанс, имя пользователя и пароль, вот так:

Создаем инвентори

Итак, теперь у нас все готово, чтобы создать инвентори в Ansible Tower. Назовем его ServiceNow:

После создания инвентори мы можем прикрепить к ней источник данных. Здесь мы указываем проект, который создали ранее, и вводим путь к нашему инвентори-файлу YAML в репозитории системы управления версиями, в нашем случае это servicenow.yml в корне проекта. Кроме того, надо привязать и учетную запись ServiceNow.

Чтобы проверить, как все работает, попробуем синхронизироваться с источником данных, нажав кнопку «Sync all». Если все настроено правильно, то узлы должны импортироваться в наш инвентори:

Обратите внимание, что необходимые нам группы тоже создались.

Заключение

В этом посте мы рассмотрели, как в Ansible Tower использовать инвентори-плагины из коллекций на примере плагина ServiceNow. Мы также безопасно прописали учетные данные для подключения к нашему инстансу ServiceNow. Привязка инвентори-плагина из проекта работает не только со сторонними или настраиваемыми плагинами, но и вполне может применяться для модификации работы некоторых штатных инвентори. Благодаря этому Ansible Automation Platform легко и бесшовно интегрируется с существующими инструментами при автоматизации ИТ-сред, которые становятся все сложнее и сложнее.

Найти дополнительные сведения по рассмотренным в этом посте темам, а также по другим аспектам применения Ansible можно здесь:

• Блог по автоматизации ServiceNow с использованием Ansible.
• Как создавать свои собственные коллекции.
• Список поддерживаемых Red Hat коллекций на сайте Automation Hub (cloud.redhat.com).
• Электронные книги по Ansible Automation Platform.

*Red Hat не дает никаких гарантий корректности приведенного здесь кода. Все материалы предоставляются на условиях отсутствия поддержки, если только иное на заявлено в явном виде.

Источник: habr.com