Hvernig á að taka stjórn á innviðum netkerfisins. Fjórði kafli. Sjálfvirkni. Sniðmát

Þessi grein er sú sjötta í röðinni „Hvernig á að taka stjórn á netinnviðum þínum. Hægt er að finna innihald allra greina í ritröðinni og tengla hér.

Eftir að hafa skilið eftir nokkur efni ákvað ég að byrja á nýjum kafla.

Ég kem aftur til öryggis aðeins seinna. Hér vil ég ræða eina einfalda en áhrifaríka nálgun, sem ég er viss um, í einni eða annarri mynd, getur nýst mörgum. Þetta er frekar stutt saga um hvernig sjálfvirkni getur breytt lífi verkfræðings. Við munum tala um að nota sniðmát. Í lokin er listi yfir verkefnin mín þar sem þú getur séð hvernig allt sem lýst er hér virkar.

DevOps fyrir netið

Að búa til stillingar með handriti, nota GIT til að stjórna breytingum á upplýsingatækniinnviðum, „hleðsla“ á fjarstýringu - þessar hugmyndir koma fyrst þegar þú hugsar um tæknilega útfærslu DevOps nálgunarinnar. Kostirnir eru augljósir. En því miður eru líka ókostir.

Þegar meira en 5 árum síðan, verktaki okkar komu til okkar, netverjar, með þessar tillögur, vorum við ekki ánægð.

Ég verð að segja að við erfðum frekar brosótt net, sem samanstendur af búnaði frá um 10 mismunandi söluaðilum. Það var þægilegt að stilla suma hluti í gegnum uppáhalds cli okkar, en í öðrum vildum við frekar nota GUI. Að auki hefur löng vinna við „lifandi“ búnað kennt okkur að stjórna í rauntíma. Til dæmis, þegar ég geri breytingar, finnst mér miklu þægilegra að vinna beint í gegnum cli. Þannig get ég fljótt séð að eitthvað fór úrskeiðis og afturkallað breytingarnar. Allt var þetta í einhverri mótsögn við hugmyndir þeirra.

Aðrar spurningar vakna líka, til dæmis gæti viðmótið breyst lítillega frá útgáfu til útgáfu hugbúnaðarins. Þetta mun að lokum valda því að handritið þitt býr til ranga "config". Ég myndi ekki vilja nota framleiðslu til að „hlaupa inn“.

Eða hvernig á að skilja að stillingarskipanirnar voru notaðar á réttan hátt og hvað á að gera ef villur koma upp?

Ég vil ekki segja að öll þessi mál séu óleysanleg. Bara það að segja "A" er líklega skynsamlegt að segja "B" líka, og ef þú vilt nota sömu ferla fyrir breytingastjórnun og í þróun, þá þarftu að hafa þróunar- og sviðsetningarumhverfi til viðbótar við framleiðslu. Þá lítur þessi nálgun út fyrir að vera fullkomin. En hvað mun það kosta?

En það er ein staða þegar ókostirnir eru nánast jafnaðir og aðeins kostirnir eru eftir. Ég er að tala um hönnunarvinnu.

Project

Síðustu tvö ár hef ég tekið þátt í verkefni um að byggja gagnaver fyrir stóra þjónustuaðila. Ég ber ábyrgð á F5 og Palo Alto í þessu verkefni. Frá sjónarhóli Cisco er þetta „þriðju aðila búnaður“.

Fyrir mig persónulega eru tvö aðskilin stig í þessu verkefni.

Fyrsta stigið

Fyrsta árið var ég endalaust upptekinn, ég vann á kvöldin og um helgar. Ég gat ekki lyft höfðinu. Þrýstingur stjórnenda og viðskiptavina var mikill og stöðugur. Í stöðugri rútínu gat ég ekki einu sinni reynt að fínstilla ferlið. Það var ekki aðeins og ekki svo mikið uppsetning búnaðar sem undirbúningur hönnunarskjala.

Fyrstu prófanirnar eru hafnar og það kæmi mér á óvart hversu margar smávillur og ónákvæmni voru gerðar. Auðvitað virkaði allt, en það vantaði staf í nafnið, það vantaði línu í skipunina... Prófin héldu áfram og áfram og ég var þegar í stöðugri, daglegri baráttu við villur, próf og skjöl .

Þetta hélt áfram í eitt ár. Verkefnið var, að því er mér skilst, ekki auðvelt fyrir alla, en smám saman varð viðskiptavinurinn ánægðari og ánægðari og það gerði það að verkum að hægt var að ráða til viðbótar verkfræðinga sem gátu tekið að sér hluta af rútínu sjálfir.

Nú gátum við litið aðeins í kringum okkur.
Og þetta var upphafið á öðrum áfanga.

XNUMX. stigi

Ég ákvað að gera ferlið sjálfvirkt.

Það sem ég skildi af samskiptum mínum við þróunaraðilana á þeim tíma (og við verðum að þakka, við vorum með sterkt lið) er að textasniðið, þó við fyrstu sýn virðist vera eitthvað úr heimi DOS stýrikerfisins, hefur tölu af verðmætum eignum.
Svo, til dæmis, mun textasniðið vera gagnlegt ef þú vilt nýta GIT og allar afleiður þess til fulls. Og ég vildi.

Jæja, það virðist sem þú getur einfaldlega geymt stillingar eða lista yfir skipanir, en það er frekar óþægilegt að gera breytingar. Að auki er annað mikilvægt verkefni við hönnun. Þú ættir að hafa skjöl sem lýsa hönnun þinni í heild sinni (Low Level Design) og sértækri útfærslu (Network Implementation Plan). Og í þessu tilviki lítur notkun sniðmáta út eins og mjög hentugur valkostur.

Svo, þegar YAML og Jinja2 eru notuð, uppfyllir YAML skrá með stillingarbreytum eins og IP tölum, BGP AS tölum, ... fullkomlega hlutverki NIP, en Jinja2 sniðmát innihalda setningafræði sem samsvarar hönnuninni, það er í rauninni spegilmynd LLD.

Það tók tvo daga að læra YAML og Jinja2. Nokkur góð dæmi nægja til að skilja hvernig þetta virkar. Síðan tók það um tvær vikur að búa til öll sniðmátin sem passa við hönnunina okkar: viku fyrir Palo Alto og aðra viku fyrir F5. Allt þetta var sett á corporate githab.

Nú leit breytingaferlið svona út:

• breytti YAML skránni
• búið til stillingarskrá með sniðmáti (Jinja2)
• vistað í fjarlægri geymslu
• hlóð upp stofnuðu uppsetningu í búnaðinn
• Ég sá villu
• breytti YAML skránni eða Jinja2 sniðmátinu
• búið til stillingarskrá með sniðmáti (Jinja2)
• ...

Greinilegt er að í fyrstu fór mikill tími í klippingar en eftir viku eða tvær varð þetta frekar sjaldgæft.

Gott próf og tækifæri til að kemba allt var vilji viðskiptavinarins til að breyta nafnavenjunni. Þeir sem unnu með F5 skilja hvað ástandið er skrítið. En fyrir mér var þetta allt frekar einfalt. Ég breytti nöfnunum í YAML skránni, eyddi allri stillingunni úr búnaðinum, bjó til nýja og hlóð því upp. Allt, þar á meðal villuleiðréttingar, tók 4 daga: tvo daga fyrir hverja tækni. Eftir það var ég tilbúinn fyrir næsta stig, nefnilega stofnun DEV og Staging gagnavera.

Dev og Staging

Sviðsetning endurtekur í raun framleiðslu algjörlega. Dev er mjög niðurrifið eintak byggt aðallega á sýndarvélbúnaði. Tilvalin staða fyrir nýja nálgun. Ef ég einangra tímann sem ég eyddi frá heildarferlinu, þá held ég að vinnan hafi ekki tekið meira en 2 vikur. Aðaltíminn er að bíða eftir hinni hliðinni og leita að vandamálum saman. Innleiðing þriðja aðila fór nánast framhjá öðrum. Það gafst meira að segja tími til að læra eitthvað og skrifa nokkrar greinar um Habré :)

Samantekt

Svo, hvað hef ég í botninum?

• Allt sem ég þarf að gera til að breyta stillingunum er að breyta einfaldri, skýrt uppbyggðri YAML skrá með stillingarbreytum. Ég breyti aldrei python scriptinu og mjög sjaldan (aðeins ef það er villa) breyti ég Jinja2 heatlate
• Frá sjónarhóli skjala er þetta nánast kjöraðstaða. Þú breytir skjölunum (YAML skrár þjóna sem NIP) og hleður upp þessari uppsetningu á búnaðinn. Þannig eru skjölin þín alltaf uppfærð

Allt þetta leiddi til þess að

• villuhlutfallið er komið niður í næstum 0
• 90 prósent af rútínu er horfin
• hraði framkvæmdar hefur aukist verulega

PAY, F5Y, ACY

Ég sagði að nokkur dæmi væru nóg til að skilja hvernig það virkar.
Hér er stutt (og auðvitað breytt) útgáfa af því sem varð til við vinnu mína.

BORGA = dreifing Palo Alto frá Yaml = Palo Alto frá Yaml
F5Y = dreifing F5 frá Yaml = F5 frá Yaml (kemur bráðum)
ACY = dreifing ACég frá Yaml = F5 frá Yaml

Ég bæti við nokkrum orðum um ACY (ekki að rugla saman við ACI).

Þeir sem hafa unnið með ACI vita að þetta kraftaverk (og á góðan hátt líka) var örugglega ekki búið til af netverjum :). Gleymdu öllu sem þú vissir um netið - það mun ekki nýtast þér!
Það er svolítið ýkt, en það miðlar í grófum dráttum þá tilfinningu að ég hafi stöðugt verið að upplifa, síðastliðin 3 ár, að vinna með ACI.

Og í þessu tilfelli er ACY ekki aðeins tækifæri til að byggja upp breytingastjórnunarferli (sem er sérstaklega mikilvægt þegar um ACI er að ræða, vegna þess að það á að vera miðlægi og mikilvægasti hluti gagnaversins), heldur gefur þér einnig notendavænt viðmót til að búa til stillingar.

Verkfræðingarnir í þessu verkefni nota Excel til að stilla ACI í stað YAML í nákvæmlega sömu tilgangi. Það eru auðvitað kostir við að nota Excel:

• NIP þinn í einni skrá
• falleg skilti sem er notalegt fyrir viðskiptavininn að skoða
• þú getur notað nokkur excel verkfæri

En það er einn mínus og að mínu mati vegur hann þyngra en kostir. Að stjórna breytingum og samræma teymisvinnu verður mun erfiðara.

ACY er í raun forrit af sömu aðferðum og ég notaði fyrir þriðja aðila til að stilla ACI.

Heimild: www.habr.com