Когда я пытаюсь понять новую концепцию или технологию, я считаю полезным потратить дополнительное время на изучение происхождения предмета. Он дает контекст и перспективу, которые имеют решающее значение для понимания чего-то сложного. Итак, прежде чем погрузиться в тему автоматизации сети, я хотел бы сказать несколько слов о том, откуда все это взялось.
Конечно, автоматизация сети в некотором роде существует уже довольно давно. Вы можете вспомнить такие примеры, как использование Expect для подключения к сетевым устройствам и выдачи команд или написание сценариев EEM на маршрутизаторах Cisco, или, возможно, запуск сценариев, которые извлекают полезную информацию с сетевых устройств через SNMP. Так что же изменилось с тех пор? Почему автоматизация сети сейчас такая горячая тема? Мой ответ — рост движения DevOps.
Термин DevOps впервые появился где-то в 2008 и 2009 годах и был приписан Патрику Дебуа. В 2009 году он провел мероприятие под названием DevOpsDays, главной целью которого было собрать вместе разработчиков и системных администраторов и обсудить пути преодоления разрыва между ними. Это набрало обороты, и DevOps стало модным словом.
Но что такое DevOps? Академического определения нет, но наиболее распространенное гласит, что это набор инструментов, практик и принципов, направленных на преодоление разрыва между командами разработки и эксплуатации, чтобы быстрее создавать качественное программное обеспечение.
DevOps имеет множество аспектов, но я хотел бы сосредоточиться на трех ключевых практиках, которые он приносит: инфраструктура как код, CI / CD и контроль версий.
Инфраструктура как код
Согласно Википедии, IaC — это …
… процесс управления компьютерными центрами обработки данных и их инициализации с помощью машиночитаемых файлов определений, а не физической конфигурации оборудования или интерактивных средств конфигурации.
На самом деле это означает, что у вас есть набор текстовых файлов, в которых вы определяете желаемое состояние вашей инфраструктуры: количество виртуальных машин, их свойства, виртуальные сети, IP-адреса и т.д. Затем эти файлы обрабатываются инструментом или фреймворком IaC (Terraform, SaltStack — это всего лишь несколько примеров), который переводит это объявленное состояние в фактические вызовы API и файлы конфигурации и применяет его к инфраструктуре, чтобы привести его в желаемое состояние. Это дает вам уровень абстракции, поскольку вы сосредотачиваетесь только на конечном состоянии, а не на том, как его достичь. Здесь я должен упомянуть одну из ключевых особенностей подхода IaC — идемпотентность. Эта функция позволяет многократно запускать инструмент IaC, и если что-то уже находится в желаемом состоянии, оно не будет касаться его. Например, если вы объявляете, что определенная VLAN должна быть настроена на коммутаторе, и она уже существует, когда вы запускаете инструмент IaC для этого коммутатора, он не будет пытаться что-либо настраивать.
Рассмотрение вашей инфраструктуры как текстовых файлов позволяет вам применять к инфраструктуре те же инструменты и методы, что и к любому другому программному проекту. Основными примерами здесь являются CI / CD и контроль версий.
CI / CD
CI / CD означает непрерывную интеграцию / непрерывную доставку или развертывание.
Давайте рассмотрим каждый компонент более подробно:
Непрерывная интеграция — процесс частого (до нескольких раз в день) слияния изменений кода в основной репозиторий кода. Эти слияния сопровождаются различными тестами и процессами контроля качества, такими как модульные и интеграционные тесты, статический анализ кода, извлечение документации из исходного кода и т. Д. Этот подход позволяет часто интегрировать изменения кода разными разработчиками, что снижает риски конфликтов интеграции.
Непрерывная доставка — расширение CI, которое заботится об автоматизации процесса выпуска (например, упаковка, создание образа и т. Д.). Непрерывная доставка позволяет развернуть приложение в производственной среде в любое время.
Непрерывное развертывание — расширение непрерывной доставки, но на этот раз развертывание в производственной среде также автоматизировано.
Управление версиями
Система контроля версий — это основа любого проекта автоматизации. Он отслеживает изменения в файлах вашего проекта (исходный код), регистрирует, кто эти изменения вносил, и включает рабочие процессы CI / CD.
Сегодня Git является стандартом де-факто в системах управления версиями. По сути, Git — это просто инструмент командной строки (хотя и очень мощный), который управляет версией проекта, создавая и управляя метаданными, хранящимися в отдельном скрытом каталоге в рабочем каталоге проекта. Но все волшебство приходит с веб-системами управления версиями, такими как GitHub или GitLab среди других.
ПРИМЕЧАНИЕ. Многие путают Git и GitHub, потому что последний стал общим термином для систем контроля версий.
Предположим, вы работаете в команде разработчиков над проектом, размещенным на GitHub. Ваш типичный рабочий процесс будет выглядеть следующим образом:
- Вы хотите внести изменения в исходный код. Это может быть исправление ошибки или новая функция. Вы создаете новую ветку из основной и начинаете делать коммиты. Это никак не влияет на основную ветку.
- Когда кажется, что работа сделана, самое время создать пул-реквест . PR — это способ сообщить другим разработчикам (сопровождающим проекта), что вы хотите объединить свою ветку с основной. Создание PR может запускать тесты CI, если они настроены. После успешного прохождения всех тестов CI код проверяется другими членами команды. Если тесты CI не пройдут или что-то нужно улучшить, PR будет отклонен. Затем вы можете исправить свой код в той же ветке и создать еще один PR.
ПРИМЕЧАНИЕ. Обычно PR никогда не объединяются автоматически, и окончательное решение должен принимать кто-то.
- Если все хорошо, ваша ветка будет объединена с основной.
- Если CD настроен, слияние с основной ветвью запускает развертывание в производственной среде.
Итог
В этом разделе я дал краткий обзор того, что такое DevOps, а также его основных инструментов и практик. В следующем разделе я попытаюсь объяснить, как это можно применить к сетям и автоматизации сетей.