🥇Kuidas võtta oma võrguinfrastruktuur kontrolli alla. Neljas peatükk. Automatiseerimine. Mallid

See artikkel on kuues artikkel seerias "Kuidas võtta võrgu infrastruktuur oma kontrolli alla". Kõigi seeria artiklite sisu ja lingid leiate siit. siit.

Jätkates mitme teema arutamist, otsustasin siiski alustada uut peatükki.

Turvalisuse teemade juurde tulen tagasi veidi hiljem. Siin tahan arutada üht lihtsat, kuid efektiivset lähenemist, mis, olen kindel, võib paljudele mingil moel kasuks tulla. See on pigem lühike lugu sellest, kuidas automatiseerimine võib inseneri elu muuta. Räägime mallide kasutamisest. Lõpus toome välja loendi minu projektidest, kus saab näha, kuidas kõik siin kirjeldatu töötab.

DevOps võrgus

Scriptide abil konfigureerimine, GIT-i kasutamine IT infrastruktuuri muudatuste jälgimiseks, kaug-‘upload’ — need ideed tulevad esimesena meelde, kui mõelda DevOps lähenemise tehnilisele rakendamisele. Plusse on selgelt palju. Kuid, kahjuks, on ka miinuseid.

Kui meie arendajad rohkem kui 5 aastat tagasi nende ettepanekutega meie, võrguinseneride, juurde tulid, ei olnud me vaimustuses.

Peab ütlema, et meile jäi päranduseks üsna kirju võrgustik, koosnes see umbes 10 erineva tootja seadmetest. Osa oli mugav konfigureerida meie lemmik CLI kaudu, kuid mõnes kohas eelistasime kasutada GUI-d. Lisaks sellele on pikka aega töötamine 'otse' seadmetega õpetanud meid reaalajas kontrollima. Mina, näiteks, tunnen end muutusi tehes palju mugavamalt, töötades otse CLI kaudu. Nii näen kiiresti, kui midagi on valesti läinud, ja saan muudatused 'tagasi võtta'. Kõik see sattus veidi vastuollu nende ideedega.

Tekkivad ka teised küsimused, näiteks võib tarkvara versioonide vahel liides veidi muutuda. See toob lõpuks kaasa selle, et teie skript loob vale 'konfiguratsiooni'. Ei tahaks kasutada tootmisrežiimi 'katsetamiseks'.

Kuidas aru saada, et konfiguratsiooni käsud rakendati korrektselt ja mida teha vea korral?

Ma ei taha öelda, et kõik need küsimused on lahendamatud. Lihtsalt öeldes "A" on mõistlik öelda ka "B", ja kui soovite kasutada samu protsesse muudatuste juhtimiseks nagu arenduses, siis tuleb omada lisaks production'ile ka dev ja staging keskkondi. Siis tundub selline lähenemine lõpetatuna. Kuid kui palju see maksma läheb?

Aga on üks olukord, kus miinused on praktiliselt tasakaalust väljas ja jäävad alles ainult plussid. Räägin projektitööst.

Projekt

Viimased kaks aastat olen osalenud andmekeskuse ehitusprojekti suurele teenusepakkujale. Olen selles projektis vastutav F5 ja Palo Alto eest. Cisco vaatevinklist on see "3rd party equipment".

Isiklikult on mul selles projektis kaks selgelt määratletud etappi.

Esimene etapp

Esimesel aastal olin ma lõputult hõivatud, töötasin öösiti ja puhkepäevadel. Ma ei saanud pead tõsta. Surve juhtimise ja tellija poolt oli tugev ja pidev. Pidevas rutiinis ei suutnud ma isegi proovida protsessi optimeerida. See ei olnud mitte ainult seadmete konfigureerimine, vaid ka projektidokumentatsiooni koostamine.

Nüüd algasid esimesed testid ja olin üllatunud, kui palju pisivigu ja ebatäpsusi oli tehtud. Loomulikult töötas kõik, kuid seal puudus täht nimes, siin jäi rida käsust vahele... Testid jätkusid ja jätkusid, ning olin pidevas igapäevases võitluses vigade, testide ja dokumentatsiooniga.

Nii kestis see aasta. Projekt, nii palju kui ma aru saan, ei olnud lihtne kellelegi, kuid aeglaselt sai klient järjest rohkem ja rohkem rahulolevaks, mis andis võimaluse võtta juurde täiendavaid insenere, kes suudaksid osa rutiinist enda kanda võtta.

Nüüd oli võimalik natuke ringi vaadata.
Ja see oli teise etapi algus.

Teine etapp

Otsustasin protsessi automatiseerida.

Mida ma tol hetkel arendajatega suheldes taipasin (ja tuleb tunnustada, et meil oli tugev meeskond), on see, et tekstivorming, ehkki näib esmapilgul olema midagi DOS-i operatsioonisüsteemi maailmast, omab mitmeid väärtuslikke omadusi.
Näiteks on tekstivorming kasulik, kui soovite täielikult ära kasutada GIT-i ja kõiki selle tuletisi. Ja mina tahtsin.

Tundub, et saaks lihtsalt konfiguratsiooni või käskude nimekirja säilitada, kuid muudatuste tegemine on sellega üsna keeruline. Samuti on projekteerimise käigus veel üks oluline ülesanne. Teil peab olema dokumentatsioon, mis kirjeldab teie disaini tervikuna (Low Level Design) ja konkreetset rakendust (Network Implementation Plan). Sel juhul näib mallide kasutamine väga sobiv variant.

Nii, kui kasutada YAML ja Jinja2, täidab YAML-fail, mis sisaldab konfiguratsiooni parameetreid, nagu IP-aadressid, BGP AS-numbrid,… suurepäraselt NIP-i rolli, samas kui Jinja2 mallid sisaldavad disainile vastavat süntaksit, mis on tegelikult LLD peegeldus.

YAML ja Jinja2 keeltesse süvenemine võttis kaks päeva. Et mõista, kuidas see töötab, piisab mõnest heast näitest. Edasi kulus umbes kaks nädalat, et luua kõik mallid, mis vastavad meie disainile: nädal Palo Alto jaoks ja veel nädal F5 jaoks. Kõik see pandi ettevõtte GitHubi.

Nüüd nägi muudatuste protsess välja järgmine:

muutsin YAML-faili
loomine malliga (Jinja2) konfiguratsioonifail
salvestatud kaugreposiitoris
laadisin loodud konfiguratsiooni seadmetesse
nägin viga
muutsin YAML faili või Jinja2 šabloni
loomine malliga (Jinja2) konfiguratsioonifail
…

On selge, et alguses kulus palju aega parandustele, kuid nädala või kahe pärast sai sellest pigem erand.

Hea kontroll ja võimalus kõik korda seada oli kliendi soov muuta nimetamisreegleid. Kes on töötanud F5-ga, see mõistab olukorra keerukust. Kuid minu jaoks oli kõik üsna lihtne. Muutsin nimed YAML failis, eemaldasin kogu konfigureerimise seadmetest, genereerisin uue ja laadisin selle üles. Kõigega, sealhulgas vigade parandamisega, kulus 4 päeva: kaks päeva iga tehnoloogia peale. Pärast seda olin valmis järgmise etapi jaoks, nimelt DEV ja Staging andmekeskuste loomine.

Dev ja Staging

Staging koopia on praktiliselt identne tootmisversiooniga. Dev on tugevalt kärbitud ja peamiselt virtuaalsel seadmel põhinev koopia. Ideaalne olukord uue lähenemisviisi rakendamiseks. Kui arvutada välja, kui palju aega ma üldiselt kulutasin, siis arvan, et tööde teostamiseks kulus mitte rohkem kui kaks nädalat. Peamine aeg on olnud ootamine teise poole pärast ja ühised probleemide otsingud. 3rd party rakendamine toimus peaaegu märkamatult. Lausalt siis, et leidus isegi aega midagi õppida ja paar artiklit Habras kirjutada 🙂

Kokkuvõtteks

Nii, mida ma siis lõpptulemusena sain?

kõik, mis on vajalik minu konfiguratsiooni muutmiseks — lihtsalt muuta selgelt struktureeritud YAML-faili konfiguratsiooni parameetritega. Ma ei muuda kunagi Python skripti ja väga harva (ainult kui esineb viga) muudan Jinja2 шаблoni
dokumeerimise seisukohalt on olukord peaaegu ideaalne. Te muudate dokumentatsiooni (YAML-failid täidavad NIP-i rolli) ja laadite selle konfiguratsiooni riistvarasse. Nii on teie dokumentatsioon alati ajakohane

Kõik see on viinud selleni, et

vigade protsent on langenud praktiliselt nulli
90% rutiinist on kadunud
rakendamise kiirus on mitu korda suurenenud

PAY, F5Y, ACY

Ma rääkisin, et mõned näited on piisavad, et mõista, kuidas see töötab.
Siin on lühike (ja muidugi muudetud) versioon sellest, mida minu tööprotsessis loodud.

PAY = kasutuselevõtt Palo Alto from Yaml = Palo Alto Yamlist
F5Y = kasutuselevõtt F5 from Yaml = F5 from Yaml (varsti tuleb)
ACY = kasutuselevõtt ACi from Yaml = F5 from Yaml

Lisaksin mõned sõnad ACY-st (ära sega ACI-ga).

Need, kes on töötanud ACI-ga, teavad, et see ime (ja heas mõttes) ei olnud kindlasti võrguinimestelt loodud :). Unustage kõik, mida te teadsit - see ei tule kasuks!
Veidi liialdatud, aga see edastab umbkaudu selle tunde, mida ma pidevalt, juba 3 aastat, tunnen, töötades ACI-ga.

Ja antud juhul on ACY mitte ainult võimalus üles ehitada muudatuste jälgimise protsess (mis on eriti oluline ACI korral, kuna eeldatakse, et see on teie andmekeskuse keskne ja kõige kriitilisem osa), vaid see annab teile ka sõbraliku liidese konfiguratsiooni loomiseks.

Selle projekti insenerid kasutavad ACI konfigureerimiseks Exceli, mitte YAML-i, et täpselt samu eesmärke saavutada. Exceli kasutamisel on kindlasti plusse: