Тази статия е шестата в цикъла статии „Как да контролирате мрежовата инфраструктура под своя контрол“. Съдържанието на всички статии от цикъла и линкове можете да намерите .
Оставяйки няколко теми зад себе си, реших да започна нова глава.
Ще се върна на сигурността по-късно. Тук искам да обсъдим един прост, но ефективен подход, който, съм уверен, по един или друг начин, може да бъде полезен на много хора. Това е по-скоро кратка история за това как автоматизацията може да промени живота на инженера. Речта ми ще бъде за използването на шаблони. В края е предоставен списък на моите проекти, където можете да видите как всичко описано тук работи.
DevOps за мрежата
Създаването на конфигурация със скрипт, използването на GIT за контрол на промените в IT инфраструктурата, дистанционно „зареждане“ — тези идеи идват на първо място, когато се замисляте за техническото реализиране на DevOps подхода. Плюсовете са очевидни. Но, за съжаление, има и минуси.
Когато преди повече от 5 години нашите разработчици дойдоха при нас, мрежовците, с тези предложения, не бяхме особено развълнувани.
Трябва да се каже, че в наследство получихме доста шарена мрежа, състояща се от оборудване на около 10 различни производителя. Нещо беше удобно за конфигуриране през нашия любим cli, но на някои места предпочитахме да използваме GUI. Освен това, дългият опит с „живото“ оборудване ни е научил на реално време контрол. Аз, например, когато правя промени, се чувствам много по-комфортно, работейки директно през cli. Така мога бързо да видя, че нещо не е наред и да „върна“ промените. Всичко това се намира в някакво противоречие с техните идеи.
Има и други въпроси, например, от версия на версия софтуерът интерфейсът може да се променя малко. В крайна сметка, това ще доведе до факта, че вашият скрипт ще създава неправилен „конфиг“. Не бих искал да използвам продукция за „тестове“.
Или, как да разберем, че конфигурационните команди са приложени правилно и какво да правим в случай на грешка?
Не искам да кажа, че всичките тези въпроси са нерешими. Просто казвайки «A», вероятно е разумно да кажем и «B» и, ако искате да използвате същите процеси за контрол на промените, както в разработката, трябва да имате, освен production, също dev и staging среди. Тогава този подход изглежда завършен. Но колко ще струва това?
Но има една ситуация, когато минусите практически се нивелират и остават само плюсове. Говоря за проектни работи.
Проект
Последните две години участвам в проект за изграждане на дата център за един голям доставчик. Отговарям за F5 и Palo Alto в този проект. От гледна точка на Cisco, това е «3rd party equipment».
Лично за мен има две ясно изразени фази в този проект.
Първа фаза
Първата година бях безкрайно зает, работех през нощите и уикендите. Не можех да вдигна глава. Натиска от страна на ръководството и клиента беше силен и непрекъснат. В постоянната рутина не можех дори да опитам да оптимизирам процеса. Това не беше само и дори не толкова конфигуриране на оборудването, колкото съставяне на проектна документация.
Започнаха първите тестове и бях поразен колко много малки грешки и неточности бяха допуснати. Разбира се, всичко работеше, но там липсваше буква в името, тук липсваше ред в командата... Тестовете продължаваха и продължаваха, а аз бях в постоянна, ежедневна борба с грешките, тестовете и документацията.
Така продължи година. Проектът, доколкото разбирам, не беше лесен за всички, но постепенно клиентът ставаше все по-доволен и това предостави възможност да назначим допълнителни инженери, които да поемат част от рутинната работа.
Сега вече можех да огледам обстановката.
И това беше началото на втория етап.
Втора фаза
Реших да автоматизирам процеса.
Какво разбрах от тогавашния контакт с разработчиците (и трябва да се признае, че имахме силен екип) е, че текстовият формат, макар и да изглежда на пръв поглед като нещо от света на операционната система DOS, има редица ценни свойства.
Така например текстовият формат ще бъде полезен, ако искате да използвате в пълна степен предимствата на GIT и всички негови производни. А аз исках.
На пръв поглед, може да изглежда лесно да се съхранява конфигурация или списък с команди, но е доста неудобно да се извършват промени. Освен това, при проектирането има още една важна задача. Трябва да имате документация, която описва вашия дизайн в общи линии (Ниско равнище на дизайн) и конкретната имплементация (План за мрежова имплементация). В този случай използването на шаблони изглежда много подходящо.
Така, при използване на YAML и Jinja2, YAML файлът с параметрите на конфигурацията, като IP адреси, номера на BGP AS и т.н., отлично изпълнява ролята на NIP, докато шаблоните на Jinja2 съдържат синтаксис, съответстващ на дизайна, което в същността си е отражение на LLD.
На изучаването на езиците YAML и Jinja2 ми отне два дни. За да разбера как работят, е достатъчно да имам няколко добри примера. След това отделих около две седмици за създаването на всички шаблони, съответстващи на нашия дизайн: една седмица за Palo Alto и още една седмица за F5. Всичко това беше публикувано в корпоративния GitHub.
Сега процесът на промяна изглеждаше така:
- промених YAML файла
- създадох конфигурационен файл с помощта на шаблона (Jinja2)
- съхраних в отдалечен репозиторий
- качих създадената конфигурация на оборудването
- видях грешка
- промених YAML файла или шаблона на Jinja2
- създадох конфигурационен файл с помощта на шаблона (Jinja2)
- …
Разбира се, в началото много време отиваше за корекции, но след една-две седмици това стана по-скоро рядкост.
Добра проверка и възможност за отстраняване на грешки стана желанието на клиента да промени конвенцията за именуване. Всеки, който е работил с F5, разбира деликатността на ситуацията. Но за мен всичко беше доста просто. Промених имената в YAML файла, изтрих цялата конфигурация от оборудването, генерирах нова и я качих. Всичко, като се вземат предвид корекциите на грешките, отне 4 дни: по два дни за всяка технология. След това бях готов за следващия етап, а именно създаването на DEV и Staging центрове.
Dev и Staging
Staging фактически напълно възпроизвежда production. Dev е значително ограничена и изградена основно на виртуално оборудване. Идеалната ситуация за прилагане на нов подход. Ако извадя прекараното от мен време от общия процес, смятам, че работата ми отне не повече от 2 седмици. Основното време е времето на изчакване от другата страна и съвместното търсене на проблеми. Имплементацията на 3rd party премина почти незабележимо за околните. Появи се дори време да науча нещо и да напиша няколко статии в Хабре 🙂
Нека обобщим
И така, какво имам в крайна сметка?
- всичко, от което се нуждая за промяна на конфигурацията — да променя прост, ясно структуриран YAML файл с конфигурационни параметри. Никога не променям python скрипт и много рядко (само ако има грешка) променям Jinja2 темплейт
- от гледна точка на документацията ситуацията е почти идеална. Вие променяте документацията (YAML файловете изпълняват ролята на NIP) и качвате тази конфигурация на оборудването. Така вашата документация винаги е актуална
Всичко това доведе до факта, че
- процентът на грешките намаля почти до 0
- отне 90 процента от рутинната работа
- значително увеличена е скоростта на внедряване
PAY, F5Y, ACY
Казах, че няколко примера са достатъчни, за да разбера как работи.
Тук е кратка (и разбира се променена) версия на това, което беше създадено в процеса на моята работа.
= внедряване Palo Alto от Yaml = Palo Alto от Yaml
= внедряване F5 from Yaml = F5 from Yaml (скоро ще бъде)
= внедряване ACi от Yaml = F5 from Yaml
Добавя няколко думи за ACY (да не се бърка с ACI).
Тези, които са работили с ACI знаете, че това чудо (и в добрия смисъл) беше създадено съвсем не от мрежари :). Забравете всичко, което знаете за мрежите — това няма да ви е от полза!
Някои изразени, но приблизително предава това усещане, което редовно, вече 3 години, изпитвам, работейки с ACI.
И в този случай ACY не е само възможността да изградиш процес за контрол на промените (което е особено важно в случай на ACI, защото се предполага, че това е централната и най-критична част от вашия дата център), но също така ви дава приятелски интерфейс за изграждане на конфигурация.
Инженерите в този проект за конфигуриране на ACI вместо YAML за същата точност използват Excel. В ползването на Excel, разбира се, има предимства:
- вашият NIP в един файл
- красиви таблици, които е приятно да се гледат от клиента
- можете да използвате някои инструменти на Excel
Но има един минус, който, според мен, надвишава плюсовете. Контролът върху промените и съгласуването на работата на екипа става много по-сложно.
ACY е всъщност прилагането на същите подходи, които използвах за 3rd party, за конфигуриране на ACI.
Източник: habr.com
