Kako preuzeti kontrolu nad vašom mrežnom infrastrukturom. Četvrto poglavlje. Automatizacija. Predlošci

Ovaj članak je šesti u seriji “Kako preuzeti kontrolu nad svojom mrežnom infrastrukturom”. Sadržaj svih članaka u seriji i linkove možete pronaći ovdje.

Nakon što sam ostavio nekoliko tema iza sebe, odlučio sam započeti novo poglavlje.

Vratiću se na obezbeđenje malo kasnije. Ovdje želim razgovarati o jednom jednostavnom, ali efikasnom pristupu, za koji sam siguran, u ovom ili onom obliku, može biti koristan mnogima. Ovo je više kratka priča o tome kako automatizacija može promijeniti život inženjera. Govorit ćemo o korištenju šablona. Na kraju je lista mojih projekata gdje možete vidjeti kako sve ovdje opisano funkcionira.

DevOps za mrežu

Kreiranje konfiguracije pomoću skripte, korištenje GIT-a za kontrolu promjena na IT infrastrukturi, daljinsko „prebacivanje“ - ove ideje dolaze na prvo mjesto kada razmišljate o tehničkoj implementaciji DevOps pristupa. Prednosti su očigledne. Ali, nažalost, postoje i nedostaci.

Kada su prije više od 5 godina naši programeri došli kod nas, networkera, sa ovim prijedlozima, nismo bili oduševljeni.

Moram reći da smo naslijedili prilično šaroliku mrežu, koja se sastoji od opreme od 10-ak različitih proizvođača. Bilo je zgodno konfigurirati neke stvari preko našeg omiljenog cli-a, ali u drugima smo radije koristili GUI. Osim toga, dug rad na opremi „živoj“ naučio nas je kontroli u realnom vremenu. Na primjer, kada pravim promjene, osjećam se mnogo ugodnije radeći direktno kroz cli. Na ovaj način mogu brzo vidjeti da je nešto pošlo po zlu i vratiti promjene. Sve je to bilo u nekoj suprotnosti sa njihovim idejama.

Postavljaju se i druga pitanja, na primjer, sučelje se može neznatno promijeniti od verzije do verzije softvera. Ovo će na kraju uzrokovati da vaša skripta kreira pogrešnu "config". Ne bih volio da koristim proizvodnju za „uhodavanje“.

Ili, kako razumjeti da su konfiguracijske komande ispravno primijenjene i što učiniti u slučaju greške?

Ne želim da kažem da su sva ova pitanja nerešiva. Samo izgovoriti “A” vjerovatno ima smisla reći i “B”, a ako želite da koristite iste procese za kontrolu promjena kao u razvoju, onda morate imati dev i scenska okruženja pored produkcije. Tada ovaj pristup izgleda potpuno. Ali koliko će to koštati?

Ali postoji jedna situacija kada su nedostaci praktično izravnani, a ostaju samo prednosti. Govorim o dizajnerskom radu.

Projekat

Posljednje dvije godine učestvujem u projektu izgradnje data centra za velikog provajdera. Odgovoran sam za F5 i Palo Alto u ovom projektu. Sa Cisco-ove tačke gledišta, ovo je „oprema treće strane“.

Za mene lično postoje dvije različite faze u ovom projektu.

Prva faza

Prve godine sam bio beskrajno zauzet, radio sam noću i vikendom. Nisam mogao da podignem glavu. Pritisak menadžmenta i kupaca bio je snažan i kontinuiran. U stalnoj rutini, nisam mogao ni pokušati optimizirati proces. Nije to bila samo i ne toliko konfiguracija opreme koliko i izrada projektne dokumentacije.

Prvi testovi su počeli, a ja bih bio začuđen koliko je malih grešaka i netačnosti napravljeno. Naravno, sve je funkcionisalo, ali je nedostajalo slovo u nazivu, nedostajao je red u komandi... Testovi su išli i dalje, a ja sam već bio u stalnoj, svakodnevnoj borbi sa greškama, testovima i dokumentacijom. .

Ovo je trajalo godinu dana. Projekat, koliko sam shvatio, nije bio lak za sve, ali postepeno je klijent postajao sve zadovoljniji, a to je omogućilo da se angažuju dodatni inženjeri koji su sami mogli da preuzmu deo rutine.

Sada bismo mogli malo pogledati okolo.
I ovo je bio početak druge faze.

Druga faza

Odlučio sam da automatizujem proces.

Ono što sam shvatio iz tadašnje komunikacije sa programerima (a moramo odati počast, imali smo jak tim) jeste da tekstualni format, iako na prvi pogled deluje kao nešto iz sveta DOS operativnog sistema, ima broj vrednih nekretnina.
Tako će, na primjer, tekstualni format biti koristan ako želite u potpunosti iskoristiti GIT i sve njegove derivate. I htela sam.

Pa, čini se da možete jednostavno pohraniti konfiguraciju ili listu naredbi, ali unošenje promjena je prilično nezgodno. Osim toga, postoji još jedan važan zadatak tokom dizajna. Trebali biste imati dokumentaciju koja opisuje vaš dizajn u cjelini (Low Level Design) i specifičnu implementaciju (Mrežni plan implementacije). I u ovom slučaju, korištenje predložaka izgleda kao vrlo prikladna opcija.

Dakle, kada koristite YAML i Jinja2, YAML datoteka sa konfiguracijskim parametrima kao što su IP adrese, BGP AS brojevi,... savršeno ispunjava ulogu NIP-a, dok Jinja2 predlošci uključuju sintaksu koja odgovara dizajnu, odnosno u suštini je odraz LLD.

Trebalo je dva dana da naučim YAML i Jinja2. Nekoliko dobrih primjera je dovoljno da shvatite kako ovo funkcionira. Zatim je trebalo oko dvije sedmice da se kreiraju svi predlošci koji su odgovarali našem dizajnu: sedmica za Palo Alto i još jedna sedmica za F5. Sve ovo je objavljeno na korporativnom githabu.

Sada je proces promjene izgledao ovako:

  • promijenio YAML datoteku
  • kreirao konfiguracionu datoteku koristeći šablon (Jinja2)
  • sačuvano u udaljenom spremištu
  • prenio kreiranu konfiguraciju na opremu
  • Vidio sam grešku
  • promijenio YAML datoteku ili Jinja2 šablon
  • kreirao konfiguracionu datoteku koristeći šablon (Jinja2)
  • ...

Jasno je da se u početku dosta vremena trošilo na uređivanje, ali nakon tjedan-dvije to je postala prava rijetkost.

Dobar test i prilika za otklanjanje grešaka u svemu bila je želja klijenta da promijeni konvenciju imenovanja. Oni koji su radili sa F5 razumiju pikanciju situacije. Ali za mene je sve bilo prilično jednostavno. Promijenio sam nazive u YAML datoteci, obrisao cijelu konfiguraciju iz opreme, generirao novu i postavio je. Sve, uključujući ispravke grešaka, trajalo je 4 dana: dva dana za svaku tehnologiju. Nakon toga, bio sam spreman za sljedeću fazu, odnosno stvaranje DEV i Staging data centara.

Dev and Staging

Inscenacija zapravo u potpunosti replicira proizvodnju. Dev je jako skraćena kopija izgrađena uglavnom na virtuelnom hardveru. Idealna situacija za novi pristup. Ako izdvojim vrijeme koje sam potrošio od cjelokupnog procesa, onda mislim da je posao trajao ne više od 2 sedmice. Glavno vrijeme je čekanje druge strane i zajedničko traženje problema. Implementacija treće strane ostala je gotovo neprimijećena od strane drugih. Čak je bilo vremena da se nešto nauči i napiše par članaka na Habréu :)

Hajde da rezimiramo

Dakle, šta imam u krajnjoj liniji?

  • Sve što treba da uradim da promenim konfiguraciju je da promenim jednostavnu, jasno strukturiranu YAML datoteku sa konfiguracionim parametrima. Nikada ne mijenjam python skriptu i vrlo rijetko (samo ako postoji greška) mijenjam Jinja2 heatlate
  • Sa dokumentacijske tačke gledišta, ovo je gotovo idealna situacija. Vi mijenjate dokumentaciju (YAML fajlovi služe kao NIP) i učitavate ovu konfiguraciju u opremu. Na ovaj način vaša dokumentacija je uvijek ažurna

Sve je to dovelo do toga da

  • stopa greške je pala na skoro 0
  • 90 posto rutine je nestalo
  • brzina implementacije je značajno povećana

PAY, F5Y, ACY

Rekao sam da je nekoliko primjera dovoljno da se shvati kako to funkcionira.
Evo kratke (i naravno modifikovane) verzije onoga što je nastalo tokom mog rada.

PAY = raspoređivanje Palo Alto from Yaml = Palo Alto iz Yamla
F5Y = raspoređivanje F5 od Yaml = F5 od Yaml (uskoro)
ACY = raspoređivanje ACja iz Yaml = F5 od Yaml

Dodaću nekoliko riječi o ACY-u (ne smije se brkati sa ACI-jem).

Oni koji su sarađivali sa ACI-jem znaju da ovo čudo (i na dobar način) definitivno nisu stvorili mrežari :). Zaboravite sve što ste znali o mreži - neće vam biti od koristi!
Malo je preuveličano, ali otprilike prenosi osjećaj koji sam stalno doživljavao, posljednje 3 godine, radeći sa ACI-jem.

I u ovom slučaju, ACY nije samo prilika da se izgradi proces kontrole promjena (što je posebno važno u slučaju ACI-ja, jer bi on trebao biti centralni i najkritičniji dio vašeg podatkovnog centra), već vam također pruža korisničko sučelje za kreiranje konfiguracije.

Inženjeri na ovom projektu koriste Excel za konfiguriranje ACI-a umjesto YAML-a za potpuno iste svrhe. Postoje, naravno, prednosti korištenja Excela:

  • vaš NIP u jednom fajlu
  • prelepi znakovi koji su klijentu prijatni za gledanje
  • možete koristiti neke Excel alate

Ali postoji jedan minus, i po mom mišljenju nadmašuje prednosti. Kontrola promjena i koordinacija timskog rada postaje mnogo teže.

ACY je zapravo aplikacija istih pristupa koje sam koristio za 3rd party da konfiguriše ACI.

izvor: www.habr.com

Dodajte komentar