Ky artikull është i gjashti në serinë "Si të merrni kontrollin e infrastrukturës së rrjetit tuaj". Përmbajtja e të gjithë artikujve në seri dhe lidhjet mund të gjenden .
Duke lënë pas disa tema, vendosa të nis një kapitull të ri.
Do të kthehem pak më vonë në siguri. Këtu dua të diskutoj një qasje të thjeshtë por efektive, e cila jam i sigurt se, në një formë ose në një tjetër, mund të jetë e dobishme për shumë njerëz. Kjo është më shumë një histori e shkurtër se si automatizimi mund të ndryshojë jetën e një inxhinieri. Ne do të flasim për përdorimin e shablloneve. Në fund ka një listë të projekteve të mia ku mund të shihni se si funksionon gjithçka e përshkruar këtu.
DevOps për rrjetin
Krijimi i një konfigurimi me një skript, përdorimi i GIT për të kontrolluar ndryshimet në infrastrukturën e TI-së, "ngarkimi" në distancë - këto ide vijnë së pari kur mendoni për zbatimin teknik të qasjes DevOps. Përparësitë janë të dukshme. Por, për fat të keq, ka edhe disavantazhe.
Kur më shumë se 5 vjet më parë, zhvilluesit tanë erdhën tek ne, rrjetistët, me këto propozime, ne nuk ishim të kënaqur.
Më duhet të them se ne trashëguam një rrjet mjaft të larmishëm, i përbërë nga pajisje nga rreth 10 shitës të ndryshëm. Ishte i përshtatshëm për të konfiguruar disa gjëra përmes klipit tonë të preferuar, por në të tjera ne preferuam të përdorim GUI-në. Për më tepër, puna e gjatë në pajisjet "live" na ka mësuar të kontrollojmë në kohë reale. Për shembull, kur bëj ndryshime, ndihem shumë më rehat duke punuar drejtpërdrejt përmes klipit. Në këtë mënyrë unë mund të shoh shpejt se diçka shkoi keq dhe të kthej ndryshimet. E gjithë kjo ishte në njëfarë kontradikte me idetë e tyre.
Gjithashtu lindin pyetje të tjera, për shembull, ndërfaqja mund të ndryshojë pak nga versioni në version i softuerit. Kjo përfundimisht do të bëjë që skripti juaj të krijojë "konfigurimin" e gabuar. Nuk do të doja të përdorja prodhimin për "vrapim".
Ose, si të kuptojmë që komandat e konfigurimit janë zbatuar saktë dhe çfarë të bëjmë në rast gabimi?
Nuk dua të them se të gjitha këto çështje janë të pazgjidhshme. Thjesht duke thënë "A" ndoshta ka kuptim të thuash gjithashtu "B" dhe nëse dëshiron të përdorësh të njëjtat procese për kontrollin e ndryshimit si në zhvillim, atëherë duhet të kesh mjedise të zhvillimit dhe të skenës përveç prodhimit. Atëherë kjo qasje duket e plotë. Por sa do të kushtojë?
Por ekziston një situatë kur disavantazhet praktikisht rrafshohen dhe mbeten vetëm avantazhet. E kam fjalën për projektimin.
Projekt
Për dy vitet e fundit kam marrë pjesë në një projekt për të ndërtuar një qendër të dhënash për një ofrues të madh. Unë jam përgjegjës për F5 dhe Palo Alto në këtë projekt. Nga këndvështrimi i Cisco-s, kjo është "pajisje e palës së tretë".
Për mua personalisht, ka dy faza të dallueshme në këtë projekt.
Faza e parë
Vitin e parë kam qenë pafundësisht i zënë, kam punuar netë dhe fundjavë. Nuk mund ta ngrija kokën. Presioni nga menaxhmenti dhe klienti ishte i fortë dhe i vazhdueshëm. Në një rutinë të vazhdueshme, as që mund të përpiqesha të optimizoja procesin. Nuk ishte vetëm dhe jo aq konfigurimi i pajisjeve sa përgatitja e dokumentacionit të projektimit.
Testet e para kanë filluar dhe do të habitesha se sa gabime dhe pasaktësi të vogla u bënë. Sigurisht, gjithçka funksionoi, por emri mungonte një germë, komanda i mungonte një rresht... Testet vazhdonin e vazhdonin dhe unë tashmë isha në një luftë të vazhdueshme, të përditshme me gabimet, testet dhe dokumentacionin. .
Kjo vazhdoi për një vit. Projekti, me sa kuptoj unë, nuk ishte i lehtë për të gjithë, por gradualisht klienti bëhej gjithnjë e më i kënaqur, dhe kjo bëri të mundur punësimin e inxhinierëve shtesë që ishin në gjendje të merrnin vetë një pjesë të rutinës.
Tani mund të shikonim pak përreth.
Dhe ky ishte fillimi i fazës së dytë.
Faza e dytë
Vendosa të automatizoj procesin.
Ajo që kuptova nga komunikimi im me zhvilluesit në atë kohë (dhe duhet të bëjmë haraç, kishim një ekip të fortë) është se formati i tekstit, megjithëse në pamje të parë duket si diçka nga bota e sistemit operativ DOS, ka një numër të pronave të vlefshme.
Kështu, për shembull, formati i tekstit do të jetë i dobishëm nëse dëshironi të përfitoni plotësisht nga GIT dhe të gjitha derivatet e tij. Dhe doja.
Epo, duket se thjesht mund të ruani një konfigurim ose një listë komandash, por bërja e ndryshimeve është mjaft e papërshtatshme. Përveç kësaj, ekziston një detyrë tjetër e rëndësishme gjatë projektimit. Ju duhet të keni dokumentacion që përshkruan dizajnin tuaj në tërësi (Dizajni i nivelit të ulët) dhe zbatimi specifik (plani i zbatimit të rrjetit). Dhe në këtë rast, përdorimi i shablloneve duket si një opsion shumë i përshtatshëm.
Pra, kur përdorni YAML dhe Jinja2, një skedar YAML me parametra konfigurimi si adresat IP, numrat BGP AS, ... përmbush në mënyrë të përsosur rolin e NIP, ndërsa shabllonet Jinja2 përfshijnë sintaksë që korrespondon me dizajnin, domethënë është në thelb një reflektimi i LLD.
U deshën dy ditë për të mësuar YAML dhe Jinja2. Mjaftojnë disa shembuj të mirë për të kuptuar se si funksionon kjo. Më pas u deshën rreth dy javë për të krijuar të gjitha shabllonet që përputheshin me dizajnin tonë: një javë për Palo Alto dhe një javë tjetër për F5. E gjithë kjo u postua në githab të korporatës.
Tani procesi i ndryshimit dukej kështu:
- ndryshoi skedarin YAML
- krijoi një skedar konfigurimi duke përdorur një shabllon (Jinja2)
- ruajtur në një depo të largët
- ngarkoi konfigurimin e krijuar në pajisje
- Pashë një gabim
- ndryshoi skedarin YAML ose shabllonin Jinja2
- krijoi një skedar konfigurimi duke përdorur një shabllon (Jinja2)
- ...
Është e qartë se në fillim u shpenzua shumë kohë për redaktime, por pas një ose dy javësh kjo u bë një gjë e rrallë.
Një provë dhe mundësi e mirë për të korrigjuar gjithçka ishte dëshira e klientit për të ndryshuar konventën e emërtimit. Ata që kanë punuar me F5 e kuptojnë pikante e situatës. Por për mua gjithçka ishte shumë e thjeshtë. Ndryshova emrat në skedarin YAML, fshiva të gjithë konfigurimin nga pajisja, gjenerova një të ri dhe e ngarkova. Gjithçka, duke përfshirë rregullimet e gabimeve, zgjati 4 ditë: dy ditë për secilën teknologji. Pas kësaj, isha gati për fazën tjetër, përkatësisht krijimin e qendrave të të dhënave DEV dhe Staging.
Dev dhe Skenimi
Inskenimi në fakt përsërit plotësisht prodhimin. Dev është një kopje shumë e zhveshur e ndërtuar kryesisht në pajisje virtuale. Një situatë ideale për një qasje të re. Nëse e veçoj kohën që kalova nga procesi i përgjithshëm, atëherë mendoj se puna zgjati jo më shumë se 2 javë. Koha kryesore është të presësh palën tjetër dhe të kërkojmë së bashku problemet. Zbatimi i palës së tretë kaloi pothuajse pa u vënë re nga të tjerët. Kishte madje kohë për të mësuar diçka dhe për të shkruar disa artikuj në Habré :)
për të përmbledhur
Pra, çfarë kam në fund?
- Gjithçka që duhet të bëj për të ndryshuar konfigurimin është të ndryshoj një skedar YAML të thjeshtë, të strukturuar qartë me parametrat e konfigurimit. Unë kurrë nuk e ndryshoj skriptin e python dhe shumë rrallë (vetëm nëse ka një gabim) e ndryshoj ngrohjen Jinja2
- Nga pikëpamja e dokumentacionit, kjo është një situatë pothuajse ideale. Ju ndryshoni dokumentacionin (skedarët YAML shërbejnë si NIP) dhe ngarkoni këtë konfigurim në pajisje. Në këtë mënyrë dokumentacioni juaj është gjithmonë i përditësuar
E gjithë kjo çoi në faktin se
- shkalla e gabimit ka rënë në pothuajse 0
- 90 për qind e rutinës është zhdukur
- shpejtësia e zbatimit është rritur ndjeshëm
PAY, F5Y, ACY
Thashë se mjaftojnë disa shembuj për të kuptuar se si funksionon.
Këtu është një version i shkurtër (dhe sigurisht i modifikuar) i asaj që u krijua gjatë punës sime.
= vendosje Palo Alto nga Yaml = Palo Alto nga Yaml
= vendosje F5 nga Yaml = F5 nga Yaml (së shpejti)
= vendosje ACune nga Yaml = F5 nga Yjr
Unë do të shtoj disa fjalë për ACY (të mos ngatërrohet me ACI).
Ata që kanë punuar me ACI e dinë që kjo mrekulli (dhe në një mënyrë të mirë gjithashtu) definitivisht nuk është krijuar nga rrjetistët :). Harrojeni gjithçka që dinit për rrjetin - nuk do të jetë e dobishme për ju!
Është pak e ekzagjeruar, por përafërsisht përçon ndjesinë që kam përjetuar vazhdimisht, për 3 vitet e fundit, duke punuar me ACI.
Dhe në këtë rast, ACY nuk është vetëm një mundësi për të ndërtuar një proces kontrolli ndryshimi (i cili është veçanërisht i rëndësishëm në rastin e ACI, sepse supozohet të jetë pjesa qendrore dhe më kritike e qendrës suaj të të dhënave), por gjithashtu ju jep një ndërfaqe miqësore për përdoruesit për krijimin e konfigurimit.
Inxhinierët në këtë projekt përdorin Excel për të konfiguruar ACI në vend të YAML për të njëjtat qëllime. Ka, natyrisht, avantazhe për të përdorur Excel:
- NIP-i juaj në një skedar
- shenja të bukura që janë të këndshme për t'i parë klienti
- mund të përdorni disa mjete excel
Por ka një minus, dhe për mendimin tim i tejkalon të mirat. Kontrolli i ndryshimeve dhe koordinimi i punës ekipore bëhet shumë më i vështirë.
ACY është në fakt një aplikim i të njëjtave qasje që kam përdorur për palën e tretë për të konfiguruar ACI.
Burimi: www.habr.com