ИТ-среды становятся все сложнее и сложнее. В этих условиях для системы ИТ-автоматизации критически важно иметь актуальную информацию обо узлах, которые присутствуют в сети и подлежат обработке. В Red Hat Ansible Automation Platform этот вопрос решается через так называемые инвентори (inventory) – списки управляемых узлов.
В своей простейшей форме инвентори представляет собой статический файл. Это идеальный вариант, когда вы начинаете работать с Ansible, но по мере расширения автоматизации, его становится недостаточно.
И вот почему:
Ответы на оба эти вопроса дает динамический инвентори (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.
Чтобы использовать в Ansible Tower инвентори-плагин из коллекции, его надо задать в качестве источника проекта. В Ansible Tower проект – это интеграция с какой-то системой управления версиями, вроде репозитория git, которую можно использовать для синхронизации не только плейбуков автоматизации, но и переменных, а также списков инвентори.
Наш репозиторий на самом деле очень простой:
Файл servicenow.yml содержит подробности для инвентори плагина. В нашем случае мы просто указываем таблицу в CMDB ServiceNow, которую хотим использовать. А также задаем поля, которые будут добавляться в качестве переменных узла, плюс определенную информации по группам, которые хотим создать.
Обратите внимание, что здесь никак не конкретизируется инстанс ServiceNow, к которому мы будем подключаться, и не задаются никакие учетные данные для подлкючения. Все это мы позднее настроим в Ansible Tower.
Файл collections/requirements.yml нужен для того, чтобы Ansible Tower мог скачать нужную коллекцию и получить тем самым нужный инвентори-плагин. Иначе пришлось бы вручную устанавливать и поддерживать эту коллекцию на всех наших узлах Ansible Tower.
После того, как мы отправили эту конфигурацию в систему контроля версий, в Ansible Tower можно создавать проект, ссылающийся на соответствующий репозиторий. В примере ниже Ansible Tower увязывается с нашим репозиторием на github. Обратите внимание на SCM URL: он позволяет прописать учетную запись для подключения к частному репозиторию, а также задать конкретную ветвь, метку или коммит для извлечения.
Как уже говорилось, конфигурация в нашем репозитории не содержит учетных данных для подключения к ServiceNow и не конкретизирует инстанс ServiceNow, с которым мы будем общаться. Поэтому для задания этих данных мы создадим credentials в Ansible Tower. Согласно документации инвентори-плагина ServiceNow, существует ряд переменных окружения, с помощью которых мы и зададим параметры подключения, например, так:
В этом случае, если переменная окружения SN_USERNAME задана, то инвентори-плагин будет использовать ее как учетную запись для подключения к ServiceNow.
Еще нам надо задать переменные SN_INSTANCE и SN_PASSWORD.
Однако в Ansible Tower нет credentials такого типа, где можно было бы указать эти данные для ServiceNow. Зато Ansible Tower позволяет нам определять настраиваемые типы credentials, подробнее об этом можно почитать в статье «Ansible Tower Feature Spotlight: Custom Credentials».
В нашем случае input-конфигурация для настраиваемых credentials для ServiceNow выглядит следующим образом:
Эти credentials будут экспонироваться как переменные окружения с тем же именем. Это описывается в конфигурации injector-а:
Итак, мы определили нужный нам тип credential, теперь можно добавить учетную запись ServiceNow и задать инстанс, имя пользователя и пароль, вот так:
Итак, теперь у нас все готово, чтобы создать инвентори в Ansible Tower. Назовем его ServiceNow:
После создания инвентори мы можем прикрепить к ней источник данных. Здесь мы указываем проект, который создали ранее, и вводим путь к нашему инвентори-файлу YAML в репозитории системы управления версиями, в нашем случае это servicenow.yml в корне проекта. Кроме того, надо привязать и учетную запись ServiceNow.
Чтобы проверить, как все работает, попробуем синхронизироваться с источником данных, нажав кнопку «Sync all». Если все настроено правильно, то узлы должны импортироваться в наш инвентори:
Обратите внимание, что необходимые нам группы тоже создались.
В этом посте мы рассмотрели, как в Ansible Tower использовать инвентори-плагины из коллекций на примере плагина ServiceNow. Мы также безопасно прописали учетные данные для подключения к нашему инстансу ServiceNow. Привязка инвентори-плагина из проекта работает не только со сторонними или настраиваемыми плагинами, но и вполне может применяться для модификации работы некоторых штатных инвентори. Благодаря этому Ansible Automation Platform легко и бесшовно интегрируется с существующими инструментами при автоматизации ИТ-сред, которые становятся все сложнее и сложнее.
Найти дополнительные сведения по рассмотренным в этом посте темам, а также по другим аспектам применения Ansible можно здесь:
*Red Hat не дает никаких гарантий корректности приведенного здесь кода. Все материалы предоставляются на условиях отсутствия поддержки, если только иное на заявлено в явном виде.
В своей простейшей форме инвентори представляет собой статический файл. Это идеальный вариант, когда вы начинаете работать с Ansible, но по мере расширения автоматизации, его становится недостаточно.
И вот почему:
- Как обновлять и поддерживать в актуальном состоянии полный список контролируемых узлов, когда что-то постоянно меняется, когда рабочие нагрузки – а вслед за ними и узлы, на которых они выполняются – то возникают, то исчезают?
- Как классифицировать компоненты ИТ-инфраструктуры, чтобы прицельно выбирать узлы для применения той или иной автоматизации?
Ответы на оба эти вопроса дает динамический инвентори (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 не дает никаких гарантий корректности приведенного здесь кода. Все материалы предоставляются на условиях отсутствия поддержки, если только иное на заявлено в явном виде.
