Ky artikull është i gjashti në ciklin e artikujve "Si të kontrolloni infrastrukturën tuaj rrjetë." Përmbajtja e të gjithë artikujve të ciklit dhe lidhjet e tyre mund të gjenden .
Dhe, pasi lanë disa tema pas, vendosa të filloj një kapitull të ri.
Do të kthehem te siguria më vonë. Këtu dua të diskutoj një qasje të thjeshtë, por efektive, që jam i sigurt se do t'i shërbejë shumëkujt në një formë apo një tjetër. Ky është më shumë një histori e shkurtër se si automatizimi mund të ndryshojë jetën e një inxhinieri. Do të flasim për përdorimin e template-ve. Në fund do të gjeni 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 konfigurimeve me skripta, 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 mendojmĂ« pĂ«r implementimin teknik tĂ« qasjes DevOps. Avantazhet janĂ« tĂ« dukshme. Por, fatkeqĂ«sisht, ka edhe disavantazhe.
Kur mbi 5 vjet më parë, zhvilluesit tanë erdhën te ne, te specialistët e rrjetit, me këto propozime, ne nuk ishim të entuziazmuar.
Duhet thënë se trashëguam një rrjet mjaft të ngjashëm, i përbërë nga pajisje të rreth 10 prodhuesve të ndryshëm. Disa ishin të lehta për t'u konfiguruar përmes CLI-së sonë të preferuar, por diku preferonim të përdornim GUI. Për më tepër, puna e gjatë me pajisje "në jet" na kishte mësuar për kontrollin në kohë reale. Për shembull, kur bëj ndryshime, ndihem shumë më komod duke punuar direkt përmes CLI-së. Kështu, mund të shoh shpejt nëse diçka ka shkuar në mënyrë të gabuar dhe ta "rikthej" ndryshimin. E gjithë kjo ishte disi në kontradiktë me idetë e tyre.
Këtu lindin edhe pyetje të tjera, për shembull, ndërmjet versioneve të softuerit, ndërfaqja mund të ndryshojë pak. Kjo, në fund të fundit, do të çojë në faktin se skripti juaj do të krijojë një "konfig" të gabuar. Nuk do të doja të përdorja prodhimin për "testim".
Ose, si të kuptohet që komandat konfiguruese janë aplikuar saktë dhe çfarë të bësh në rast të gabimit?
Nuk dëshiroj të them se të gjitha këto pyetje janë të pazgjidhshme. 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, duhet të kesh përveç production edhe dev dhe staging mjedise. Atëherë ky qasje duket e plotë. Por sa do të kushtojë kjo?
Por ka një situatë kur disavantazhet praktikisht neutralizohen dhe mbeten vetëm avantazhet. Po flas për punët projektore.
Projekt
Dy vitet e fundit kam marrë pjesë në një projekt për ndërtimin e një data center-i për një ofrues të madh shërbimi. Unë jam përgjegjës në këtë projekt për F5 dhe Palo Alto. Nga këndvështrimi i Cisco-s, kjo është "3rd party equipment".
Personalish, për mua kanë dy faza të qarta në këtë projekt.
Faza e parë
Viti i parë isha pa fund i zënë, punoja natën dhe në fundjavë. Nuk mund të ngrija kokën. Të presionit nga menaxhimi dhe klienti ishte e fortë dhe e vazhdueshme. Në rutinën e përhershme nuk mund të përpiqesha të optimizoja procesin. Kjo nuk ishte vetëm dhe as aq shumë konfigurimi i pajisjeve, por përgatitja e dokumentacionit të projektit.
Këtu filluan provat e para, dhe isha i habitur nga numri i vogël i gabimeve dhe pasaktësive që ishin bërë. Sigurisht, gjithçka funksiononte, por aty mungonte një shkronjë në emrin, këtu mungonte një rresht në komandë⊠Provat vazhduan dhe vazhduan, dhe unë isha në një luftë të vazhdueshme, çdo ditë me gabime, prova dhe dokumentacion.
Kështu vazhdoi për një vit. Projekti, sa e kuptoj, nuk ishte i lehtë për askënd, por gradualisht klienti filloi të bëhej gjithnjë e më i kënaqur, dhe kjo krijoi mundësinë për të punësuar inxhinierë të tjerë, të cilët mund të merrnin pjesë nga rutina.
Tani mund të shikoja pak rreth meje.
Dhe kjo ishte fillimi i fazës së dytë.
Faza e Dytë
Decidova ta automatizoj procesin.
Ajo që kuptova nga bisedat e atyre kohëve me zhvilluesit (dhe duhet ta pranoj, kishim një ekip të fortë) është se formati tekstual, ndonëse duket si diçka nga bota e sistemit operativ DOS, ka disa veçori të çmuara.
Për shembull, formati tekstual do të ishte i dobishëm nëse dëshiron të shfrytëzosh plotësisht përfitimet e GIT dhe të gjitha derivatet e tij. Dhe unë e doja këtë.
Duket sikur mund të ruajmë vetëm konfigurimin ose një listë komandash, por ndryshimet janë mjaft të pakëndshme për t'u bërë. Për më tepër, gjatë projektimit, ka një detyrë tjetër të rëndësishme. Ju duhet të keni dokumentacionin që përshkruan dizajnin tuaj në mënyrë të përgjithshme (Dizajni në Nivel të Ulët) dhe implementimin specifik (Plani i Implementimit të Rrjetit). Në këtë rast, përdorimi i shablloneve duket si një opsion shumë i përshtatshëm.
Kështu, kur përdoren YAML dhe Jinja2, skedari YAML me parametrat e konfigurimit, si adresat IP, numrat BGP AS, etj., luan perfekt rolin e NIP, ndërsa shabllonet Jinja2 përfshijnë sintaksën përkatëse të dizajnit, pra në thelb janë reflektim i LLD.
Disa ditë më janë dashur për të mësuar gjuhët YAML dhe Jinja2. Për të kuptuar se si funksionon, mjaftojnë disa shembuj të mirë. Më pas, rreth dy javë më janë dashur për të krijuar të gjitha shabllonet përkatëse me dizajnin tonë: një javë për Palo Alto dhe një javë tjetër për F5. Të gjitha këto janë ngarkuar në GitHub-in e korporatës.
Tani procesi i ndryshimeve dukej si më poshtë:
- kam ndryshuar skedarin YAML
- kam krijuar skedarin e konfigurimit me anë të shabllonit (Jinja2)
- e kam ruajtur në repozitorin e largët
- ngarko konfigurimin e krijuar në pajisje
- pashë një gabim
- ndryshova skedarin YAML ose template-in Jinja2
- kam krijuar skedarin e konfigurimit me anë të shabllonit (Jinja2)
- âŠ
E kuptoj, se në fillim shpenzohej shumë kohë për ndryshime, por pas një ose dy javësh kjo bëhej më shumë një përjashtim.
Një verifikim i mirë dhe mundësi për të gjithë për të rregulluar doli nga dëshira e klientit për të ndryshuar konventën e emra. Kush ka punuar me F5 e kupton delikatesën e situatës. Por për mua gjithçka ishte mjaft e thjeshtë. Ndryshova emrat në skedarin YAML, fshiva të gjithë konfigurimin nga pajisja, gjenerova një të re dhe e ngarkoha. Për të gjitha, duke përfshirë rregullimet e gabimeve, u deshën 4 ditë: dy ditë për secilën teknologji. Pas kësaj isha gati për fazën tjetër, që ishte krijimi i qendrave të të dhënave DEV dhe Staging.
Dev dhe Staging
Staging nĂ« fakt e riprodhon nĂ« mĂ«nyrĂ« tĂ« plotĂ« prodhimin. Dev - njĂ« kopje e fortĂ« e reduktuar dhe e ndĂ«rtuar kryesisht mbi pajisje virtuale. NjĂ« situatĂ« e ideale pĂ«r tĂ« aplikuar njĂ« qasje tĂ« re. NĂ«se veçoj kohĂ«n qĂ« kam shpenzuar nga procesi i pĂ«rgjithshĂ«m, mendoj se puna mori jo mĂ« shumĂ« se 2 javĂ«. Koha kryesore Ă«shtĂ« koha e pritjes sĂ« palĂ«s tjetĂ«r dhe kĂ«rkimi i pĂ«rbashkĂ«t i problemeve. Implementimi i 3rd party kaloi pothuajse pa u vĂ«nĂ« re nga tĂ« tjerĂ«t. Madje pati kohĂ« pĂ«r tĂ« mĂ«suar disa gjĂ«ra dhe pĂ«r tĂ« shkruar disa artikuj nĂ« Habr đ
Le të bëjmë një përmbledhje
Pra, çfarë më mbetet në përfundim?
- Të gjitha që më nevojiten për të ndryshuar konfigurimin - të ndryshoj një skedar YAML të thjeshtë, të strukturuar qartë me parametrat e konfigurimit. Unë kurrë nuk e ndryshoj skriptin python dhe shumë rrallë (vetëm nëse ka ndonjë gabim) ndryshoj template Jinja2
- Nga perspektiva e dokumentacionit, rezulton një situatë pothuajse ideale. Ju ndryshoni dokumentacionin (skedarët YAML luajnë rolin e NIP) dhe ngarkoni këtë konfigurim në pajisje. Në këtë mënyrë dokumentacioni juaj është gjithmonë aktual
E gjitha kjo çoi në atë që
- pjesa e gabimeve ra pothuajse në 0
- u hoqën 90 përqind e rutinës
- shpejtësia e implementimit ka rritur shumëfish
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 shkurtuar (dhe sigurisht i modifikuar) i asaj që u krijua gjatë punës sime.
= implementim Palo Alto nga Yaml = Palo Alto nga Yaml
= implementim F5 from Yaml = F5 from Yaml (shumë shpejt do të jetë)
= implementim ACi nga Yaml = F5 from Yaml
Do të shtoj disa fjalë rreth ACY (mos e ngatërroni me ACI).
Ata qĂ« kanĂ« punuar me ACI e dinĂ« se ky mrekulli (dhe nĂ« njĂ« kuptim tĂ« mirĂ« gjithashtu) Ă«shtĂ« krijuar sigurisht jo nga profesionistĂ« tĂ« rrjetit :). Harroje gjithçka qĂ« ke ditur pĂ«r rrjetin â kjo nuk do tĂ« tĂ« ndihmojĂ«!
Pak e ekzagjeruar, por përafërsisht përcjell ndjenjën që kam ndjerë vazhdimisht për 3 vjet, duke punuar me ACI.
Dhe në këtë rast, ACY nuk është vetëm një mundësi për të ndërtuar procesin e kontrollit të ndryshimeve (çka është veçanërisht e rëndësishme për ACI, sepse supozohet se është pjesa qendrore dhe më kritike e qendrës tuaj të të dhënave), por gjithashtu ju ofron një ndërfaqe miqësore për krijimin e konfigurimeve.
Ingjinierë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 avantazhet e tij:
- NIP-i juaj në një skedar
- tabelat e bukura, të cilat janë këndshme për t'u parë nga klienti
- mund të përdorni disa mjete të Excel-it
Por ka një disavantazh, dhe sipas mendimit tim, ai e tejkalon avantazhet. Të kontrollosh ndryshimet dhe të koordosh punën e ekipit bëhet shumë më e vështirë.
ACY është në thelb përdorimi i qasjeve të njëjta që kam përdorur për 3rd party, për konfiguruar ACI.
Burimi: habr.com
