Эта статья является шестой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти .
Оставив несколько тем позади, я решил все же начать новую главу.
К безопасности вернусь чуть позже. Здесь я хочу обсудить один простой, но эффективный подход, который, уверен, в том или ином виде, может пригодиться многим. Это скорее короткая история о том, как автоматизация может изменить жизнь инженера. Речь пойдет об использовании темлейтов. В конце приводится список моих проектов, где можно посмотреть, как все описанное здесь работает.
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
Я говорил, что несколько примеров достаточно, чтобы понять, как это работает.
Здесь краткая (и конечно видоизмененная) версия того, что было создано в процессе моей работы.
= deployment Palo Alto from Yaml = Palo Alto from Yaml
= deployment F5 from Yaml = F5 from Yaml (скоро будет)
= deployment ACi from Yaml = F5 from Yaml
Добавлю несколько слов об ACY (не путать с ACI).
Те, кто работал с ACI знают, что это чудо (и в хорошем смысле тоже) было создано точно не сетевиками :). Забудьте все что вы знали о сети — это вам не пригодится!
Немного утрировано, но приблизительно передает то ощущение, которое я постоянно, вот уже 3 года, испытываю, работая с ACI.
И в данном случае ACY — это не только возможность выстроить процесс контроля изменений (что особенно важно в случае ACI, потому что предполагается, что это центральная и наиболее критичная часть вашего дата-центра), но также дает вам дружественный интерфейс для создания конфигурации.
Инженеры в данном проекте для конфигурирования ACI вместо YAML для точности тех же целей используют Excel. В использовании Excel, конечно, есть плюсы:
- ваш NIP в одном файле
- красивые таблички, на которые приятно смотреть клиенту
- вы можете использовать некоторые инструменты Excel
Но есть один минус, и он на мой взгляд перевешивает плюсы. Контролировать изменения и согласовывать работу команды становится намного сложнее.
ACY — это фактически применение тех же подходов, что я использовал для 3rd party, для конфигурирования ACI.
Источник: habr.com