See artikkel on kuues sarjast "Kuidas oma võrguinfrastruktuuri kontrolli alla võtta". Sarja kõigi artiklite sisu ja lingid leiate .
Olles jätnud mitu teemat selja taha, otsustasin alustada uut peatükki.
Tulen turvalisuse juurde veidi hiljem tagasi. Siinkohal tahan arutleda ühe lihtsa, kuid tõhusa lähenemisviisi üle, mis olen kindel, et ühel või teisel kujul võib paljudele kasulik olla. See on pigem lühike lugu sellest, kuidas automatiseerimine võib muuta inseneri elu. Räägime mallide kasutamisest. Lõpus on minu projektide nimekiri, kus näete, kuidas kõik siin kirjeldatud toimib.
DevOps võrgu jaoks
Konfiguratsiooni loomine skriptiga, GIT-i kasutamine IT-infrastruktuuri muudatuste juhtimiseks, kaugüleslaadimine – need ideed tulevad esikohale, kui mõelda DevOpsi lähenemisviisi tehnilisele rakendamisele. Eelised on ilmsed. Kuid kahjuks on ka puudusi.
Kui enam kui 5 aastat tagasi meie arendajad nende ettepanekutega meie, võrgutegijate poole pöördusid, ei olnud me sellest vaimustuses.
Pean ütlema, et pärisime üsna kirju võrgu, mis koosnes umbes 10 erineva müüja seadmetest. Mõningaid asju oli mugav konfigureerida meie lemmikkliendi kaudu, kuid teiste puhul eelistasime kasutada GUI-d. Lisaks on pikk töö "elavate" seadmete kallal õpetanud meid reaalajas kontrollima. Näiteks muudatusi tehes tunnen end palju mugavamalt otse klii kaudu töötades. Nii näen kiiresti, et midagi läks valesti, ja tühistan muudatused. Kõik see oli nende ideedega vastuolus.
Tekivad ka muud küsimused, näiteks võib liides tarkvara versiooniti veidi muutuda. See põhjustab lõpuks teie skripti vale konfiguratsiooni loomise. Ma ei tahaks tootmist "sissejooksuks" kasutada.
Või kuidas aru saada, et konfiguratsioonikäsud on õigesti rakendatud ja mida teha vea korral?
Ma ei taha öelda, et kõik need probleemid on lahendamatud. Lihtsalt "A" ütlemine on ilmselt mõttekas öelda ka "B" ja kui soovite kasutada muudatuste juhtimiseks samu protsesse, mis arenduses, siis peavad teil olema lisaks tootmisele ka arendus- ja lavastuskeskkonnad. Siis tundub see lähenemine täielik. Aga kui palju see maksma läheb?
Kuid on üks olukord, kus puudused on praktiliselt tasandatud ja jäävad ainult eelised. Ma räägin disainitööst.
Projekt
Viimased kaks aastat olen osalenud suurele pakkujale andmekeskuse ehitamise projektis. Vastutan selles projektis F5 ja Palo Alto eest. Cisco seisukohast on see "kolmanda osapoole varustus".
Minu jaoks isiklikult on selles projektis kaks erinevat etappi.
Esimene etapp
Esimesel aastal olin lõputult hõivatud, töötasin öösiti ja nädalavahetustel. Ma ei suutnud pead tõsta. Juhtkonna ja kliendi surve oli tugev ja pidev. Pidevas rutiinis ei saanud ma isegi proovida protsessi optimeerida. Asi polnud mitte ainult ja mitte niivõrd seadmete konfigureerimises, kuivõrd projektdokumentatsiooni koostamises.
Esimesed testid on alanud ja ma oleks üllatunud, kui palju pisivigu ja ebatäpsusi tehti. Muidugi kõik toimis, aga nimes oli puudu täht, käsus oli rida puudu... Testid läksid ja kestsid ja ma olin juba pidevas igapäevases võitluses vigade, testide ja dokumentatsiooniga. .
See kestis aasta. Projekt minu arusaamist mööda ei olnud kõigi jaoks lihtne, kuid aegamööda jäi klient üha rahulolevamaks ja see võimaldas palgata juurde insenere, kes said osa rutiinist ka ise enda kanda võtta.
Nüüd saime natuke ringi vaadata.
Ja see oli teise etapi algus.
Teine etapp
Otsustasin protsessi automatiseerida.
Tollasest suhtlusest arendajatega (ja me peame austust avaldama, meil oli tugev meeskond) sain aru, et tekstivormingul, kuigi esmapilgul tundub midagi DOS-i operatsioonisüsteemi maailmast, on oma number. väärtuslikest omadustest.
Näiteks on tekstivorming kasulik, kui soovite GIT-i ja kõiki selle tuletisi täielikult ära kasutada. Ja ma tahtsin.
Tundub, et saate lihtsalt konfiguratsiooni või käskude loendi salvestada, kuid muudatuste tegemine on üsna ebamugav. Lisaks on projekteerimisel veel üks oluline ülesanne. Teil peaks olema dokumentatsioon, mis kirjeldab teie disaini kui tervikut (madalatasemeline disain) ja konkreetset teostust (võrgu rakendusplaan). Ja sel juhul näib mallide kasutamine väga sobiv variant.
Seega täidab YAML-i ja Jinja2 kasutamisel YAML-fail konfiguratsiooniparameetritega, nagu IP-aadressid, BGP AS-i numbrid, suurepäraselt NIP-i rolli, samas kui Jinja2 mallid sisaldavad kujundusele vastavat süntaksit, st sisuliselt on tegemist LLD peegeldus.
YAMLi ja Jinja2 õppimiseks kulus kaks päeva. Selle toimimise mõistmiseks piisab mõnest heast näitest. Seejärel kulus kõigi meie kujundusega sobivate mallide loomiseks umbes kaks nädalat: nädal Palo Alto jaoks ja teine nädal F5 jaoks. Kõik see postitati ettevõtte githabi.
Nüüd nägi muutmisprotsess välja selline:
- muutis YAML-faili
- lõi malli abil konfiguratsioonifaili (Jinja2)
- salvestatud kaughoidlasse
- laadis loodud konfiguratsiooni seadmesse üles
- Ma nägin viga
- muutis YAML-faili või Jinja2 malli
- lõi malli abil konfiguratsioonifaili (Jinja2)
- ...
Selge see, et algul kulus toimetamistele palju aega, kuid nädala-paari pärast muutus see üsna harulduseks.
Hea test ja võimalus kõike siluda oli kliendi soov muuta nimetustava. Need, kes F5-ga töötasid, mõistavad olukorra pikantsust. Aga minu jaoks oli kõik üsna lihtne. Muutsin YAML-failis nimesid, kustutasin seadmest kogu konfiguratsiooni, genereerisin uue ja laadisin üles. Kõik, sealhulgas veaparandused, võttis aega 4 päeva: iga tehnoloogia jaoks kaks päeva. Pärast seda olin valmis järgmiseks etapiks, nimelt DEV ja Staging andmekeskuste loomiseks.
Arendaja ja lavastamine
Lavastus kordab tegelikult tootmist täielikult. Dev on tugevalt eemaldatud koopia, mis on ehitatud peamiselt virtuaalsele riistvarale. Ideaalne olukord uue lähenemise jaoks. Kui ma eraldan kulutatud aja kogu protsessist, siis arvan, et töö ei kestnud rohkem kui 2 nädalat. Põhiline aeg on teise poole ootamine ja koos probleemide otsimine. Kolmanda osapoole rakendamine jäi teistele peaaegu märkamatuks. Isegi oli aega midagi õppida ja Habré kohta paar artiklit kirjutada :)
Kokkuvõttes
Niisiis, mis mul alumisel real on?
- Kõik, mida ma konfiguratsiooni muutmiseks tegema pean, on muuta lihtsat, selgelt struktureeritud YAML-faili koos konfiguratsiooniparameetritega. Ma ei muuda kunagi pythoni skripti ja väga harva (ainult vea korral) muudan Jinja2 heatlate
- Dokumentatsiooni seisukohast on see peaaegu ideaalne olukord. Muudate dokumentatsiooni (YAML-failid toimivad NIP-na) ja laadite selle konfiguratsiooni seadmesse. Nii on teie dokumentatsioon alati ajakohane
Kõik see viis selleni, et
- veamäär on langenud peaaegu 0-ni
- 90 protsenti rutiinist on kadunud
- rakendamise kiirus on oluliselt suurenenud
PAY, F5Y, ACY
Ütlesin, et piisab paarist näitest, et aru saada, kuidas see toimib.
Siin on lühike (ja loomulikult muudetud) versioon sellest, mis minu töö käigus loodi.
= kasutuselevõtt PAlo Alto alates Yaml = Palo Alto Yamlist
= kasutuselevõtt F5 Alates Yaml = F5 Alates Yaml (varsti tulemas)
= kasutuselevõtt ACma pärit Yaml = F5 Alates Yaml
Lisan paar sõna ACY kohta (mitte segi ajada ACI-ga).
Need, kes on ACI-ga koostööd teinud, teavad, et see ime (ja heas mõttes ka) pole kindlasti võrgutegijate loodud :). Unustage kõik, mida teadsite võrgu kohta – see pole teile kasulik!
See on veidi liialdatud, kuid see annab jämedalt edasi tunde, mida olen viimase 3 aasta jooksul pidevalt kogenud ACI-ga töötades.
Ja sel juhul pole ACY mitte ainult võimalus ehitada üles muudatuste juhtimisprotsess (mis on eriti oluline ACI puhul, sest see peaks olema teie andmekeskuse keskne ja kõige kriitilisem osa), vaid annab teile ka kasutajasõbralik liides konfiguratsiooni loomiseks.
Selle projekti insenerid kasutavad Excelit, et konfigureerida YAML-i asemel ACI-d täpselt samadel eesmärkidel. Muidugi on Exceli kasutamisel eeliseid:
- teie NIP ühes failis
- ilusaid silte, mida on kliendil meeldiv vaadata
- võite kasutada mõnda Exceli tööriista
Kuid on üks miinus ja minu arvates kaalub see plussid üles. Muudatuste kontrollimine ja meeskonnatöö koordineerimine muutub palju keerulisemaks.
ACY on tegelikult samade lähenemisviiside rakendus, mida kasutasin kolmanda osapoole jaoks ACI konfigureerimiseks.
Allikas: www.habr.com