Гэты артыкул з'яўляецца шосты ў цыкле артыкулаў "Як узяць сеткавую інфраструктуру пад свой кантроль". Змест усіх артыкулаў цыклу і спасылкі можна знайсці .
Пакінуўшы некалькі тэм ззаду, я вырашыў усё ж пачаць новы раздзел.
Да бяспекі вярнуся крыху пазней. Тут я жадаю абгаварыць адзін просты, але эфектыўны падыход, які, упэўнены, у тым ці іншым выглядзе, можа спатрэбіцца шматлікім. Гэта хутчэй кароткая гісторыя аб тым, як аўтаматызацыя можа змяніць жыццё інжынера. Размова пойдзе аб выкарыстанні темлейтаў. У канцы прыводзіцца спіс маіх праектаў, дзе можна паглядзець, як усё апісанае тут працуе.
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
Я казаў, што некалькі прыкладаў дастаткова, каб зразумець, як гэта працуе.
Тут кароткая (і вядома перайначаная) версія таго, што было створана падчас маёй працы.
= deployment Palo Alto from Yaml = Palo Alto ад Yaml
= deployment F5 ад Yaml = F5 ад Yaml (хутка будзе)
= deployment ACя ад Yaml = F5 ад Yмалодшы
Дадам некалькі слоў аб ACY (не блытаць з ACI).
Тыя, хто працаваў з ACI ведаюць, што гэты цуд (і ў добрым сэнсе таксама) быў створаны дакладна не сеткавікамі :). Забудзьцеся пра ўсё, што вы ведалі аб сетцы - гэта вам не спатрэбіцца!
Трохі ўвыдатнена, але прыблізна перадае тое адчуванне, якое я ўвесь час, вось ужо 3 гады, зведваю, працуючы з ACI.
І ў дадзеным выпадку ACY – гэта не толькі магчымасць выбудаваць працэс кантролю змен (што асабліва важна ў выпадку ACI, таму што мяркуецца, што гэта цэнтральная і найболей крытычная частка вашага дата-цэнтра), але таксама дае вам дружалюбны інтэрфейс для стварэння канфігурацыі.
Інжынеры ў дадзеным праекце для канфігуравання ACI замест YAML для дакладнасці тых жа мэт выкарыстоўваюць Excel. У выкарыстанні Excel, вядома, ёсць плюсы:
- ваш NIP у адным файле
- прыгожыя таблічкі, на якія прыемна глядзець кліенту
- вы можаце выкарыстоўваць некаторыя інструменты Excel
Але ёсць адзін мінус, і ён на мой погляд перавешвае плюсы. Кантраляваць змены і ўзгадняць працу каманды становіцца нашмат складаней.
ACY – гэта фактычна ўжыванне тых жа падыходаў, што я выкарыстаў для 3rd party, для канфігуравання ACI.
Крыніца: habr.com