- Регистрация
- 21.07.20
- Сообщения
- 40.408
- Реакции
- 1
- Репутация
- 0
ИТ-среды становятся все сложнее и сложнее. В этих условиях для системы ИТ-автоматизации критически важно иметь актуальную информацию обо узлах, которые присутствуют в сети и подлежат обработке. В Red Hat Ansible Automation Platform этот вопрос решается через так называемые инвентори (
В своей простейшей форме инвентори представляет собой статический файл. Это идеальный вариант, когда вы начинаете работать с Ansible, но по мере расширения автоматизации, его становится недостаточно.
И вот почему:
Ответы на оба эти вопроса дает динамический инвентори (
Ansible Tower поставляется вместе с рядом
Помимо штатных плагинов из комплекта поставки Ansible Tower есть и другие инвентори-плагины, поддерживаемые силами сообщества Ansible. С переходом на
В этом посте мы для примера разберем работу с инвентори-плагином для ServiceNow, популярной платформы управления ИТ-сервисами, в CMDB которой заказчики часто хранят сведения обо всех своих устройствах. Кроме того, CMDB может содержать полезный для автоматизации контекст, например, сведения о владельцах серверов, уровнях обслуживания (production/non-production), установленных обновлениях и окнах технического обслуживания. Инвентори-плагин Ansible умеет работать с CMDB ServiceNow и входит в состав коллекции
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.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
После того, как мы отправили эту конфигурацию в систему контроля версий, в Ansible Tower можно создавать проект, ссылающийся на соответствующий репозиторий. В примере ниже Ansible Tower увязывается с нашим репозиторием на github. Обратите внимание на SCM URL: он позволяет прописать учетную запись для подключения к частному репозиторию, а также задать конкретную ветвь, метку или коммит для извлечения.
Создаем credentials для ServiceNow
Как уже говорилось, конфигурация в нашем репозитории не содержит учетных данных для подключения к ServiceNow и не конкретизирует инстанс ServiceNow, с которым мы будем общаться. Поэтому для задания этих данных мы создадим credentials в Ansible Tower. Согласно
= 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 позволяет нам определять
В нашем случае 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 можно здесь:
*Red Hat не дает никаких гарантий корректности приведенного здесь кода. Все материалы предоставляются на условиях отсутствия поддержки, если только иное на заявлено в явном виде.
You must be registered for see links
) – списки управляемых узлов.В своей простейшей форме инвентори представляет собой статический файл. Это идеальный вариант, когда вы начинаете работать с Ansible, но по мере расширения автоматизации, его становится недостаточно.
И вот почему:
- Как обновлять и поддерживать в актуальном состоянии полный список контролируемых узлов, когда что-то постоянно меняется, когда рабочие нагрузки – а вслед за ними и узлы, на которых они выполняются – то возникают, то исчезают?
- Как классифицировать компоненты ИТ-инфраструктуры, чтобы прицельно выбирать узлы для применения той или иной автоматизации?
Ответы на оба эти вопроса дает динамический инвентори (
You must be registered for see links
) – скрипт или плагин, который ищет подлежащие автоматизации узлы, обращаясь к источнику истины (source of truth). Кроме того, динамический инвентори автоматически классифицирует узлы по группам, чтобы вы могли точнее отбирать целевые системы для выполнения той или иной автоматизации Ansible.
You must be registered for see links
дают пользователю Ansible возможность обращаться к внешним платформам для динамического поиска целевых узлов и использовать эти платформы в качестве источника истины при формировании инвентори. Стандартный список источников в Ansible включает облачные платформы AWS EC2, Google GCP и Microsoft Azure, также для Ansible есть и множество других инвентори-плагинов.Ansible Tower поставляется вместе с рядом
You must be registered for see links
, которые работают прямо «из коробки» и помимо выше перечисленных облачных платформ обеспечивают интеграцию с VMware vCenter, Red Hat OpenStack Platform и Red Hat Satellite. Для этих плагинов достаточно предоставить учетные данные для подключения к целевой платформе, после чего их можно использовать как источник инвентори-данных в Ansible Tower.Помимо штатных плагинов из комплекта поставки Ansible Tower есть и другие инвентори-плагины, поддерживаемые силами сообщества Ansible. С переходом на
You must be registered for see links
эти плагины стали включаться в соответствующие коллекции.В этом посте мы для примера разберем работу с инвентори-плагином для ServiceNow, популярной платформы управления ИТ-сервисами, в CMDB которой заказчики часто хранят сведения обо всех своих устройствах. Кроме того, CMDB может содержать полезный для автоматизации контекст, например, сведения о владельцах серверов, уровнях обслуживания (production/non-production), установленных обновлениях и окнах технического обслуживания. Инвентори-плагин Ansible умеет работать с CMDB ServiceNow и входит в состав коллекции
You must be registered for see links
на портале
You must be registered for see links
.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.
You must be registered for see links
нужен для того, чтобы 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. Согласно
You must be registered for see links
, существует ряд переменных окружения, с помощью которых мы и зададим параметры подключения, например, так:= 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 позволяет нам определять
You must be registered for see links
, подробнее об этом можно почитать в статье
You must be registered for see links
.В нашем случае 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 можно здесь:
- Блог по
You must be registered for see links.
-
You must be registered for see links.
- Список поддерживаемых Red Hat коллекций на сайте Automation Hub (
You must be registered for see links).
-
You must be registered for see links.
*Red Hat не дает никаких гарантий корректности приведенного здесь кода. Все материалы предоставляются на условиях отсутствия поддержки, если только иное на заявлено в явном виде.