Ansible + SoT или Ещё раз про динамический inventory

Ansible используют почти все, и мы не исключение. В отделе сетевой инфраструктуры мы с его помощью автоматизируем доставку конфигураций на коммутаторы и маршрутизаторы. Наша сеть постоянно расширяется, внедряются новые фичи, которые тянут за собой новые плейбуки и роли, но одно всегда оставалось неизменным — список хостов мы держали в ini-файле. И когда количество хостов стало исчисляться сотнями, пришло понимание, что вручную контролировать inventory в файле не очень-то и удобно.

«Постойте» — подумали мы — «у нас же есть актуальный список всех сетевых устройств в Nautobot, и в нашей сети именно он является источником истины. Надо всего лишь подружить Ansible и Nautobot». Что ж, давайте посмотрим, как умеют договариваться эти двое.

Но сначала о том, как был устроен наш файл inventory. Все хосты в нём разбиты на вложенные друг в друга группы: по роли (роутер, коммутатор), по производителю, по типу локации (центральный офис, магазины, склады), по назначению (основной роутер, резервный, тестовый). Выглядел inventory примерно так:

# все роутеры Cisco [all-cr:children] dc-cr hq-cr branch-cr-r0 branch-cr-r1 test-cr  # роутеры Cisco в ЦОД [dc-cr] DC_R0 DC_R1  # роутеры Cisco в центральном офисе [hq-cr] HQ_R0 HQ_R1  # основные роутеры Cisco в филиалах [branch-cr-r0:children] st-cr-r0 wh-cr-r0  # резервные роутеры Cisco в филиалах [branch-cr-r1:children] st-cr-r1 wh-cr-r1  # основные роутеры Cisco в магазинах [st-cr-r0] 111_R0 112_R0  # основные роутеры Cisco на складах [wh-cr-r0] 1119_R0 1129_R0  # output omitted 

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

Для тех, кто ещё не слышал про Nautobot, скажем пару слов о нём и его месте в нашей инфраструктуре:

• это форк Netbox,

• мы про него уже писали,

• в нём описаны все наши сетевые устройства, с интерфейсами и адресами, эта информация актуальна;

• также мы учитываем в Nautobot серверы и виртуальные машины;

• все устройства и серверы привязаны к локациям;

• если разрезов учёта «из коробки» не хватает, мы используем custom fields или пишем плагины;

• у Nautobot есть очень хорошо описанный API;

• в Nautobot есть вся нужная информация для inventory.

Какие же есть способы решения возникшей задачи? Первое, что приходит в голову — скрипт, который запросит данные из Nautobot и подготовит файл с хостами по заданному алгоритму.

Вариант № 1: простая синхронизация по расписанию

API у Nautobot вполне достаточно, выбираем любимый язык программирования и добавляем написанный скрипт в cron. Алгоритм простой: обращаемся к API по HTTP(s), дёргаем список устройств по заданным параметрам и  пишем в файл. Нам нужно получить от Nautobot сведения, которые позволят распределить хосты по нужным группам. Для сохранения преемственности данные в файл будем писать в формате INI, хотя, на мой взгляд, YAML был бы попроще.

Примерный код скрипта на Python мог бы выглядеть так:

import os, requests  url = os.getenv('NAUTOBOT_GRAPHQL_URL') headers = {     "Content-Type": "application/json",     "Accept-Encoding": "gzip",     "Authorization": f"Token {os.getenv('NAUTOBOT_TOKEN')}", }  query = """ {   devices(     status: ["active"],     manufacturer: "Cisco",     has_primary_ip: true   ){     name     primary_ip4 { address }     device_role { slug }     site {         slug         cf_format     }     tags { slug }   } } """  response = requests.post(url, headers=headers, json={"query": query}) if response.status_code == 200:     inventory = configparser.ConfigParser(allow_no_value=True)     for device in response.json()["data"]["devices"]:         device_name = device["name"]         device_ip = device["primary_ip4"]["address"].split("/")[0]          # соберем секцию исходя из какой-то нашей логики         # первая часть зависит от формата филиала, данные хранятся в custom field 'format'         section_part_1 = {             "store": "st",             "warehouse": "wh"         }.get(device["site"]["cf_format"], "other")         # вторая часть зависит от роли устройства         section_part_2 = {             "router": "cr",             "access_switch": "cs",         }.get(device["device_role"]["slug"], "cd")         # третья часть зависит от тега, навешенного на устройство         tags = [tag["slug"] for tag in device["tags"]]         if "primary_router" in tags:             section_part_3 = "r0"         elif "secondary_router" in tags:             section_part_3 = "r1"         else:             section_part_3 = "rx"         if device["device_role"]["slug"] == "router":             section = f"{section_part_1}-{section_part_2}-{section_part_3}"         else:             section = f"{section_part_1}-{section_part_2}"          if not inventory.has_section(section):             inventory.add_section(section)         inventory.set(section, f"{device_name} ansible_host={device_ip}")      with open("cisco_hosts", 'w') as inventory_file:         inventory.write(inventory_file)

В коде используется обращение не к привычному всем нам REST API, а к более современному GraphQL. Подробнее про работу с GraphQL в Nautobot можно почитать тут. Почему GraphQL? Он быстрее, проще, и отдаёт только нужные данные.

Преимущества такого решения: относительная простота реализации и, пожалуй, на этом всё.

Недостатки:

• Данные актуальны только на момент выполнения скрипта, изменения в период между синхронизацией inventory и запуском плейбука учитываться не будут.

• Набор групп статичен и захардкожен в скрипте.

Итак, начинаем избавляться от недостатков. Первым делом надо придумать, как актуализировать список хостов на момент запуска плейбуков.

Вариант № 2: Dynamic inventory (свой)

Если вы посмотрите ansible.cfg, то наверняка найдёте в нём примерно такие строки:

[inventory]
# enable inventory plugins, default: ‘host_list’, ‘script’, ‘auto’, ‘yaml’, ‘ini’, ‘toml’

Параметр script означает, что «из коробки» Ansible позволяет в качестве источника списка хостов применять не только привычные нам YAML или INI, а любые исполняемые скрипты. Достаточно положить скрипт в нужную папку, указать правильный шебанг и дать права на исполнение. Подробнее можно почитать в оригинале.

Код получается почти такой же, как в первом варианте. Основные отличия: 

• Скрипт в зависимости от входных аргументов выводит или список хостов (—list), или данные одного хоста (—host {hostname}).

• Скрипт не изменяет файл, а возвращает JSON.

• Если требуются данные только одного хоста, то в запросе к Nautobot появляется дополнительное условие.

#! /usr/bin/python3  import requests import argparse import json import os, sys  parser = argparse.ArgumentParser() parser.add_argument(     "--list",     action='store_true' ) parser.add_argument(     "--host",     action='store', ) args = parser.parse_args()  inventory = {     "_meta": {         "hostvars": {}     } }  # Выводим пустые vars и выходим if not args.list and not args.host:     print(json.dumps(inventory, indent=4))     sys.exit(0)   url = os.getenv('NAUTOBOT_GRAPHQL_URL') headers = {     "Content-Type": "application/json",     "Accept-Encoding": "gzip",     "Authorization": f"Token {os.getenv('NAUTOBOT_TOKEN')}", }  if args.host:     limit_device = f'name: "{args.host}",' else:     limit_device = "" query = """ {   devices(%s status: ["active"], manufacturer:"Cisco", has_primary_ip:true) {     name     primary_ip4 { address }     device_role { slug }     site {         slug         cf_format     }     tags { slug }   } } """ % (limit_device)  response = requests.post(url, headers=headers, json={"query": query}, verify=False) if response.status_code == 200:     for device in response.json()["data"]["devices"]:         device_name = device["name"]         device_ip = device["primary_ip4"]["address"].split("/")[0]         # соберем секцию исходя из какой-то нашей логики         # первая часть зависит от формата филиала, данные хранятся в custom field 'format'         section_part_1 = {             "store": "st",             "warehouse": "wh"         }.get(device["site"]["cf_format"], "other")         # вторая часть зависит от роли устройства         section_part_2 = {             "router": "cr",             "access_switch": "cs",         }.get(device["device_role"]["slug"], "cd")         # третья часть зависит от тега, навешенного на устройство         tags = [tag["slug"] for tag in device["tags"]]         if "primary_router" in tags:             section_part_3 = "r0"         elif "secondary_router" in tags:             section_part_3 = "r1"         else:             section_part_3 = "rx"          if device["device_role"]["slug"] == "router":             section = f"{section_part_1}-{section_part_2}-{section_part_3}"         else:             section = f"{section_part_1}-{section_part_2}"         if section not in inventory:             inventory[section] = {                 "hosts": []             }          inventory[section]["hosts"].append(device_name)         inventory["_meta"]["hostvars"][device_name] = {             "ansible_host": device_ip         }  # Выводим hosts и vars if args.list:     print(json.dumps(inventory, indent=4))  # Выводим vars конкретного хоста elif args.host:     host_vars = {         "_meta": {             "hostvars": inventory["_meta"]["hostvars"][args.host]         }     }     print(json.dumps(host_vars, indent=4))

Такое решение позволяет нам получать нужные группы и актуальный список хостов в момент выполнения плейбука. Это уже самый настоящий динамический inventory, создаваемый на лету. Но всё ещё остаётся недостаток с фиксированным набором групп. Хотелось бы оперативно добавлять группы и регулировать их наполнение через интерфейс Nautobot. Так что двигаемся дальше и продолжаем генерировать идеи.

Вариант № 3 — Dynamic inventory (чужой)

Давайте посмотрим, что там в сообществе? Может, есть готовый велосипед, который нас устроит? И действительно, разработчики Nautobot позаботились о ленивых сетевых инженерах и в составе большой коллекции для Ansible galaxy предоставили плагин networktocode.nautobot.inventory. Никакой код писать не надо: установили плагин, заполнили согласно документации файл inventory, и получили актуальный список хостов, разбитый по группам. Причём группировать можно по широкому набору полей: по производителю, роли оборудования, локации, даже по тегам. Всё формируется на лету: добавили устройства нового производителя — сразу в списке хостов появляется группа с таким же названием.

Предположим, что мы создали следующий файл inventory.yml:

plugin: networktocode.nautobot.inventory api_endpoint: https://nautobot validate_certs: True config_context: False group_by:   - device_roles   - tags   - manufacturers   - sites query_filters:   - status: active   - role: router   - role: access_switch device_query_filters:   - has_primary_ip: 'true'

В результате мы получаем (вывод неполный, только несколько коммутаторов и маршрутизаторов для примера):

ansible-inventory --graph -i inventory.yml @all:   |--@device_roles_access_switch:   |  |--111_SW1   |  |--111_SW2   |  |--112_SW1   |  |--112_SW2   |--@device_roles_router:   |  |--111_R0   |  |--111_R1   |  |--112_R0   |  |--112_R1   |--@manufacturers_Cisco:   |  |--111_R0   |  |--111_R1   |  |--112_R0   |  |--112_R1   |  |--111_SW1   |  |--111_SW2   |  |--112_SW1   |  |--112_SW2   |--@sites_111:   |  |--111_R0   |  |--111_R1   |  |--111_SW1   |  |--111_SW2   |--@sites_112:   |  |--112_R0   |  |--112_R1   |  |--112_SW1   |  |--112_SW2   |--@tags_primary_router:   |  |--111_R0   |  |--112_R0   |--@tags_secondary_router:   |  |--111_R1   |  |--112_R1

Достоинства решения:

• Не простое, а очень простое внедрение.

• Возможность передавать в переменные хоста данные из Nautobot (custom fields, local context и т. д.).

• Разнообразные способы группировки хостов.

Ну и куда же без недостатков:

• Нельзя просто так взять и объединить группы.

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

Вариант № 4: Dynamic inventory (свой, удобный, красивый)

В итоге мы пришли к следующей концепции: 

В Nautobot создаётся список групп, которые содержат формализованные фильтры по устройствам и виртуальным машинам. Интерфейс должен позволять сразу увидеть список хостов, входящих в группу по заданным условиям. Скрипт динамического inventory получает по API список групп с условиями, и затем по каждому условию получает список хостов, который вносит в состав соответствующей группы. 

Например, сетевому инженеру нужна группа, в которую входят маршрутизаторы, удовлетворяющие следующим условиям:

• модель: Cisco 4300 series;

• тег: primary_router;

• локация: склады;

• статус: active.

Инженер добавляет в Nautobot группу с названием cr4300_wh_r0 и в её настройках указывает нужные фильтры. Можно посмотреть список устройств, попадающих в группу, и проконтролировать правильность фильтра. Этого достаточно, чтобы созданная группа появилась в Ansible inventory, нет необходимости править файлы inventory на сервере с Ansible. И, разумеется, концепция должна работать не только для сетевых устройств, но и для серверов, и для ВМ, которые учитываются в Nautobot.

Для реализации задуманного были написаны плагин для Nautobot и скрипт динамического inventory. Основные составляющие плагина:

• модель данных;

• View, отвечающий за формирование списка хостов по условию группы;

• шаблон HTML для удобного просмотра списка хостов по условию группы.

Модель данных предельно проста: в таблице храним имя группы, параметры фильтра в JSON и статус. Не забываем про возможность выдачи данных по GraphQL, это делается простым добавлением нужного декоратора.

from nautobot.core.models.generics import PrimaryModel from nautobot.extras.models import StatusModel from nautobot.extras.utils import extras_features  @extras_features(     "statuses",     "graphql", ) class AnsibleGroup(PrimaryModel, StatusModel):     name = models.CharField(max_length=20, unique=True, blank=False)     device_filters = models.JSONField(encoder=DjangoJSONEncoder)     description = models.CharField(max_length=150, blank=False, default="")

View полностью приводить не буду, класс стандартный, как для любого плагина, и отличается от всех остальных только наличием функции get_extra_context, которая отвечает за передачу дополнительного содержимого из View в шаблон. Именно в ней составляется список устройств в соответствии с параметрами фильтра:

def get_extra_context(self, request, instance):     # фильтры, которые можно использовать в запросе     DEVICE_PREFILTER_KEYS = {         "status": "status__slug__in",         "role": "device_role__slug__in",         "name": "name__in",         "manufacturer": "platform__manufacturer__slug__in",         "site": "site__slug__in",     }     VM_PREFILTER_KEYS = {         "status": "status__slug__in",         "role": "role__slug__in",         "name": "name__in",         "site": "cluster__site__slug__in",     }      # фильтры для ограничения уже полученного набора данных     DEVICE_POSTFILTER_KEYS =  ["model", "cf_format", "platform", "tag", "tag_any"]     VM_POSTFILTER_KEYS = ["cf_format", "platform", "tag", "tag_any"]      context = super().get_extra_context(request, instance)     if self.action == "retrieve":         dev_filters = instance.device_filters         # фильтр по умолчанию         device_kw_args = {             "status__slug__in": ["active"],         }         for key, filter_value in dev_filters.items():             if type(filter_value) is str:                 cur_filter = [filter_value]             else:                 cur_filter = filter_value             if key in DEVICE_PREFILTER_KEYS:                 device_kw_args.update({DEVICE_PREFILTER_KEYS[key]: cur_filter})          # получаем список устройств, ограниченный префильтрами         devices_raw = (             Device.objects.restrict(request.user, "view")             .filter(**device_kw_args)         )         devices = []         for device in devices_raw:             device_tags = device.tags.slugs()             for key in DEVICE_POSTFILTER_KEYS:                 cur_filter = dev_filters.get(key)                 if cur_filter:                     if type(cur_filter) is str:                         cur_filter = [cur_filter]                     if key == "model" and not any(filter_value.lower() in device.device_type.slug.lower() for filter_value in cur_filter):                         # ищем вхождение фильтра "model" в device_type.slug                         break                     elif key == "cf_format" and not any(filter_value.lower() == device.site.cf.get("Format", "Other").lower() for filter_value in cur_filter):                         # проверяем на соответствие формату сайта (custom field "format")                         break                     elif key == "platform" and not any(filter_value.lower() == device.platform.napalm_driver.lower() for filter_value in cur_filter):                         # проверяем на соответствие платформе (конкретную платформу храним в поле napalm_driver)                         break                     elif key == "tag" and not all(filter_value in device_tags for filter_value in cur_filter):                         # все теги должны совпадать с фильтром                         break                     elif key == "tag_any" and not any(filter_value in device_tags for filter_value in cur_filter):                         # хотя бы один тег должен совпадать с фильтром                         break             else:                 devices.append(device)          device_table = DeviceTable(devices)         # спрячем лишние столбцы         for column in ("tenant", "rack", "location"):             device_table.columns.hide(column)          paginate = {             "paginator_class": EnhancedPaginator,             "per_page": get_paginate_count(request),         }         RequestConfig(request, paginate).configure(device_table)         # передадим в шаблон полученную таблицу         context["device_table"] = device_table  # дальше идёт код для подготовки списка VirtualMachine, он аналогичен коду для Device      return context

Можно заметить, что поля в фильтре делятся на два типа:

• Первые участвуют в запросе к данным и применяются на стороне сервера БД.

• Значения вторых проверяются уже на полученных данных. 

Поля первого типа используются для подготовки запроса к таблице Device. Результаты запроса последовательно сверяются со значениями полей второго типа. Итоговый список хостов выводится пользователю в HTML-шаблоне. На стороне Ansible в динамическом inventory работает точно такой же алгоритм: скрипт запрашивает список групп в Nautobot и для каждой из них делает GraphQL-запрос с последующей генераций списка хостов.

Вот так пользователь видит группу и список хостов:

А чтобы при создании новой или редактировании существующей группы пользователи сразу видели возможности плагина, на экран выводится справка по фильтру:

Приводить код скрипта динамического inventory, работающего на стороне Ansible, смысла уже не вижу, для его создания мы просто соединили принципы из второго вариант и логику из View созданного плагина. Такой вариант связки Nautobot + Ansible оказался самым удобным в использовании. Интерфейс плагина наглядный, максимально простой, и в то же время позволяет реализовать любые комбинации условий для создания новых групп. 

О том, как писать плагины для Nautobot можно почитать на Хабре и в официальной документации.

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