Тази статия е шестата от поредицата „Как да поемете контрола над вашата мрежова инфраструктура“. Можете да намерите съдържанието на всички статии от поредицата и връзките .
След като изоставих няколко теми, реших да започна нова глава.
Ще се върна към охраната малко по-късно. Тук искам да обсъдя един прост, но ефективен подход, който съм сигурен, че под една или друга форма може да бъде полезен за мнозина. Това е по-скоро кратка история за това как автоматизацията може да промени живота на един инженер. Ще говорим за използването на шаблони. В края има списък с моите проекти, където можете да видите как работи всичко описано тук.
DevOps за мрежата
Създаване на конфигурация със скрипт, използване на GIT за контрол на промените в ИТ инфраструктурата, отдалечено „качване“ - тези идеи идват на първо място, когато мислите за техническото изпълнение на подхода DevOps. Предимствата са очевидни. Но, за съжаление, има и недостатъци.
Когато преди повече от 5 години нашите разработчици дойдоха при нас, мрежовите специалисти, с тези предложения, не бяхме възхитени.
Трябва да кажа, че наследихме доста пъстра мрежа, състояща се от оборудване от около 10 различни доставчици. Беше удобно да конфигурираме някои неща чрез любимия ни cli, но за други предпочитахме да използваме GUI. В допълнение, дългата работа върху „живо“ оборудване ни научи да контролираме в реално време. Например, когато правя промени, се чувствам много по-удобно да работя директно през cli. По този начин мога бързо да видя, че нещо се е объркало и да върна промените назад. Всичко това беше в известно противоречие с техните представи.
Възникват и други въпроси, например интерфейсът може да се променя леко от версия на версия на софтуера. Това в крайна сметка ще накара вашия скрипт да създаде грешна "конфигурация". Не бих искал да използвам продукцията за „разработване“.
Или как да разберете, че командите за конфигуриране са приложени правилно и какво да направите в случай на грешка?
Не искам да кажа, че всички тези проблеми са неразрешими. Самото казване на „А“ вероятно има смисъл да се каже и „Б“ и ако искате да използвате същите процеси за контрол на промените, както при разработката, тогава трябва да имате среди за разработка и етапи в допълнение към производството. Тогава този подход изглежда завършен. Но колко ще струва?
Но има една ситуация, когато недостатъците са практически изравнени и остават само предимствата. Говоря за дизайнерска работа.
Проект
През последните две години участвам в проект за изграждане на център за данни на голям доставчик. Аз отговарям за F5 и Palo Alto в този проект. От гледна точка на Cisco това е „оборудване на трета страна“.
Лично за мен има два различни етапа в този проект.
Първи етап
Първата година бях безкрайно зает, работех през нощта и през уикендите. Не можех да вдигна глава. Натискът от ръководството и клиента беше силен и непрекъснат. В постоянна рутина не можах дори да се опитам да оптимизирам процеса. Не беше само и не толкова конфигурацията на оборудването, колкото подготовката на проектната документация.
Започнаха първите тестове и ще се учудя колко малки грешки и неточности са допуснати. Разбира се, всичко работеше, но имаше липсваща буква в името, имаше липсващ ред в командата... Тестовете продължаваха и продължаваха, а аз вече бях в постоянна, ежедневна борба с грешки, тестове и документация .
Това продължи една година. Проектът, доколкото разбирам, не е бил лесен за всички, но постепенно клиентът става все по-доволен и това дава възможност да се наемат допълнителни инженери, които сами да поемат част от рутината.
Сега можем да се огледаме малко.
И това беше началото на втория етап.
Втори етап
Реших да автоматизирам процеса.
Това, което разбрах от тогавашната ми комуникация с разработчиците (и трябва да отдадем дължимото, имахме силен екип), е, че текстовият формат, въпреки че на пръв поглед изглежда като нещо от света на операционната система DOS, има номер от ценни имоти.
Така например, текстовият формат ще бъде полезен, ако искате да се възползвате напълно от GIT и всички негови производни. И исках.
Е, изглежда, че можете просто да съхранявате конфигурация или списък с команди, но извършването на промени е доста неудобно. Освен това има още една важна задача по време на проектирането. Трябва да имате документация, описваща вашия дизайн като цяло (дизайн на ниско ниво) и конкретно изпълнение (план за внедряване на мрежа). И в този случай използването на шаблони изглежда много подходящ вариант.
Така че, когато използвате YAML и Jinja2, YAML файл с конфигурационни параметри като IP адреси, BGP AS номера, ... перфектно изпълнява ролята на NIP, докато шаблоните Jinja2 включват синтаксис, съответстващ на дизайна, т.е. по същество е отражение на LLD.
Научаването на YAML и Jinja2 отне два дни. Няколко добри примера са достатъчни, за да разберем как работи това. След това отне около две седмици, за да създадем всички шаблони, които отговарят на нашия дизайн: една седмица за Пало Алто и още една седмица за F5. Всичко това беше публикувано в корпоративния githab.
Сега процесът на промяна изглеждаше така:
- промени YAML файла
- създаде конфигурационен файл с помощта на шаблон (Jinja2)
- запазени в отдалечено хранилище
- качи създадената конфигурация в оборудването
- Видях грешка
- промени YAML файла или шаблона Jinja2
- създаде конфигурационен файл с помощта на шаблон (Jinja2)
- ...
Ясно е, че в началото много време беше изразходвано за редакции, но след седмица или две това стана по-скоро рядкост.
Добър тест и възможност за отстраняване на грешки във всичко беше желанието на клиента да промени конвенцията за именуване. Тези, които са работили с F5, разбират пикантността на ситуацията. Но за мен всичко беше съвсем просто. Промених имената в YAML файла, изтрих цялата конфигурация от оборудването, генерирах нова и я качих. Всичко, включително корекциите на грешки, отне 4 дни: по два дни за всяка технология. След това бях готов за следващия етап, а именно създаването на DEV и Staging центрове за данни.
Dev и Staging
Постановката всъщност напълно възпроизвежда постановката. Dev е силно съкратено копие, изградено главно върху виртуален хардуер. Идеална ситуация за нов подход. Ако изолирам времето, което отделих от цялостния процес, то мисля, че работата отне не повече от 2 седмици. Основното време е да чакаме другата страна и да търсим проблемите заедно. Внедряването на трета страна остана почти незабелязано от другите. Дори имаше време да научим нещо и да напишем няколко статии на Хабре :)
За да обобщим
И така, какво имам в долния ред?
- Всичко, което трябва да направя, за да променя конфигурацията, е да променя прост, ясно структуриран YAML файл с конфигурационни параметри. Никога не променям скрипта на Python и много рядко (само ако има грешка) променям Jinja2 heatlate
- От гледна точка на документацията това е почти идеална ситуация. Променяте документацията (YAML файловете служат като NIP) и качвате тази конфигурация в оборудването. По този начин вашата документация е винаги актуална
Всичко това доведе до факта, че
- процентът на грешки е спаднал до почти 0
- 90 процента от рутината е изчезнала
- скоростта на изпълнение се увеличи значително
ПЛАЩАНЕ, F5Y, ACY
Казах, че няколко примера са достатъчни, за да разберем как работи.
Ето кратка (и разбира се модифицирана) версия на това, което беше създадено по време на моята работа.
= разгръщане PALO Alto от Yaml = Пало Алто от Yaml
= разгръщане F5 от Yaml = F5 от Yaml (очаквайте скоро)
= разгръщане ACаз от Yaml = F5 от YJR
Ще добавя няколко думи за ACY (да не се бърка с ACI).
Тези, които са работили с ACI, знаят, че това чудо (и в добрия смисъл) определено не е създадено от мрежовици :). Забравете всичко, което сте знаели за мрежата - няма да ви е от полза!
Малко е преувеличено, но грубо предава усещането, което постоянно изпитвам през последните 3 години, работейки с ACI.
И в този случай ACY е не само възможност за изграждане на процес за контрол на промените (което е особено важно в случая на ACI, тъй като се предполага, че е централната и най-критична част от вашия център за данни), но също така ви дава удобен интерфейс за създаване на конфигурация.
Инженерите на този проект използват Excel за конфигуриране на ACI вместо YAML за точно същите цели. Разбира се, има предимства при използването на Excel:
- вашият NIP в един файл
- красиви табели, приятни за гледане от клиента
- можете да използвате някои инструменти на Excel
Но има един минус и според мен той надхвърля плюсовете. Контролирането на промените и координирането на екипната работа става много по-трудно.
ACY всъщност е приложение на същите подходи, които използвах за трета страна за конфигуриране на ACI.
Източник: www.habr.com