Использование инвентори-плагинов из 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 можно здесь:


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

    Комментарии 0

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

    Самое читаемое