Ansible используют почти все, и мы не исключение. В отделе сетевой инфраструктуры мы с его помощью автоматизируем доставку конфигураций на коммутаторы и маршрутизаторы. Наша сеть постоянно расширяется, внедряются новые фичи, которые тянут за собой новые плейбуки и роли, но одно всегда оставалось неизменным — список хостов мы держали в ini-файле. И когда количество хостов стало исчисляться сотнями, пришло понимание, что вручную контролировать inventory в файле не очень-то и удобно.
«Постойте» - подумали мы - «у нас же есть актуальный список всех сетевых устройств в Nautobot, и в нашей сети именно он является источником истины. Надо всего лишь подружить Ansible и Nautobot». Что ж, давайте посмотрим, как умеют договариваться эти двое.
![](https://habrastorage.org/getpro/habr/upload_files/ec6/fd9/1e6/ec6fd91e6e820151444ce4bc3cdc9b10.jpg)
Но сначала о том, как был устроен наш файл 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 мог бы выглядеть так:
nautobot2ansible_v1.py
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 появляется дополнительное условие.
nautobot2ansible_v2.py
#! /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, это делается простым добавлением нужного декоратора.
models.py
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 в шаблон. Именно в ней составляется список устройств в соответствии с параметрами фильтра:
views.py
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-запрос с последующей генераций списка хостов.
Вот так пользователь видит группу и список хостов:
![](https://habrastorage.org/getpro/habr/upload_files/b82/a08/0db/b82a080dba088f0b09becaa4dde2bdc7.png)
А чтобы при создании новой или редактировании существующей группы пользователи сразу видели возможности плагина, на экран выводится справка по фильтру:
![](https://habrastorage.org/getpro/habr/upload_files/128/089/ac4/128089ac42652f40573c926c9744afcc.png)
Приводить код скрипта динамического inventory, работающего на стороне Ansible, смысла уже не вижу, для его создания мы просто соединили принципы из второго вариант и логику из View созданного плагина. Такой вариант связки Nautobot + Ansible оказался самым удобным в использовании. Интерфейс плагина наглядный, максимально простой, и в то же время позволяет реализовать любые комбинации условий для создания новых групп.
О том, как писать плагины для Nautobot можно почитать на Хабре и в официальной документации.
Ну и, конечно же, не могу не упомянуть моего друга и бывшего коллегу Николая Никифорова, который внес неоценимый вклад в разработку описанного решения.