Тази статия е шестата в цикъла статии «Как да вземете мрежовата инфраструктура под контрол». Съдържанието на всички статии в цикъла и линковете могат да бъдат намерени .
Оставяйки няколко теми зад себе си, реших все пак да започна нова глава.
На безопасността ще се върна малко по-късно. Тук искам да обсъдя един прост, но ефективен подход, който, съм сигурен, в един или друг вид, може да бъде полезен на много. Това е по-скоро кратка история за това как автоматизацията може да промени живота на инженера. Ще става въпрос за използването на темплейти. В края има списък на моите проекти, където може да се види как всичко описано тук работи.
DevOps за мрежите
Създаването на конфигурация със скрипт, използването на GIT за контрол на промените в IT инфраструктурата, дистанционно „зареждане“ — тези идеи идват на първо място, когато се замислите за техническата реализация на DevOps подхода. Плюсовете са очевидни. Но, за съжаление, има и минуси.
Когато преди над 5 години нашите разработчици дойдоха при нас, мрежовиците, с тези предложения, не бяхме особено впечатлени.
Трябва да се каже, че наследството, което получихме, беше доста пъстро — мрежа, състояща се от оборудване на около 10 различни вендора. Някои неща бяха удобно да се конфигурират през нашия любим cli, но на други места предпочитахме да използваме GUI. Освен това, дългата работа с „живото“ оборудване ни накара да привикнем към реално време контрол. Аз, например, променяйки неща, се чувствам много по-комфортно, работейки директно през cli. Така мога бързо да видя, че нещо не върви наред и да „откатя“ промените. Всичко това беше в известно противоречие с техните идеи.
Възникват и други въпроси, например, от версия до версия софтуерът интерфейсът може да варира малко. В крайна сметка, това ще доведе до факта, че вашият скрипт ще създава неправилен „конфиг“. Не бих искал да използвам продукцията за „тестове“.
Или, как да разбереш, че конфигурационните команди са приложени коректно и какво да правиш в случай на грешка?
Не искам да казвам, че всички тези въпроси са нерешими. Просто казвайки „A“, вероятно е разумно да кажете и „B“, и ако искате да използвате същите процеси за контрол на промените, каквито имате в разработката, трябва да имате освен продукция и 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. Всичко беше публикувано в корпоративния gitHub.
Сега процесът на промени изглеждаше по следния начин:
- измених YAML файла
- създадох конфигурационен файл с помощта на шаблона (Jinja2)
- запазих го в отдалечен репозиторий
- изпратих създадената конфигурация на оборудването
- видях грешка
- измених YAML файла или шаблона на Jinja2
- създадох конфигурационен файл с помощта на шаблона (Jinja2)
- …
Разбира се, че в началото много време се отнемаше за корекции, но след седмица-две това стана по-скоро рядкост.
Добра проверка и възможност за отстраняване на проблеми стана желанието на клиента да промени името на конвенцията. Всеки, който е работил с F5, разбира пикантността на ситуацията. Но за мен всичко беше доста просто. Промених имената в YAML файла, изтрих цялата конфигурация от оборудването, генерирах нова и я качих. За всичко, с включение на отстраняване на грешки, отне 4 дни: по два дни за всяка технология. След това бях готов за следващия етап, а именно създаването на DEV и Staging дата-центрове.
Dev и Staging
Staging всъщност напълно повтаря продукцията. Dev е силно ограничена и изградена основно върху виртуално оборудване копия. Идеална ситуация за прилагане на новия подход. Ако изключим общия процес, мисля, че работата ми отне не повече от 2 седмици. Основното време — това е времето на чакане от другата страна и съвместното търсене на проблеми. Имплементирането на трета страна премина почти незабелязано за околните. Дори имаше време да науча нещо и да напиша няколко статии в Хабра 🙂
Нека обобщим
И така, какво имам в сухото остатъци?
- всичко, което ми трябва, за да променя конфигурацията — е да променя прост, ясно структуриран 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, тъй като се предполага, че това е централната и най-критична част от вашия дата център), но също така ви предоставя приятен интерфейс за създаване на конфигурация.
Инженерите в този проект вместо YAML, за постигане на същите цели, използват Excel за конфигуриране на ACI. В използването на Excel, разбира се, има предимства:
- вашият NIP в един файл,
- красиви таблици, на които е приятно да се гледа от клиента,
- можете да използвате някои инструменти на Excel.
Но има един недостатък, и той, според мен, преобладава над предимствата. Контролът на промените и координирането на работата на екипа става много по-сложно.
ACY — това е на практика прилагане на същите подходи, които използвах за 3rd party, за конфигуриране на ACI.
Източник: habr.com
