Теперь, когда вы прочитали предыдущий раздел, вы должны догадаться, что NetDevOps — это просто подход DevOps, применяемый к сети. Все вышеупомянутые ключевые практики DevOps могут быть согласованы с сетью: конфигурации устройств могут быть шаблонными (IaC) и помещены в систему контроля версий, где применяются процессы CI / CD.
Ниже приведен пример схемы, представляющей весь процесс.
Рабочий процесс начинается с того, что сетевой оператор вносит изменение (1) либо в Источник истины, либо в шаблоны конфигурации. Так что именно?
Источником истины является база данных (например, база данных SQL или простые текстовые файлы), в которой хранятся такие константы, как номера VLAN и IP-адреса. Фактически, это может быть несколько баз данных — вы можете получить информацию об IP из IPAM, а описания интерфейсов из DCIM (Netbox — отличный пример, который может делать и то, и другое). Ключевая идея здесь заключается в том, что каждая база данных должна быть единственным источником истины для определенной части информации поэтому когда вам нужно что-то изменить, вы меняете это только в одном месте.
Шаблоны конфигурации — это просто текстовые файлы, написанные на выбранном языке шаблонов (я думаю, Jinja2 — самый популярный). В сочетании с информацией из SoT они создают файлы конфигурации для конкретных устройств. Шаблоны позволяют разбивать конфигурации устройств на отдельные файлы шаблонов, каждый из которых представляет определенный раздел конфигурации, а затем смешивать и сопоставлять их для создания конфигураций для различных сетевых устройств. Некоторые шаблоны могут быть повторно использованы на нескольких устройствах, а некоторые могут быть созданы для определенных версий программного обеспечения или поставщиков.
Внесение изменений в SoT или шаблоны запускает (2) остальную часть процесса. Во-первых, оба этих источника информации используются системой управления конфигурацией (например, Ansible, подробнее об этом позже) для генерации результирующих файлов конфигурации, которые будут применяться к сетевым устройствам. Затем эти конфигурации должны быть проверены (3). Валидация обычно включает в себя несколько автоматических тестов (проверка синтаксиса, использование программного обеспечения для моделирования, запуск виртуальных устройств) и экспертную оценку. Если проверка не удалась, инициатору изменения предоставляется обратная связь (4), чтобы он мог исправить ситуацию и снова запустить весь процесс. Если проверка пройдена, полученные конфигурации можно развернуть в производственной сети (5).
Конечно, представленный рабочий процесс довольно схематичен и призван дать общее представление о процессе автоматизации сети и роли в нем основных компонентов.
В следующем разделе я собираюсь рассмотреть инструменты и технологии, которые можно использовать в рабочих процессах сетевой автоматизации.
Модели данных и кодировки
Понимание того, как данные могут быть структурированы и закодированы, очень важно для программирования в целом и автоматизации сети в частности.
YANG и Openconfig
YANG (еще одно новое поколение) — это язык моделирования данных, первоначально разработанный для NETCONF и определенный в RFC 6020, а затем обновленный в RFC 7950. YANG и NETCONF можно рассматривать как преемников SMIng и SNMP соответственно.
YANG предоставляет независимый от формата способ описания модели данных, которая может быть представлена в XML или JSON.
Джейсон Эдельман, Скотт С. Лоу, Мэтт Освальт. Сетевое программирование и автоматизация, стр. 183
Существуют сотни моделей данных YANG, которые не зависят от поставщика и зависят от поставщика. Каталог ЯН веб — сайт может быть полезным, если вам нужно найти модели данных, имеющие отношение к вашим задачам.
Из-за обилия моделей данных и отсутствия координации между организациями, занимающимися разработкой стандартов, и поставщиками кажется, что YANG и NETCONF идут по тому же пути, по которому пошел SNMP (т.е. используется только для извлечения данных, но не для настройки). Рабочая группа OpenConfig пытается решить эту проблему, предоставляя модели данных, не зависящие от поставщиков, но я думаю, что точка зрения Ивана Пепельняка от 2018 года о том, что:
«бесшовная конфигурация сетевых устройств с несколькими поставщиками по-прежнему остается несбыточной мечтой », все еще актуальна в 2020 году.
XML
XML (расширяемый язык разметки), хотя и немного устарел, все еще широко используется в различных API. Он использует теги для кодирования данных, поэтому его трудно читать людям. Первоначально он был разработан для документов, но подходит для представления произвольных структур данных.
Вы можете обратиться к этому руководству, чтобы узнать больше о XML.
Давайте посмотрим, как этот пример вывода CLI команды Cisco IOS show vlanможет быть закодирован с помощью XML:
VLAN Name Status Ports
—- ——————————— ——— ——————————-
1 default active Gi3/4, Gi3/5, Gi4/11
<…>
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
—- —— ———- —— —— —— ——— —- ——— —— ——
1 enet 100001 1500 — — — — — 0 0
Вот как это выглядит в XML:
<?xml version=»1.0″ encoding=»UTF-8″ ?>
<root>
<vlans>
<1>
<interfaces>GigabitEthernet3/4</interfaces>
<interfaces>GigabitEthernet3/5</interfaces>
<interfaces>GigabitEthernet4/11</interfaces>
<mtu>1500</mtu>
<name>default</name>
<said>100001</said>
<shutdown>false</shutdown>
<state>active</state>
<trans1>0</trans1>
<trans2>0</trans2>
<type>enet</type>
<vlan_id>1</vlan_id>
</1>
</vlans>
</root>
YAML
YAML (YAML Ain’t Markup Language) — это удобный для человека формат сериализации данных. Поскольку YAML действительно легко читать и писать, он широко используется в современных инструментах автоматизации для файлов конфигурации и даже для определения логики задач автоматизации (см. Ansible).
Вы можете обратиться к этому руководству, чтобы узнать больше о YAML.
Вот show vlanвывод из предыдущего подраздела, закодированный в YAML:
—
vlans:
‘1’:
interfaces:
— GigabitEthernet3/4
— GigabitEthernet3/5
— GigabitEthernet4/11
mtu: 1500
name: default
said: 100001
shutdown: false
state: active
trans1: 0
trans2: 0
type: enet
vlan_id: ‘1’
Бонус: сборник недостатков YAML.
JSON
JSON (JavaScript Object Notation) — это современный формат кодирования данных, определенный в RFC 7159 и широко используемый в веб-API. Он легкий, удобочитаемый и больше подходит для моделей данных современных языков программирования, чем XML.
Вы можете обратиться к этому руководству, чтобы узнать больше о JSON.
Вот пример данных из предыдущих разделов, закодированных в JSON:
{
«vlans»: {
«1»: {
«interfaces»: [
«GigabitEthernet3/4»,
«GigabitEthernet3/5»,
«GigabitEthernet4/11»
],
«mtu»: 1500,
«name»: «default»,
«said»: 100001,
«shutdown»: false,
«state»: «active»,
«trans1»: 0,
«trans2»: 0,
«type»: «enet»,
«vlan_id»: «1»
}
}
}
Как видите, его почти так же легко читать, как и YAML, однако собственный JSON не поддерживает комментарии, что делает его не очень подходящим для файлов конфигурации.
Резюме
Вот сводная таблица, представляющая ключевые свойства описанных форматов данных.
| XML | YAML | JSON | |
| Человек читаемый | не совсем | да | да |
| Цель | документы, API | файлы конфигурации | API |
| Библиотеки Python | xml , lxml | PyYAML | json |
Существуют онлайн-инструменты, подобные этому, для преобразования данных между всеми тремя форматами.