Ky kjo artikull është e gjashta në ciklin e artikujve "Si ta merrni nën kontroll infrastrukturën rrjetore". Mund të gjeni përmbajtjen e të gjithë artikujve të ciklit dhe lidhjet. .
Duke lënë disa tema pas, vendosa të filloj një kapitull të ri.
Do të kthehem te siguria pak më vonë. Këtu dua të diskutoj një qasje të thjeshtë, por efektive, e cila, sigurisht, në një formë apo në një tjetër, mund të jetë e dobishme për shumë. Kjo është më shumë një histori e shkurtër se si automatizimi mund të ndryshojë jetën e inxhinierit. Do të flas për përdorimin e templatëve. 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 konfiguracionit me skript, pĂ«rdorimi i GIT pĂ«r kontrollin e ndryshimeve nĂ« infrastrukturĂ«n IT, ngarkimi i largĂ«t â kĂ«to ide vijnĂ« menjĂ«herĂ« nĂ« mendje kur mendoni pĂ«r realizimin teknik tĂ« qasjes DevOps. Avantazhet janĂ« tĂ« dukshme. Por fatkeqĂ«sisht, ka edhe disavantazhe.
Kur më shumë se 5 vjet më parë, zhvilluesit tanë erdhën te ne, tek rrjetarët, me këto propozime, ne nuk ishim shumë entuziastë.
Duhet të them se trashëgova një rrjet të ngjashëm, që përbëhej nga pajisje të rreth 10 ofruesve të ndryshëm. Disa gjëra ishin të lehta për t'u konfiguruar përmes CLI-së tonë të preferuar, por ndonjëherë ne preferonim të përdornim GUI-në. Për më tepër, puna e gjatë me pajisje "në jetë" na ka mësuar për kontrollin në kohë reale. Unë, për shembull, duke bërë ndryshime, ndjehem shumë më rehat duke punuar drejtpërdrejt përmes CLI. Kështu mund të shoh shpejt nëse diçka shkoi keq dhe ta "kthej" ndryshimin. Të gjitha këto ishin në njëfarë mënyre në kontradiktë me idetë e tyre.
Shfaqen edhe pyetje të tjera, për shembull, nga versioni në version të softuerit, ndërfaqja mund të ndryshojë pak. Kjo, përfundimisht, do të çojë në faktin që skripti juaj do të krijojë një "konfig" të gabuar. Nuk do të doja të përdorja prodhimin për "testimin".
Ose, si ta kuptoj se komandat e konfigurimit u aplikuan saktë dhe çfarë të bëj në rast gabimi?
Nuk dua të them se të gjitha këto pyetje janë të pazgjidhshme. Thjesht duke thënë "A", ndoshta është e arsyeshme të thuash edhe "B" dhe, nëse dëshiron të përdorësh të njëjtat procese për kontrollin e ndryshimeve si në zhvillim, atëherë duhet të kesh përveç prodhimit, gjithashtu mjedise dev dhe staging. Atëherë, ky qasje duket e plotë. Por sa do të kushtojë?
Por një situatë ku disavantazhet pothuajse anulohet, dhe mbeten vetëm avantazhet. Po flas për punët projektimore.
Projekti
Dy vitet e fundit, kam marrë pjesë në një projekt për ndërtimin e një qendre të të dhënave për një provajder të madh. Unë jam përgjegjës për F5 dhe Palo Alto në këtë projekt. Nga këndvështrimi i Cisco, kjo është '3rd party equipment'.
Personalish për mua, ka dy faza të spikatura në këtë projekt.
Faza e parë
Viti i parë kam qenë pafundësisht i angazhuar, kam punuar natën dhe gjatë fundjavave. Nuk isha në gjendje të ngrihem kokën. Presioni nga menaxhmenti dhe klienti ishte i fortë dhe i vazhdueshëm. Në rutinën e përhershme nuk mund të përpiqesha as të optimizoja procesin. Nuk ishte vetëm konfigurimi i pajisjeve, por edhe përgatitja e dokumentacionit projektues.
Këtu filluan testet e para, dhe isha i befasuar nga sa shumë gabime dhe pasaktësi ishin bërë. Sigurisht, gjithçka funksiononte, por aty mungonte një shkronjë në emrin, këtu mungonte një rresht në komandë... Testet vazhdonin pa ndalur, dhe unë isha në një luftë të përhershme, të përditshme me gabimet, testet dhe dokumentacionin.
Kështu vazhdoi për një vit. Projekti, sa kuptoj, ishte i vështirë për të gjithë, por gradualisht klienti filloi të ishte gjithnjë e më i kënaqur, dhe kjo dha mundësinë për të marrë inxhinierë të tjerë që mund të merrnin një pjesë të rutinës mbi vete.
Tani ishte kohë për të filluar të shihja pak rreth meje.
Dhe kjo ishte fillimi i fazës së dytë.
Faza e dytë
Vendosa të automatizoj procesin.
ĂfarĂ« kuptova nga bisedat e asaj kohe me zhvilluesit (dhe duhen kujtuar, kishim njĂ« ekip tĂ« fortĂ«), Ă«shtĂ« se formati tekstual, edhe pse duket nĂ« shikim tĂ« parĂ« si diçka nga bota e sistemit operativ DOS, ka njĂ« sĂ«rĂ« pronash tĂ« vlefshme.
Pra, për shembull, formati tekstual do të jetë i dobishëm nëse dëshironi të shfrytëzoni plotsisht përfitimet e GIT dhe të gjithë pasardhësve të tij. Dhe unë e doja këtë.
Mirë, duket se mund të ruajmë thjesht konfigurimin ose listën e komandave, por të bësh ndryshime është mjaft e bezdisshme. Përveç kësaj, gjatë projektimit ka një detyrë të rëndësishme tjetër. Duhet të keni dokumentacion që përshkruan dizajnin tuaj në tërësi (Low Level Design) dhe implementimin specifik (Network Implementation Plan). Dhe në këtë rast, përdorimi i shablloneve duket të jetë një variant shumë i përshtatshëm.
Pra përdorimin e YAML dhe Jinja2, skedari YAML me parametrat e konfigurimit, si adresat IP, numrat BGP AS,⊠luan shkëlqyeshëm rolin e NIP, ndërsa shablonët Jinja2 përfshijnë sintaksën përkatëse të dizajnit, domethënë përbëjnë në thelb një pasqyrë të LLD.
Studimi i gjuhĂ«ve YAML dhe Jinja2 zgjati dy ditĂ«. PĂ«r tĂ« kuptuar se si funksionon mjaftojnĂ« disa shembuj tĂ« mirĂ«. Pastaj, rreth dy javĂ« kaluan pĂ«r krijimin e tĂ« gjithĂ« shabloneve qĂ« pĂ«rputhen me dizajnin tonĂ«: njĂ« javĂ« pĂ«r Palo Alto dhe njĂ« javĂ« tjetĂ«r â pĂ«r F5. TĂ« gjitha kjo u publikua nĂ« GitHub-in tonĂ« tĂ« korporatĂ«s.
Tani procesi i ndryshimeve dukej si në vijim:
- ndryshova skedarin YAML
- krijova skedarin e konfigurimit me ndihmën e shabllonit (Jinja2)
- e ruajta në depo të largët
- ngrita konfigurimin e krijuar në pajisje
- pashë një gabim
- ndryshova skedarin YAML ose shabllonin Jinja2
- krijova skedarin e konfigurimit me ndihmën e shabllonit (Jinja2)
- âŠ
ĂshtĂ« e qartĂ« se nĂ« fillim kaloheshin shumĂ« kohĂ« pĂ«r rregullime, por pas njĂ« jave tĂ« dy, kjo tashmĂ« ishte mĂ« shumĂ« njĂ« rastisht.
Një verifikim i mirë dhe mundësi për të gjitha për të zbuluar mangësitë ishte dëshira e klientit për të ndryshuar konventën e emrave. Kush ka punuar me F5 e kupton ndjeshmërinë e situatës. Por për mua e gjitha ishte mjaft e thjeshtë. Ndryshova emrat në skedarin YAML, fshiva të gjithë konfigurimin nga pajisja, gjenerova të re dhe ngrita. Për gjithçka, duke përfshirë rregullimet e gabimeve, kalova 4 ditë: dy ditë për çdo teknologji. Pas kësaj isha gati për fazën e ardhshme, konkretisht krijimin e qendrave të të dhënave DEV dhe Staging.
Dev dhe Staging
Staging nĂ« fakt e riprodhon plotĂ«sisht prodhimin. Dev â njĂ« kopje shumĂ« e reduktuar dhe kryesisht e ndĂ«rtuar mbi pajisje virtuale. NjĂ« situatĂ« ideale pĂ«r tĂ« aplikuar qasjen e re. NĂ«se do tĂ« veçoj kohĂ«n qĂ« kam shpenzuar, do tĂ« mendoj se punĂ«t, mendoj, nuk zgjatĂ«n mĂ« shumĂ« se 2 javĂ«. Koha kryesore â Ă«shtĂ« koha e pritjes nga ana tjetĂ«r, dhe kĂ«rkime tĂ« pĂ«rbashkĂ«ta pĂ«r problemet. Implementimi i 3rd party kaloi pothuajse pa u vĂ«nĂ« re nga tĂ« tjerĂ«t. Madje u shfaq edhe koha pĂ«r tĂ« mĂ«suar diçka dhe pĂ«r tĂ« shkruar disa artikuj nĂ« Habra đ
Le të përmbledhim
Pra, çfarë kam në përfundim?
- gjithçka qĂ« mĂ« nevojitet pĂ«r tĂ« ndryshuar konfigurimin â Ă«shtĂ« tĂ« ndryshoj njĂ« skedar YAML tĂ« thjeshtĂ«, tĂ« strukturuar mirĂ« me parametrat e konfigurimit. UnĂ« kurrĂ« nuk e ndryshoj skenarin python dhe shumĂ« rrallĂ« (vetĂ«m nĂ«se ka njĂ« gabim) e ndryshoj shabllonin Jinja2.
- nga pikëpamja e dokumentacionit, situata është pothuajse ideale. Ju ndryshoni dokumentacionin (skedarët YAML shërbejnë si NIP) dhe e ngarkoni këtë konfiguracion në pajisje. Kështu, dokumentacioni juaj është gjithmonë i azhurnuar.
Të gjitha këto çuan në faktin se
- pjesa e gabimeve ra pothuajse në 0.
- 90 përqind e rutinës është eliminuar.
- shpejtësia e zbatimit u rrit shumë.
PAY, F5Y, ACY.
Kam thënë se disa shembuj janë të mjaftueshëm për të kuptuar se si funksionon.
Këtu është një version i shkurtër (dhe natyrisht i modifikuar) i asaj që është krijuar gjatë punës sime.
= zbatimi. Palo. Alto nga. Yaml = Palo Alto nga Yaml.
= zbatimi. F5 from Yaml =. F5 from Yaml (po vjen së shpejti).
= zbatimi. ACi nga. Yaml =. F5 from Yaml.
Do të shtoj disa fjalë rreth ACY (mos e ngatërroni me ACI).
Atyre qĂ« kanĂ« punuar me ACI u bĂ«het e qartĂ« se ky mrekulli (dhe nĂ« kuptimin e mirĂ« gjithashtu) nuk Ă«shtĂ« krijuar saktĂ«sisht nga specialistĂ« tĂ« rrjetit :). Harrojini gjithçka qĂ« e dini pĂ«r rrjetin â kjo nuk do t'ju ndihmojĂ«!
Pak e ekzagjeruar, por përafërsisht përcjell ndjenjën që unë përjetoj vazhdimisht, tashmë për 3 vjet, duke punuar me ACI.
Dhe në këtë rast, ACY është jo vetëm një mundësi për të ndërtuar procesin e kontrollit të ndryshimeve (çka është veçanërisht e rëndësishme në rastin e ACI, sepse supozohet se është pjesa qendrore dhe më kritike e qendrës së të dhënave tuaj), por gjithashtu ju ofron një ndërfaqe miqësore për krijimin e konfiguracionit.
Inxhinierët në këtë projekt për konfigurimin e ACI përdorin Excel në vend të YAML për të arritur të njëjtat qëllime. Përdorimi i Excel ka sigurisht disa avantazhe:
- NIP-i juaj në një skedar.
- tabela të bukura, për të cilat është kënaqësi të shikoni klientët.
- mund të përdorni disa vegla të Excel.
Por ka një disavantazh, dhe sipas mendimit tim, ai e tejkalon avantazhin. Të kontrollosh ndryshimet dhe të koordinosh punën e ekipit bëhet shumë më e vështirë.
ACY është në thelb aplikimi i të njëjtave qasje që kam përdorur për 3rd party, për konfigurimin e ACI.
Burimi: habr.com
