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

See artikkel on kuues osa artiklite tsüklist "Kuidas võtta oma võrguinfrastruktuur kontrolli alla". Kõigi artiklite sisu ja lingid leiate siit. siin.

Kuna jätsin mitu teemat seljataha, otsustasin siiski alustada uut peatükki.

Turvalisuse juurde tulen hiljem tagasi. Siin tahan arutada ühte lihtsat, kuid tõhusat lähenemist, mis kindlasti, mingil moel, võib paljusid aidata. See on pigem lühike lugu sellest, kuidas automatiseerimine võib inseneri elu muuta. Räägime mallide kasutamisest. Lõpus on loetelu minu projektidest, kus saab näha, kuidas kõik siingi kirjeldatu töötab.

DevOps võrgus

Konfiguratsiooni loomine skripti abil, GITi kasutamine IT-infrastruktuuri muudatuste jälgimiseks, kaugüleslaadimine — need ideed tulevad esimesena meelde, kui mõelda DevOpsi lähenemise tehnilisele rakendamisele. Eelised on selged. Kuid kahjuks on ka miinuseid.

Kui rohkem kui 5 aastat tagasi tulid meie arendajad meie, võrgutöötajate juurde nende ettepanekutega, polnud me vaimustuses.

Pean ütlema, et päranduseks jäi meile üsna kirju võrk, mis koosneb seadmetest umbes 10 erinevalt tootjalt. Mõned asjad oli mugav konfigureerida meie lemmik CLI kaudu, kuid mõnes kohas eelistasime kasutada GUI-d. Lisaks harjutas pikk töö "elava" seadmega reaalajas kontrollimisega. Mina näiteks tunnen muudatusi tehes end palju mugavamalt, töötades otseselt CLI kaudu. Nii saan kiiresti näha, et midagi on valesti läinud ja muuta muudatused tagasi. Kõik see oli mingis vastuolus nende ideedega.

Tekkivad ka muud küsimused, näiteks võib tarkvara versioonist versiooni interfäär natuke erineda. See toob lõpuks kaasa selle, et teie skript loob vale "konfigu". Ei sooviks kasutada tootmisvõrku "katsetamiseks".

Või kuidas mõista, et konfiguratsiooni käskudega said õigesti rakendatud ja mida teha vigade 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 kontrollimiseks, nagu arenduses, siis on lisaks tootmis- ka arendus- ja testkeskkond vajalikud. Siis tundub see lähenemine tervikuna lõpetatuna. Aga kui palju see maksma läheb?

Kuid on üks olukord, kus miinused praktiliselt kaovad ning jäävad ainult plussid. Räägin projekti töödest.

Projekt

Viimased kaks aastat olen osalenud suurandmekeskuse projekti loomisel ühe suure teenusepakkuja jaoks. Ma vastutan selles projektis F5 ja Palo Alto eest. Cisco vaatenurgast on see "kolmanda osapoole seadmed".

Isiklikult on minu jaoks selles projektis kaks eristuvat etappi.

Esimene etapp

Esimesel aastal olin ma pidevalt hõivatud, töötasin öösiti ja nädalavahetustel. Ma ei saanud pead tõsta. Juhtkonna ja tellija poolt olid pinged suured ja pidevad. Igapäevases rutiinis ei suutnud ma isegi proovida protsessi optimeerida. See polnud ainult seadmete konfigureerimine, vaid ka projektdokumentatsiooni koostamine.

Siis algasid esimesed testid ja olin üllatunud, kui palju väikesi vigu ja ebatäpsusi oli tehtud. Loomulikult töötas kõik, aga seal puudus täht nimes, siin puudus rida käskudes... Testid jätkusid ja jätkusid, ning ma olin pidevas, igapäevases võitluses vigade, testide ja dokumentatsiooniga.

Nii kestis see aasta. Projekt, nii palju kui ma aru sain, ei olnud kõigile kerge, kuid järk-järgult hakkas klient üha rohkem ja rohkem rahule jääma, ja see andis võimaluse võtta juurde täiendavaid insenere, kes suudaksid osa rutiinist enda peale võtta.

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

Teine etapp

Otsustasin automatiseerida protsessi.

Mida ma toona arendajatega suheldes (ja tuleb tunnustada, et meil oli tugev meeskond) mõistsin, oli see, et tekstivorming, kuigi näib esmapilgul midagi DOS-i 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.

Kuid tundub, et konfiguratsiooni või käskude loetelu lihtsalt hoidmine on vaid pool töödest, kuna muudatuste tegemine on ebamugav. Lisaks tuleb projekteerimise käigus silmas pidada veel üks oluline ülesanne. Teil peab olema dokumentatsioon, mis kirjeldab teie disaini tervikuna (Low Level Design) ja konkreetset rakendust (Network Implementation Plan). Sellisel juhul tunduvad mallid väga sobiva valikuna.

Nii, kasutades YAML-i ja Jinja2-t, täidab YAML-fail, mis sisaldab konfiguratsiooni parameetreid, nagu IP-aadressid ja BGP AS numbrid, suurepäraselt NIP-i rolli, samas kui Jinja2 mallid sisaldavad disainiga seotud süntaksit, olles seega nagu lauad LLD peegeldus.

YAML-i ja Jinja2 õppimiseks kulus kaks päeva. Selle toimimise mõistmiseks piisab mõnest heast näitest. Edasi kulus umbes kahe nädala jagu aega, et luua meie disainile vastavad mallid: nädal Palo Alto jaoks ja veel nädal F5 jaoks. Kõik see pandi ettevõtte githabi.

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

• muutsin YAML-faili
• loomiseks kasutasin mallide (Jinja2) konfiguratsioonifaili
• salvestasin kaugarhi
• laadisin loodud konfiguratsiooni seadmetesse
• nägin viga
• muutsin YAML-faili või Jinja2 malli
• loomiseks kasutasin mallide (Jinja2) konfiguratsioonifaili
• …

On selge, et alguses kulus palju aega muudatustele, kuid nädala või kahe pärast muutus see pigem haruldaseks.

Hea testimine ja võimalus kõike siluda tuli kliendi soovist naming conventionit muuta. Need, kes on F5-ga töötanud, mõistavad olukorra tõsidust. Kuid minu jaoks oli kõik üsna lihtne. Muutsin YAML-failis nimed, kustutasin seadmete kogu konfiguratsiooni, genereerisin uue ja laadisin selle üles. Kõik see koos vigade parandamisega võttis aega 4 päeva: kaks päeva iga tehnoloogia jaoks. Pärast seda olin valmis järgmise etapi jaoks, nimelt DEV ja Staging andmekeskuste loomiseks.

Dev ja Staging

Staging korduma kippuv ehtne tootmisprotsessile. Dev on tugevalt kärbitud ja põhineb peamiselt virtuaalsel seadmel. Täiuslik olukord uue lähenemise rakendamiseks. Kui eraldada kogu protsessis minu kulutatud aeg, siis usun, et tööd võtsid aega mitte rohkem kui 2 nädalat. Peamine aeg on ooteaeg teiselt poolt ja probleemide ühisotsingud. 3. osapoole rakendamine toimus ümbritsevate jaoks peaaegu märkamatult. Leidsin isegi aega midagi õppida ja paar artiklit Habrisse kirjutada 🙂

Teeme kokkuvõtte

Nii et, mis on minu kokkuvõte?

• kõik, mida mul on vaja конфигурация muutmiseks — muuta lihtsat, selgelt struktureeritud YAML faili конфигурация параметритena. Ma ei muuda kunagi python skripti ja väga harva (ainult kui esineb viga) muudan Jinja2 šabloni.
• dokumentatsiooni vaatenurgast on see peaaegu ideaalne olukord. Te muudate dokumentatsiooni (YAML failid toimivad NIP-ina) ja laadite selle конфигурация seadmesse. Nii on teie dokumentatsioon alati ajakohane.

Kõik see viis selleni, et

• vea protsent langes praktiliselt nulli
• rutliin kadus 90 protsenti
• rakendamise kiirus suurenes mitmeid kordi

PAY, F5Y, ACY

Mulle ütlesin, et mõni näide on piisav, et mõista, kuidas see töötab.
Siin on lühike (ja loomulikult muudetud) versioon sellest, mis loodi minu töö käigus.

PAY = juurutamine Pala Alto from Yaml = Palo Alto Yaml-ist
F5Y = juurutamine F5 from Yaml = F5 from Yaml (varsti tuleb)
ACY = juurutamine ACi from Yaml = F5 from Yaml

Lisaksin paar sõna ACY-st (mitte segi ajada ACI-ga).

Need, kes on töötanud ACI-ga, teavad, et see ime (ja ka heas mõttes) loodi mitte võrguinimestelt :). Unustage kõik, mida te teate võrgu osas — see ei tule marjaks!
Veidi liialdatud, aga peaaegu edastab tunnet, mida ma pidevalt tunnen, töötades ACI-ga viimased 3 aastat.

Ja antud juhul on ACY mitte ainult võimalus luua muutuste kontrollimise protsess (mis on eriti oluline ACI puhul, kuna see on teie andmekeskuse keskpunkt ja kõige kriitilisem osa), vaid see annab teile ka sõbraliku liidese конфигурация loomiseks.

Insenerid selles projektis kasutavad ACI konfigureerimiseks Exceli, et saavutada samu eesmärke, mitte YAML-i. Exceli kasutamise eelised on selged:

• teie NIP ühes failis
• ilusad tabelid, mida on meeldiv vaadata kliendile
• Saate kasutada mõningaid Exceli tööriistu

Kuid on üks miinus, mis minu arvates kaalub üles plussid. Meeskonna töö muutub oluliselt keerulisemaks muudatuste jälgimise ja kooskõlastamise osas.

ACY on tegelikult samade lähenemisviiside rakendamine, mida ma kasutasin 3rd party jaoks, ACI konfigureerimisel.

Allikas: habr.com