Dit artikel is it sechsde yn 'e searje "Hoe kinne jo kontrôle nimme oer jo netwurkynfrastruktuer." De ynhâld fan alle artikels yn 'e searje en keppelings is te finen .
Neidat ik ferskate ûnderwerpen efterlitten hie, besleat ik in nij haadstik te begjinnen.
Ik kom efkes letter werom op feiligens. Hjir wol ik ien ienfâldige, mar effektive oanpak besprekke, dy't ik wis bin, yn ien of oare foarm, kin nuttich wêze foar in protte. Dit is mear in koart ferhaal oer hoe't automatisearring it libben fan in yngenieur kin feroarje. Wy sille prate oer it brûken fan sjabloanen. Oan 'e ein is der in list fan myn projekten wêr't jo kinne sjen hoe't alles hjir beskreaun wurket.
DevOps foar it netwurk
In konfiguraasje oanmeitsje mei in skript, gebrûk fan GIT om wizigingen oan 'e IT-ynfrastruktuer te kontrolearjen, "uploaden" op ôfstân - dizze ideeën komme earst as jo tinke oer de technyske ymplemintaasje fan 'e DevOps-oanpak. De foardielen binne fanselssprekkend. Mar, spitigernôch, der binne ek neidielen.
Doe't mear dan 5 jier lyn ús ûntwikkelders nei ús kamen, de netwurkers, mei dizze foarstellen, wiene wy net bliid.
Ik moat sizze dat wy in nochal motley netwurk erfden, besteande út apparatuer fan sawat 10 ferskillende leveransiers. It wie handich om guon dingen te konfigurearjen fia ús favorite cli, mar yn oaren brûkten wy leaver de GUI. Dêrneist hat lang wurk oan "live" apparatuer ús leard om real-time kontrôle. Bygelyks, by it meitsjen fan feroarings, fiel ik my folle nofliker om direkt troch de cli te wurkjen. Op dizze manier kin ik gau sjen dat der wat mis gie en de feroarings weromdraaie. Dit alles wie yn guon tsjinspraak mei har ideeën.
Oare fragen komme ek op, bygelyks de ynterface kin wat feroarje fan ferzje nei ferzje fan 'e software. Dit sil úteinlik soargje dat jo skript de ferkearde "konfiguraasje" oanmeitsje. Ik wol de produksje net brûke foar "ynrinne".
Of hoe te begripen dat de konfiguraasjekommando's korrekt waarden tapast en wat te dwaan yn gefal fan in flater?
Ik wol net sizze dat al dizze problemen ûnoplosber binne. Gewoan sizze "A" makket wierskynlik ek sin om "B" te sizzen, en as jo deselde prosessen wolle brûke foar feroaringskontrôle as yn ûntwikkeling, dan moatte jo njonken produksje ek dev- en staging-omjouwings hawwe. Dan sjocht dizze oanpak kompleet. Mar hoefolle sil it kostje?
Mar d'r is ien situaasje as de neidielen praktysk gelyk wurde, en allinich de foardielen bliuwe. Ik haw it oer ûntwerpwurk.
It projekt
De lêste twa jier die ik mei oan in projekt om in datasintrum foar in grutte provider te bouwen. Ik bin ferantwurdlik foar F5 en Palo Alto yn dit projekt. Ut it eachpunt fan Cisco is dit "apparatuer fan tredden".
Foar my persoanlik binne d'r twa ûnderskate stadia yn dit projekt.
Earste faze
It earste jier wie ik einleas drok, ik wurke nachts en wykeinen. Ik koe de holle net ophelje. De druk fan it management en de klant wie sterk en kontinu. Yn in konstante routine koe ik net iens besykje it proses te optimalisearjen. It wie net allinich en net sasear de konfiguraasje fan apparatuer as de tarieding fan ûntwerpdokumintaasje.
De earste tests binne begûn, en ik soe fernuverje hoefolle lytse flaters en unakkuracies waarden makke. Alles wurke fansels, mar der mist in letter yn de namme, der mist in rigel yn it kommando... De tests gongen troch en ik siet al yn in konstante, deistige striid mei flaters, tests en dokumintaasje .
Dit gie in jier troch. It projekt wie foar safier ik begryp net foar elkenien maklik, mar stadichoan waard de opdrachtjouwer mear en mear tefreden, en dat makke it mooglik om ekstra yngenieurs oan te nimmen dy't sels in part fan de routine nimme koenen.
No koene wy efkes om ús hinne sjen.
En dit wie it begjin fan 'e twadde etappe.
Stage twa
Ik besleat it proses te automatisearjen.
Wat ik begriep út myn kommunikaasje mei de ûntwikkelders op dat stuit (en wy moatte hulde betelje, wy hiene in sterk team) is dat it tekstformaat, hoewol op it earste each liket as wat út 'e wrâld fan it DOS-bestjoeringssysteem, in nûmer hat fan weardefolle eigenskippen.
Sa, bygelyks, it tekstformaat sil nuttich wêze as jo folslein foardielje wolle fan GIT en al syn derivatives. En ik woe.
No, it liket derop dat jo gewoan in konfiguraasje of in list mei kommando's kinne opslaan, mar feroaringen meitsje is frijwat ûngemaklik. Derneist is d'r in oare wichtige taak by ûntwerp. Jo moatte dokumintaasje hawwe dy't jo ûntwerp as gehiel beskriuwt (ûntwerp op leech nivo) en spesifike ymplemintaasje (netwurkimplementaasjeplan). En yn dit gefal liket it gebrûk fan sjabloanen in heul geskikte opsje.
Dat, by it brûken fan YAML en Jinja2, in YAML-bestân mei konfiguraasjeparameters lykas IP-adressen, BGP AS-nûmers, ... foltôget de rol fan NIP perfekt, wylst Jinja2-sjabloanen syntaksis befetsje dy't oerienkomme mei it ûntwerp, dat is, it is yn wêzen in refleksje fan LLD.
It duorre twa dagen om YAML en Jinja2 te learen. In pear goede foarbylden binne genôch om te begripen hoe't dit wurket. Dêrnei duorre it sawat twa wiken om alle sjabloanen te meitsjen dy't oerienkomme mei ús ûntwerp: in wike foar Palo Alto en in wike foar F5. Dit alles waard pleatst op corporate githab.
No seach it feroaringsproses der sa út:
- feroare de YAML triem
- in konfiguraasjetriem makke mei in sjabloan (Jinja2)
- opslein yn in remote repository
- uploade de oanmakke konfiguraasje nei de apparatuer
- Ik seach in flater
- feroare it YAML-bestân as Jinja2-sjabloan
- in konfiguraasjetriem makke mei in sjabloan (Jinja2)
- ...
Dúdlik is dat der earst in protte tiid oan bewurkings bestege is, mar nei in wike as twa waard dat nochal in seldsumheid.
In goede test en kâns om alles te debuggen wie de winsk fan 'e kliïnt om de nammekonvinsje te feroarjen. Dejingen dy't wurke mei F5 begripe de piquancy fan 'e situaasje. Mar foar my wie it allegear frij simpel. Ik feroare de nammen yn it YAML-bestân, wiske de hiele konfiguraasje fan 'e apparatuer, generearre in nije en upload it. Alles, ynklusyf bug fixes, naam 4 dagen: twa dagen foar elke technology. Dêrnei wie ik klear foar de folgjende etappe, nammentlik de skepping fan DEV en Staging datacenters.
Dev en Staging
Staging replicates eins folslein produksje. Dev is in swier stripped-down kopy boud foaral op firtuele hardware. In ideale situaasje foar in nije oanpak. As ik isolearje de tiid dy't ik trochbrocht fan it totale proses, dan tink ik dat it wurk duorre net mear as 2 wiken. De wichtichste tiid is wachtsjen op 'e oare kant en sykjen nei problemen tegearre. De ymplemintaasje fan 3rd party gie hast ûngemurken troch oaren. Der wie sels tiid om wat te learen en in pear artikels oer Habré te skriuwen :)
Litte wy it fermelde
Dus, wat haw ik yn 'e ûnderste rigel?
- Alles wat ik moat dwaan om de konfiguraasje te feroarjen is in ienfâldige, dúdlik strukturearre YAML-bestân te feroarjen mei konfiguraasjeparameters. Ik feroarje it python-skript noait en heul selden (allinich as d'r in flater is) feroarje ik de Jinja2 heatlate
- Ut in dokumintaasje eachpunt is dit in hast ideale situaasje. Jo feroarje de dokumintaasje (YAML triemmen tsjinje as NIP) en upload dizze konfiguraasje oan de apparatuer. Op dizze manier is jo dokumintaasje altyd bywurke
Dit alles late ta it feit dat
- it flaterrate is sakke nei hast 0
- 90 prosint fan de routine is fuort
- de snelheid fan útfiering is signifikant tanommen
PAY, F5Y, ACY
Ik sei dat in pear foarbylden genôch binne om te begripen hoe't it wurket.
Hjir is in koarte (en fansels oanpast) ferzje fan wat makke is tidens myn wurk.
= ynset Phallo Alto fan Yaml = Palo Alto út Yaml
= ynset F5 fan Yaml = F5 fan Yaml (komt gau)
= ynset ACik fan Yaml = F5 fan Yaml
Ik sil in pear wurden tafoegje oer ACY (net te betiizjen mei ACI).
Wa't mei ACI wurke hat, wit dat dit wûnder (en op in goede manier ek) perfoarst net makke is troch netwurkers :). Ferjit alles wat jo wisten oer it netwurk - it sil jo net nuttich wêze!
It is in bytsje oerdreaun, mar it bringt rûchwei it gefoel oer dat ik de lêste 3 jier konstant mei ACI haw belibbe.
En yn dit gefal is ACY net allinich in kâns om in feroaringskontrôleproses te bouwen (dat is benammen wichtich yn it gefal fan ACI, om't it it sintrale en meast krityske diel fan jo datasintrum moat wêze), mar jout jo ek in brûkerfreonlike ynterface foar it meitsjen fan konfiguraasje.
De yngenieurs op dit projekt brûke Excel om ACI te konfigurearjen ynstee fan YAML foar krekt deselde doelen. D'r binne fansels foardielen foar it brûken fan Excel:
- jo NIP yn ien triem
- moaie buorden dy't foar de klant noflik binne om nei te sjen
- jo kinne guon Excel-ark brûke
Mar der is ien minus, en nei myn miening is it grutter as de foardielen. Feroarings kontrolearje en teamwurk koördinearje wurdt folle dreger.
ACY is eins in tapassing fan deselde oanpak dy't ik brûkte foar de tredde partij om ACI te konfigurearjen.
Boarne: www.habr.com