Эта статья является шестой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.
Оставив несколько тем позади, я решил все же начать новую главу.
К безопасности вернусь чуть позже. Здесь я хочу обсудить один простой, но эффективный подход, который, уверен, в том или ином виде, может пригодиться многим. Это скорее короткая история о том, как автоматизация может изменить жизнь инженера. Речь пойдет об использовании темлейтов. В конце приводится список моих проектов, где можно посмотреть, как все описанное здесь работает.
Создание конфигурации скриптом, использование 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.
Теперь процесс изменений выглядел следующим образом:
Понятно, что сначала много времени уходило на правки, но через неделю-две это уже стало скорее редкостью.
Хорошей проверкой и возможностью все отладить стало желание клиента изменить naming convention. Кто работал с F5 понимает пикантность ситуации. Но для меня все было довольно просто. Я поменял имена в YAML файле, удалил всю конфигурацию с оборудования, сгенерировал новую и залил. На все, с учетом правок багов, ушло 4 дня: по два дня на каждую технологию. После этого я был готов к следующем этапу, а именно создание DEV и Staging дата-центров.
Staging фактически полностью повторяет production. Dev — сильно урезанная и построенная в основном на виртуальном оборудовании копия. Идеальная ситуация для применения нового подхода. Если из общего процесса вычленить потраченное мною время, то работы, думаю, заняли не более 2х недель. Основное время — это время ожидания другой стороны, и совместные поиски проблем. Имплементация 3rd party прошла почти незаметно для окружающих. Появилось даже время что-то поучить и написать пару статей на Хабре :)
Итак, что я имею в сухом остатке?
Все это привело к тому, что
Я говорил, что несколько примеров достаточно, чтобы понять, как это работает.
Здесь краткая (и конечно видоизмененная) версия того, что было создано в процессе моей работы.
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, конечно, есть плюсы:
Но есть один минус, и он на мой взгляд перевешивает плюсы. Контролировать изменения и согласовывать работу команды становится намного сложнее.
ACY — это фактически применение тех же подходов, что я использовал для 3rd party, для конфигурирования ACI.
Оставив несколько тем позади, я решил все же начать новую главу.
К безопасности вернусь чуть позже. Здесь я хочу обсудить один простой, но эффективный подход, который, уверен, в том или ином виде, может пригодиться многим. Это скорее короткая история о том, как автоматизация может изменить жизнь инженера. Речь пойдет об использовании темлейтов. В конце приводится список моих проектов, где можно посмотреть, как все описанное здесь работает.
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, конечно, есть плюсы:
- ваш NIP в одном файле
- красивые таблички, на которые приятно смотреть клиенту
- вы можете использовать некоторые инструменты Excel
Но есть один минус, и он на мой взгляд перевешивает плюсы. Контролировать изменения и согласовывать работу команды становится намного сложнее.
ACY — это фактически применение тех же подходов, что я использовал для 3rd party, для конфигурирования ACI.
Комментарии (9)
nihole Автор
29.05.2019 14:48В README проекта PAY я пишу когда это может быть полезным.
В основном это может быть полезно в двух случаях:
- у вас есть повторяющиеся операции с одинаковым или похожим синтаксисом, но с разными параметрами
- на этапе реализации проекта. Этот подход позволяет вам использовать best practices в управления изменениями на основе git и git-подобных приложений
В моем случае это и второе и первое. У нас датацентр состоит из 3х сегментов. С точки зрения дизайна они одинаковы. То есть темплейты одинаковы. Так же есть еще аналогичные staging и dev. Мне не нужно думать над конфигруацией — я только ввожу то, чем все эти сегменты отличаются, а именно ip адреса, номера bgp as, имена объектов… и все — конфиг создается сам.
И после этого мне не нужно идти и добавлять все это в документацию. Говоря про 90 процентов я думаю, что я даже приуменьшил :)
В вашем случае нужно найти повторяющиеся задачи. Например, в моей практике это было создание виртуальных серверов для балансировки — вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы… и обычно это все довольно однотипно. А делать это приходилось довольно часто.Karroplan
29.05.2019 15:19я не совсем уверен, что «использовать best practices в управления изменениями на основе git и git-подобных приложений» хорошо для сети. Это звучит как «я изучаю питон потому что все вокруг изучают питон» )
по поводу «вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы» — неужто у вас одинаковые приложения? у меня в работе архитектура около 10 проектов и в каждом из них — сильно разные виртуальные машины, ОЧЕНЬ разные карты доступов — этого точно не заскриптуешь, настройки балансировщиков тоже разные, потому что приложения используют разные протоколы, разные health-checks. Писать все это в скриптах — значит потратить больше времени, я уже молчу, что в скрипте можно ошибиться и придется начинать всё заново, а сперва почистить.nihole Автор
29.05.2019 15:29>я не совсем уверен…
в проектировании очень полезно. Вы имеете трек всех изменений, понимаете кто делал эти изменения и когда. Так же вы можете ввести процедуру согласования изменений с архитекторами и если хотите с клиентом, вы можете делать разные ветки,… В общем все тоже что и врограммировании… поверьте это очень полезно. И я как раз говорил про полезность данного действие при проектировании.
>неужто у вас одинаковые приложения?
нет, конечно. Но это может быть с десяток различных конфигураций, ну, может чуть больше. Я их опишу за пару дней. Создание шаблонов это во многом простое копирование вашей реальной конфигурации.
Если же вам каждый раз или почти каждый раз приходится создавать что-то новое, то этот подход не для вас, но зачем такое разнообразие?
Karroplan
Вы пишите «ушло 90% рутины». Пожалуйста, приведите примеры той рутины, что вы оптимизировали. Я сколько раз пытаюсь придумать, куда бы в сети применить все эти замечательные ниндзютцу и не нахожу. Есть только пара случаев — первоначальный конфиг устройства и массовые однотипные изменения (типа, на всех устройствах обновить ACL для административного доступа). В остальных случаях, я не вижу особой пользы от всего этого модного, т.к. тупо увеличивается время на решение проблем, а сами проблемы не решаются кардинально. Да и даже для указанных примеров проще применить уже давно проработанные ZTP или использовать устоявшиеся инструменты типа Cisco Prime.
athacker
У нас в сети, например, полно рутины. Создание-прокидывание новых вланов, выделение IP-подсетей, создание интерфейсов на роутерах, постоянные изменения сетевых ACL. Десятки в день заявок. Пока что далеко не всё из этого автоматизированно, а руками всё это делается довольно долго.
Prime так-то не дешёвый…
Karroplan
вот давайте пример в студию — как автоматизировать с помощью стандартных open-source средств «прокидывание vlan-а»? допустим, есть цепочка из 5и свитчей где надо: 1) добавить vlan, 2) залезть на 3-5 (на каждом свитче по-разному) разных интерфейсов и добавить vlan в список разрешенных, 3) настроить приоритет stp для этого vlan-а (тоже на всех свитчах разный)
nihole Автор
В YAML файле вы можете все это указать. На какой свитч заходить, какая модель свича, что делать с stp. И исходя из этого будут созданы конфиги.
Так же ничто не мешает вам сначала понять по какой логике вы куда заходите и правите а потом формально отразить это в ваших скриптах. Вы же принимете решение исходя из каких-то начальных параметров или условий — опишите их формально а потом воплотите.
Посмотрите как это сделано например с доступам в psefabric
Karroplan
вот я и вижу, что быстрее это сделать руками, чем писать скрипты. Если прокидывать vlan-ы надо каждый раз на одинаковый набор свитчей и на примерно одинаковый набор портов — то может имеет смысл автоматизировать. Но если каждый раз нужно составить инвентори, подправить шаблон, написать новый кусок шаблона — то всё это не имеет смысла.
nihole Автор
Да, конечно, все надо применять по делу. Думаю есть много ситуаций, когда это не имеет смысла, если только не хочется самим научиться чему-то новому :)