🥇Как взять сетевую инфраструктуру под свой контроль. Глава четвертая. Автоматизация. Темплейты

Эта статья является шестой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

Оставив несколько тем позади, я решил все же начать новую главу.

К безопасности вернусь чуть позже. Здесь я хочу обсудить один простой, но эффективный подход, который, уверен, в том или ином виде, может пригодиться многим. Это скорее короткая история о том, как автоматизация может изменить жизнь инженера. Речь пойдет об использовании темлейтов. В конце приводится список моих проектов, где можно посмотреть, как все описанное здесь работает.

DevOps для сети

Создание конфигурации скриптом, использование GIT для контроля изменений IT инфраструктуры, удаленная «заливка» — эти идеи приходят в первую очередь, когда вы задумываетесь о технической реализации DevOps подхода. Плюсы очевидны. Но есть, к сожалению, и минусы.

Когда более 5-ти лет назад, наши разработчики пришли к нам, к сетевикам, с этими предложениями, мы не были в восторге.

Надо сказать, что в наследство нам досталась довольно пестрая сеть, состоящая из оборудования порядка 10 различных вендоров. Что-то было удобно конфигурировать через наш любимый cli, но где-то мы предпочитали использовать GUI. К тому же, долгая работа на «живом» оборудовании приучили к реал-тайм контролю. Я, например, производя изменения, намного комфортней себя чувствую, работая непосредственно через cli. Так я могу быстро увидеть, что что-то пошло не так и «откатить» изменения. Все это находилось в некотором противоречии с их идеями.

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

Или, как понять, что конфигурационные команды применились корректно и что делать, в случае ошибки?

Не хочу сказать, что все эти вопросы нерешаемы. Просто сказав «A», наверно, разумно сказать и «В» и, если вы хотите использовать те же процессы для контроля изменений, что и в разработке, то нужно иметь помимо production также dev и staging среды. Тогда данный подход выглядит завершенным. Но сколько это будет стоить?

Но есть одна ситуация, когда минусы практически нивелируются, и остаются только плюсы. Я говорю о проектных работах.

Проект

Последние два года я участвую в проекте по построению дата-центра для одного крупного провайдера. Я отвечаю в этом проекте за F5 и Palo Alto. С точки зрения Cisco это «3rd party equipment».

Лично для меня есть две ярко выраженные стадии в этом проекте.

Первая стадия

Первый год я был бесконечно занят, я работал по ночам и по выходным. Я не мог поднять головы. Давление со стороны менеджмента и заказчика было сильным и непрерывным. В постоянной рутине я не мог даже попытаться оптимизировать процесс. Это было не только и даже не столько конфигурирование оборудования, сколько составление проектной документации.

Вот начались первые тесты, и я бы поражен, сколько мелких ошибок и неточностей было допущено. Конечно, все работало, но там пропущена буква в названии, здесь пропущена строка в команде… Тесты продолжались и продолжались, и я уже находился в постоянной, ежедневной борьбе с ошибками, тестами и документацией.

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

Теперь можно было чуть осмотреться.
И это было начало второго этапа.

Вторая стадия

Я решил автоматизировать процесс.

Что я понял из тогдашнего общения с разработчиками (и надо отдать должное, у нас была сильная команда), так это то, что текстовый формат, хотя, и кажется на первый взгляд чем-то из мира операционной системы DOS, но обладает рядом ценных свойств.
Так, например, текстовый формат будет полезен, если вы хотите в полной мере использовать преимущества GIT и всех его производных. А я хотел.

Ну, казалось бы, можно просто хранить конфигуруацию или список команд, но производить изменения при этом довольно неудобно. К тому же при проектировании стоит еще одна важная задача. У вас должна быть документация, описывающая ваш дизайн в целом (Low Level Design) и конкретная имплементация (Network Implementation Plan). И в данном случае использование темплейтов выглядит очень подходящим вариантом.

Так, при использование YAML и Jinja2, YAML файл с параметрами конфигурации, такими как IP адреса, номера BGP AS,… отлично выполняет роль NIP, в то время как Jinja2 темплейты включают в себя синтаксис соответствующий дизайну, то есть по сути является отражением LLD.

На изучение языков YAML и Jinja2 ушло два дня. Чтобы понять, как это работает достаточно нескольких хороших примеров. Далее порядка двух недель ушло на то, чтобы создать все темплейты, соответствующие нашему дизайну: неделя для Palo Alto и еще неделя — для F5. Все это было выложено на корпоративный githab.

Теперь процесс изменений выглядел следующим образом:

изменил YAML файл
создал с помощью шаблона (Jinja2) конфигурационный файл
сохранил в удаленном репозитории
залил созданную конфигурацию на оборудование
увидел ошибку
изменил YAML файл или Jinja2 темплейт
создал с помощью шаблона (Jinja2) конфигурационный файл
…

Понятно, что сначала много времени уходило на правки, но через неделю-две это уже стало скорее редкостью.

Хорошей проверкой и возможностью все отладить стало желание клиента изменить naming convention. Кто работал с F5 понимает пикантность ситуации. Но для меня все было довольно просто. Я поменял имена в YAML файле, удалил всю конфигурацию с оборудования, сгенерировал новую и залил. На все, с учетом правок багов, ушло 4 дня: по два дня на каждую технологию. После этого я был готов к следующем этапу, а именно создание DEV и Staging дата-центров.

Dev и Staging

Staging фактически полностью повторяет production. Dev — сильно урезанная и построенная в основном на виртуальном оборудовании копия. Идеальная ситуация для применения нового подхода. Если из общего процесса вычленить потраченное мною время, то работы, думаю, заняли не более 2х недель. Основное время — это время ожидания другой стороны, и совместные поиски проблем. Имплементация 3rd party прошла почти незаметно для окружающих. Появилось даже время что-то поучить и написать пару статей на Хабре 🙂

Подведем итог

Итак, что я имею в сухом остатке?

все, что требуется мне для изменения конфигурации — изменить простой, ясно структурированный YAML файл с конфигурационными параметрами. Я никогда не меняю python скрипт и очень редко (только если есть ошибка) меняю Jinja2 теплейт
с точки зрения документации получается почти идеальная ситуация. Вы меняете документацию (YAML файлы выполняют роль NIP) и заливаете эту конфигурацию на оборудование. Таким образом ваша документация всегда актуальна

Все это привело к тому, что

процент ошибок снизился практически до 0
ушло 90 процентов рутины
в разы увеличилась скорость внедрения

PAY, F5Y, ACY

Я говорил, что несколько примеров достаточно, чтобы понять, как это работает.
Здесь краткая (и конечно видоизмененная) версия того, что было создано в процессе моей работы.

PAY = deployment Palo Alto from Yaml = Palo Alto from Yaml
F5Y = deployment F5 from Yaml = F5 from Yaml (скоро будет)
ACY = deployment ACi from Yaml = F5 from Yaml

Добавлю несколько слов об ACY (не путать с ACI).

Те, кто работал с ACI знают, что это чудо (и в хорошем смысле тоже) было создано точно не сетевиками :). Забудьте все что вы знали о сети — это вам не пригодится!
Немного утрировано, но приблизительно передает то ощущение, которое я постоянно, вот уже 3 года, испытываю, работая с ACI.

И в данном случае ACY — это не только возможность выстроить процесс контроля изменений (что особенно важно в случае ACI, потому что предполагается, что это центральная и наиболее критичная часть вашего дата-центра), но также дает вам дружественный интерфейс для создания конфигурации.

Инженеры в данном проекте для конфигурирования ACI вместо YAML для точности тех же целей используют Excel. В использовании Excel, конечно, есть плюсы: