Комментарии 10
Вы пишите «ушло 90% рутины». Пожалуйста, приведите примеры той рутины, что вы оптимизировали. Я сколько раз пытаюсь придумать, куда бы в сети применить все эти замечательные ниндзютцу и не нахожу. Есть только пара случаев — первоначальный конфиг устройства и массовые однотипные изменения (типа, на всех устройствах обновить ACL для административного доступа). В остальных случаях, я не вижу особой пользы от всего этого модного, т.к. тупо увеличивается время на решение проблем, а сами проблемы не решаются кардинально. Да и даже для указанных примеров проще применить уже давно проработанные ZTP или использовать устоявшиеся инструменты типа Cisco Prime.
У нас в сети, например, полно рутины. Создание-прокидывание новых вланов, выделение IP-подсетей, создание интерфейсов на роутерах, постоянные изменения сетевых ACL. Десятки в день заявок. Пока что далеко не всё из этого автоматизированно, а руками всё это делается довольно долго.
Prime так-то не дешёвый…
Prime так-то не дешёвый…
вот давайте пример в студию — как автоматизировать с помощью стандартных open-source средств «прокидывание vlan-а»? допустим, есть цепочка из 5и свитчей где надо: 1) добавить vlan, 2) залезть на 3-5 (на каждом свитче по-разному) разных интерфейсов и добавить vlan в список разрешенных, 3) настроить приоритет stp для этого vlan-а (тоже на всех свитчах разный)
В YAML файле вы можете все это указать. На какой свитч заходить, какая модель свича, что делать с stp. И исходя из этого будут созданы конфиги.
Так же ничто не мешает вам сначала понять по какой логике вы куда заходите и правите а потом формально отразить это в ваших скриптах. Вы же принимете решение исходя из каких-то начальных параметров или условий — опишите их формально а потом воплотите.
Посмотрите как это сделано например с доступам в psefabric
Так же ничто не мешает вам сначала понять по какой логике вы куда заходите и правите а потом формально отразить это в ваших скриптах. Вы же принимете решение исходя из каких-то начальных параметров или условий — опишите их формально а потом воплотите.
Посмотрите как это сделано например с доступам в psefabric
вот я и вижу, что быстрее это сделать руками, чем писать скрипты. Если прокидывать vlan-ы надо каждый раз на одинаковый набор свитчей и на примерно одинаковый набор портов — то может имеет смысл автоматизировать. Но если каждый раз нужно составить инвентори, подправить шаблон, написать новый кусок шаблона — то всё это не имеет смысла.
В README проекта PAY я пишу когда это может быть полезным.
В основном это может быть полезно в двух случаях:
В моем случае это и второе и первое. У нас датацентр состоит из 3х сегментов. С точки зрения дизайна они одинаковы. То есть темплейты одинаковы. Так же есть еще аналогичные staging и dev. Мне не нужно думать над конфигруацией — я только ввожу то, чем все эти сегменты отличаются, а именно ip адреса, номера bgp as, имена объектов… и все — конфиг создается сам.
И после этого мне не нужно идти и добавлять все это в документацию. Говоря про 90 процентов я думаю, что я даже приуменьшил :)
В вашем случае нужно найти повторяющиеся задачи. Например, в моей практике это было создание виртуальных серверов для балансировки — вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы… и обычно это все довольно однотипно. А делать это приходилось довольно часто.
В основном это может быть полезно в двух случаях:
- у вас есть повторяющиеся операции с одинаковым или похожим синтаксисом, но с разными параметрами
- на этапе реализации проекта. Этот подход позволяет вам использовать best practices в управления изменениями на основе git и git-подобных приложений
В моем случае это и второе и первое. У нас датацентр состоит из 3х сегментов. С точки зрения дизайна они одинаковы. То есть темплейты одинаковы. Так же есть еще аналогичные staging и dev. Мне не нужно думать над конфигруацией — я только ввожу то, чем все эти сегменты отличаются, а именно ip адреса, номера bgp as, имена объектов… и все — конфиг создается сам.
И после этого мне не нужно идти и добавлять все это в документацию. Говоря про 90 процентов я думаю, что я даже приуменьшил :)
В вашем случае нужно найти повторяющиеся задачи. Например, в моей практике это было создание виртуальных серверов для балансировки — вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы… и обычно это все довольно однотипно. А делать это приходилось довольно часто.
я не совсем уверен, что «использовать best practices в управления изменениями на основе git и git-подобных приложений» хорошо для сети. Это звучит как «я изучаю питон потому что все вокруг изучают питон» )
по поводу «вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы» — неужто у вас одинаковые приложения? у меня в работе архитектура около 10 проектов и в каждом из них — сильно разные виртуальные машины, ОЧЕНЬ разные карты доступов — этого точно не заскриптуешь, настройки балансировщиков тоже разные, потому что приложения используют разные протоколы, разные health-checks. Писать все это в скриптах — значит потратить больше времени, я уже молчу, что в скрипте можно ошибиться и придется начинать всё заново, а сперва почистить.
по поводу «вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы» — неужто у вас одинаковые приложения? у меня в работе архитектура около 10 проектов и в каждом из них — сильно разные виртуальные машины, ОЧЕНЬ разные карты доступов — этого точно не заскриптуешь, настройки балансировщиков тоже разные, потому что приложения используют разные протоколы, разные health-checks. Писать все это в скриптах — значит потратить больше времени, я уже молчу, что в скрипте можно ошибиться и придется начинать всё заново, а сперва почистить.
>я не совсем уверен…
в проектировании очень полезно. Вы имеете трек всех изменений, понимаете кто делал эти изменения и когда. Так же вы можете ввести процедуру согласования изменений с архитекторами и если хотите с клиентом, вы можете делать разные ветки,… В общем все тоже что и врограммировании… поверьте это очень полезно. И я как раз говорил про полезность данного действие при проектировании.
>неужто у вас одинаковые приложения?
нет, конечно. Но это может быть с десяток различных конфигураций, ну, может чуть больше. Я их опишу за пару дней. Создание шаблонов это во многом простое копирование вашей реальной конфигурации.
Если же вам каждый раз или почти каждый раз приходится создавать что-то новое, то этот подход не для вас, но зачем такое разнообразие?
в проектировании очень полезно. Вы имеете трек всех изменений, понимаете кто делал эти изменения и когда. Так же вы можете ввести процедуру согласования изменений с архитекторами и если хотите с клиентом, вы можете делать разные ветки,… В общем все тоже что и врограммировании… поверьте это очень полезно. И я как раз говорил про полезность данного действие при проектировании.
>неужто у вас одинаковые приложения?
нет, конечно. Но это может быть с десяток различных конфигураций, ну, может чуть больше. Я их опишу за пару дней. Создание шаблонов это во многом простое копирование вашей реальной конфигурации.
Если же вам каждый раз или почти каждый раз приходится создавать что-то новое, то этот подход не для вас, но зачем такое разнообразие?
Генерация конфига для greenfield — это наименьшая из проблем.
Хотя даже здесь возникает вопрос — как хранить данные? Если конфиг чуть проще, чем банальное прописывание параметров ntp/dns/ssh, то уже возникает вопрос с форматом описания (например, параметров BGP).
А вот когда у вас brownfield, всё становится гораздо интереснее :)
P.S. Вы же уже, надеюсь, читали статьи из АДСМ?
Хотя даже здесь возникает вопрос — как хранить данные? Если конфиг чуть проще, чем банальное прописывание параметров ntp/dns/ssh, то уже возникает вопрос с форматом описания (например, параметров BGP).
А вот когда у вас brownfield, всё становится гораздо интереснее :)
P.S. Вы же уже, надеюсь, читали статьи из АДСМ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как взять сетевую инфраструктуру под свой контроль. Глава четвертая. Автоматизация. Темплейты