Kako prevzeti nadzor nad svojo omrežno infrastrukturo. Četrto poglavje. Avtomatizacija. Predloge

Ta članek je šesti v seriji »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

Ker sem pustil več tem za sabo, sem se odločil začeti novo poglavje.

Na varnost se bom vrnil malo kasneje. Tukaj želim razpravljati o enem preprostem, a učinkovitem pristopu, za katerega sem prepričan, da je lahko v takšni ali drugačni obliki koristen mnogim. To je bolj kratka zgodba o tem, kako lahko avtomatizacija spremeni življenje inženirja. Govorili bomo o uporabi šablon. Na koncu je seznam mojih projektov, kjer si lahko ogledate, kako vse tukaj opisano deluje.

DevOps za omrežje

Ustvarjanje konfiguracije s skriptom, uporaba GIT za nadzor sprememb v infrastrukturi IT, »nalaganje« na daljavo - te ideje so na prvem mestu, ko pomislite na tehnično izvedbo pristopa DevOps. Prednosti so očitne. Toda na žalost obstajajo tudi slabosti.

Ko so pred več kot 5 leti naši razvijalci prišli do nas, omrežnikov, s temi predlogi, nismo bili navdušeni.

Moram reči, da smo podedovali precej pestro mrežo, sestavljeno iz opreme približno 10 različnih proizvajalcev. Nekatere stvari je bilo priročno konfigurirati prek našega najljubšega klinika, pri drugih pa smo raje uporabili GUI. Poleg tega nas je dolgo delo na "živi" opremi naučilo nadzora v realnem času. Na primer, ko delam spremembe, se počutim veliko bolj udobno delati neposredno prek cli. Tako lahko hitro vidim, da je šlo kaj narobe, in razveljavim spremembe. Vse to je bilo v nekem nasprotju z njihovimi predstavami.

Pojavljajo se tudi druga vprašanja, na primer, ali se lahko vmesnik nekoliko spreminja od različice do različice programske opreme. To bo sčasoma povzročilo, da bo vaš skript ustvaril napačno "config". Proizvodnje ne bi rad uporabljal za “utekanje”.

Ali pa, kako razumeti, da so bili konfiguracijski ukazi uporabljeni pravilno in kaj storiti v primeru napake?

Nočem reči, da so vsa ta vprašanja nerešljiva. Če samo rečemo »A«, je verjetno smiselno reči tudi »B«, in če želite uporabiti iste postopke za nadzor sprememb kot pri razvoju, potem morate poleg produkcije imeti razvojna in uprizoritvena okolja. Potem je ta pristop videti popoln. Toda koliko bo to stalo?

Toda obstaja ena situacija, ko so slabosti praktično izničene in ostanejo le prednosti. Govorim o oblikovalskem delu.

Projekt

Zadnji dve leti sodelujem pri projektu izgradnje podatkovnega centra za velikega ponudnika. V tem projektu sem odgovoren za F5 in Palo Alto. Z vidika Cisca je to "oprema tretjih oseb".

Zame osebno obstajata dve različni fazi tega projekta.

Prva faza

Prvo leto sem bil neskončno zaposlen, delal sem ponoči in ob vikendih. Nisem mogel dvigniti glave. Pritisk vodstva in stranke je bil močan in stalen. V stalni rutini nisem mogel niti poskusiti optimizirati procesa. Ni šlo samo in ne toliko za konfiguracijo opreme kot za pripravo projektne dokumentacije.

Začeli so se prvi testi in presenečen bi bil, koliko majhnih napak in netočnosti je bilo narejenih. Seveda je vse delovalo, vendar je manjkala črka v imenu, manjkala je vrstica v ukazu ... Testi so šli in trajali, jaz pa sem bil že v nenehni vsakodnevni borbi z napakami, testi in dokumentacijo. .

To je trajalo eno leto. Projekt, kolikor razumem, ni bil lahek za vse, vendar je sčasoma naročnik postajal vedno bolj zadovoljen, kar je omogočilo najem dodatnih inženirjev, ki so lahko sami prevzeli del rutine.

Zdaj bi lahko malo pogledali okoli sebe.
In to je bil začetek druge etape.

Druga stopnja

Odločil sem se za avtomatizacijo postopka.

Kar sem razumel iz takratne komunikacije z razvijalci (in moramo priznati, imeli smo močno ekipo), je, da ima besedilni format, čeprav na prvi pogled deluje kot nekaj iz sveta operacijskega sistema DOS, številko dragocenih lastnosti.
Tako bo na primer besedilna oblika uporabna, če želite v celoti izkoristiti GIT in vse njegove izpeljanke. In hotel sem.

No, zdi se, da lahko preprosto shranite konfiguracijo ali seznam ukazov, vendar je spreminjanje precej neprijetno. Poleg tega je med načrtovanjem še ena pomembna naloga. Imeti morate dokumentacijo, ki opisuje vašo zasnovo kot celoto (načrt na nizki ravni) in posebno izvedbo (načrt za izvedbo omrežja). In v tem primeru je uporaba šablon videti kot zelo primerna možnost.

Torej, pri uporabi YAML in Jinja2 datoteka YAML s konfiguracijskimi parametri, kot so naslovi IP, številke BGP AS, ... popolnoma izpolnjuje vlogo NIP, medtem ko predloge Jinja2 vključujejo sintakso, ki ustreza dizajnu, to pomeni, da je v bistvu odraz LLD.

Učenje YAML in Jinja2 je trajalo dva dni. Nekaj ​​dobrih primerov je dovolj, da razumemo, kako to deluje. Nato sta trajala približno dva tedna, da smo ustvarili vse predloge, ki so ustrezale našemu dizajnu: en teden za Palo Alto in še en teden za F5. Vse to je bilo objavljeno na korporativnem githabu.

Zdaj je postopek spreminjanja izgledal takole:

  • spremenil datoteko YAML
  • ustvaril konfiguracijsko datoteko z uporabo predloge (Jinja2)
  • shranjeno v oddaljenem repozitoriju
  • naložil ustvarjeno konfiguracijo v opremo
  • Videl sem napako
  • spremenil datoteko YAML ali predlogo Jinja2
  • ustvaril konfiguracijsko datoteko z uporabo predloge (Jinja2)
  • ...

Jasno je, da je bilo sprva veliko časa porabljenega za urejanje, po tednu ali dveh pa je to postalo redkost.

Dober preizkus in priložnost za odpravljanje napak v vsem je bila naročnikova želja po spremembi konvencije o poimenovanju. Tisti, ki so delali s F5, razumejo pikantnost situacije. Ampak zame je bilo vse zelo preprosto. Spremenil sem imena v datoteki YAML, izbrisal celotno konfiguracijo iz opreme, ustvaril novo in jo naložil. Vse, vključno s popravki napak, je trajalo 4 dni: dva dni za vsako tehnologijo. Po tem sem bil pripravljen na naslednjo fazo, in sicer ustvarjanje podatkovnih centrov DEV in Staging.

Dev in Staging

Uprizoritev dejansko popolnoma posnema produkcijo. Dev je močno okrnjena kopija, zgrajena predvsem na virtualni strojni opremi. Idealna situacija za nov pristop. Če ločim čas, ki sem ga porabil od celotnega procesa, potem mislim, da delo ni trajalo več kot 2 tedna. Glavni čas je čakanje na drugo stran in skupno iskanje težav. Izvedba tretje stranke je ostala skoraj neopažena pri drugih. Bil je celo čas, da se nekaj naučim in napišem par člankov na Habréju :)

Če povzamemo

Torej, kaj imam na koncu?

  • Vse, kar moram storiti, da spremenim konfiguracijo, je spremeniti preprosto, jasno strukturirano datoteko YAML s konfiguracijskimi parametri. Nikoli ne spreminjam skripta python in zelo redko (samo če je napaka) spremenim Jinja2 heatlate
  • Z vidika dokumentacije je to skoraj idealna situacija. Spremenite dokumentacijo (datoteke YAML služijo kot NIP) in naložite to konfiguracijo v opremo. Tako je vaša dokumentacija vedno posodobljena

Vse to je privedlo do dejstva, da

  • stopnja napak je padla na skoraj 0
  • 90 odstotkov rutine je izginilo
  • hitrost izvajanja se je znatno povečala

PLAČAJ, F5Y, ACY

Rekel sem, da je nekaj primerov dovolj, da razumemo, kako deluje.
Tukaj je kratka (in seveda spremenjena) verzija tega, kar je nastalo med mojim delom.

PAY = razporeditev Palo Alto od Yaml = Palo Alto iz Yamla
F5Y = razporeditev F5 iz Yaml = F5 iz Yaml (kmalu na voljo)
ACY = razporeditev ACjaz sem iz Yaml = F5 iz Yaml

Dodal bom nekaj besed o ACY (ne zamenjujte z ACI).

Tisti, ki so delali z ACI, vedo, da tega čudeža (in to v dobrem smislu) zagotovo niso ustvarili omrežniki :). Pozabite na vse, kar ste vedeli o omrežju – ne bo vam koristilo!
Malo pretirano, vendar približno izraža občutek, ki ga zadnja 3 leta neprestano doživljam pri delu z ACI.

In v tem primeru ACY ni le priložnost za izgradnjo procesa nadzora sprememb (kar je v primeru ACI še posebej pomembno, ker naj bi bil osrednji in najbolj kritičen del vašega podatkovnega centra), ampak vam daje tudi uporabniku prijazen vmesnik za ustvarjanje konfiguracije.

Inženirji na tem projektu uporabljajo Excel za konfiguracijo ACI namesto YAML za popolnoma iste namene. Seveda obstajajo prednosti uporabe Excela:

  • vaš NIP v eni datoteki
  • lepi napisi, ki so stranki prijetni na pogled
  • lahko uporabite nekaj orodij excel

Je pa en minus in po mojem mnenju odtehta prednosti. Obvladovanje sprememb in usklajevanje timskega dela postane veliko težje.

ACY je pravzaprav aplikacija istih pristopov, ki sem jih uporabil za tretje osebe za konfiguracijo ACI.

Vir: www.habr.com

Dodaj komentar