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

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

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

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

    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.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 10

      +1
      Вы пишите «ушло 90% рутины». Пожалуйста, приведите примеры той рутины, что вы оптимизировали. Я сколько раз пытаюсь придумать, куда бы в сети применить все эти замечательные ниндзютцу и не нахожу. Есть только пара случаев — первоначальный конфиг устройства и массовые однотипные изменения (типа, на всех устройствах обновить ACL для административного доступа). В остальных случаях, я не вижу особой пользы от всего этого модного, т.к. тупо увеличивается время на решение проблем, а сами проблемы не решаются кардинально. Да и даже для указанных примеров проще применить уже давно проработанные ZTP или использовать устоявшиеся инструменты типа Cisco Prime.
        +1
        У нас в сети, например, полно рутины. Создание-прокидывание новых вланов, выделение IP-подсетей, создание интерфейсов на роутерах, постоянные изменения сетевых ACL. Десятки в день заявок. Пока что далеко не всё из этого автоматизированно, а руками всё это делается довольно долго.

        Prime так-то не дешёвый…
          0
          вот давайте пример в студию — как автоматизировать с помощью стандартных open-source средств «прокидывание vlan-а»? допустим, есть цепочка из 5и свитчей где надо: 1) добавить vlan, 2) залезть на 3-5 (на каждом свитче по-разному) разных интерфейсов и добавить vlan в список разрешенных, 3) настроить приоритет stp для этого vlan-а (тоже на всех свитчах разный)
            0
            В YAML файле вы можете все это указать. На какой свитч заходить, какая модель свича, что делать с stp. И исходя из этого будут созданы конфиги.
            Так же ничто не мешает вам сначала понять по какой логике вы куда заходите и правите а потом формально отразить это в ваших скриптах. Вы же принимете решение исходя из каких-то начальных параметров или условий — опишите их формально а потом воплотите.

            Посмотрите как это сделано например с доступам в psefabric
              0
              вот я и вижу, что быстрее это сделать руками, чем писать скрипты. Если прокидывать vlan-ы надо каждый раз на одинаковый набор свитчей и на примерно одинаковый набор портов — то может имеет смысл автоматизировать. Но если каждый раз нужно составить инвентори, подправить шаблон, написать новый кусок шаблона — то всё это не имеет смысла.
                0
                Да, конечно, все надо применять по делу. Думаю есть много ситуаций, когда это не имеет смысла, если только не хочется самим научиться чему-то новому :)
        0
        В README проекта PAY я пишу когда это может быть полезным.

        В основном это может быть полезно в двух случаях:

        • у вас есть повторяющиеся операции с одинаковым или похожим синтаксисом, но с разными параметрами
        • на этапе реализации проекта. Этот подход позволяет вам использовать best practices в управления изменениями на основе git и git-подобных приложений


        В моем случае это и второе и первое. У нас датацентр состоит из 3х сегментов. С точки зрения дизайна они одинаковы. То есть темплейты одинаковы. Так же есть еще аналогичные staging и dev. Мне не нужно думать над конфигруацией — я только ввожу то, чем все эти сегменты отличаются, а именно ip адреса, номера bgp as, имена объектов… и все — конфиг создается сам.

        И после этого мне не нужно идти и добавлять все это в документацию. Говоря про 90 процентов я думаю, что я даже приуменьшил :)

        В вашем случае нужно найти повторяющиеся задачи. Например, в моей практике это было создание виртуальных серверов для балансировки — вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы… и обычно это все довольно однотипно. А делать это приходилось довольно часто.
          0
          я не совсем уверен, что «использовать best practices в управления изменениями на основе git и git-подобных приложений» хорошо для сети. Это звучит как «я изучаю питон потому что все вокруг изучают питон» )

          по поводу «вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы» — неужто у вас одинаковые приложения? у меня в работе архитектура около 10 проектов и в каждом из них — сильно разные виртуальные машины, ОЧЕНЬ разные карты доступов — этого точно не заскриптуешь, настройки балансировщиков тоже разные, потому что приложения используют разные протоколы, разные health-checks. Писать все это в скриптах — значит потратить больше времени, я уже молчу, что в скрипте можно ошибиться и придется начинать всё заново, а сперва почистить.
            0
            >я не совсем уверен…
            в проектировании очень полезно. Вы имеете трек всех изменений, понимаете кто делал эти изменения и когда. Так же вы можете ввести процедуру согласования изменений с архитекторами и если хотите с клиентом, вы можете делать разные ветки,… В общем все тоже что и врограммировании… поверьте это очень полезно. И я как раз говорил про полезность данного действие при проектировании.

            >неужто у вас одинаковые приложения?
            нет, конечно. Но это может быть с десяток различных конфигураций, ну, может чуть больше. Я их опишу за пару дней. Создание шаблонов это во многом простое копирование вашей реальной конфигурации.
            Если же вам каждый раз или почти каждый раз приходится создавать что-то новое, то этот подход не для вас, но зачем такое разнообразие?
          0
          Генерация конфига для greenfield — это наименьшая из проблем.
          Хотя даже здесь возникает вопрос — как хранить данные? Если конфиг чуть проще, чем банальное прописывание параметров ntp/dns/ssh, то уже возникает вопрос с форматом описания (например, параметров BGP).

          А вот когда у вас brownfield, всё становится гораздо интереснее :)
          P.S. Вы же уже, надеюсь, читали статьи из АДСМ?

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое