Acest articol este al șaselea din ciclul de articole „Cum să preiei controlul asupra infrastructurii de rețea”. Conținutul tuturor articolelor din ciclu și linkurile pot fi găsite .
După ce am lăsat câteva subiecte în urmă, am decis totuși să încep un nou capitol.
Mă voi întoarce la securitate puțin mai târziu. Aici vreau să discut despre o abordare simplă, dar eficientă, care, sunt sigur, poate fi utilă multora, în diferite forme. Este o poveste scurtă despre cum automatizarea poate schimba viața unui inginer. Va fi vorba despre utilizarea șabloanelor. La final, va fi inclusă o listă a proiectelor mele, unde puteți vedea cum funcționează tot ceea ce este descris aici.
DevOps pentru rețea
Crearea configurației prin script, utilizarea GIT pentru controlul modificărilor infrastructurii IT, încărcarea de la distanță — acestea sunt ideile care vin în minte atunci când te gândești la implementarea tehnică a abordării DevOps. Avantajele sunt evidente. Dar din păcate, există și dezavantaje.
Când, acum mai bine de 5 ani, dezvoltatorii noștri au venit la noi, tehnicienii de rețea, cu aceste propuneri, nu am fost foarte entuziasmați.
Trebuie să spun că am moștenit o rețea destul de pestriță, formată din echipamente de la aproximativ 10 furnizori diferiți. Unele au fost convenabile de configurat prin cli-ul nostru preferat, dar în alte cazuri am preferat să folosim GUI. În plus, munca îndelungată pe echipamentele „vii” ne-a făcut să ne obișnuim cu controlul în timp real. De exemplu, eu, când fac modificări, mă simt mult mai confortabil lucrând direct prin cli. Astfel pot vedea rapid dacă ceva a mers prost și pot „reseta” modificările. Toate acestea erau oarecum în dezacord cu ideile lor.
Apare și alte întrebări, de exemplu, de la o versiune de software la alta, interfața poate suferi mici schimbări. Asta va duce, în cele din urmă, la crearea unui „config” greșit de către scriptul tău. Nu mi-ar plăcea să folosesc producția pentru „testare”.
Sau, cum să înțelegi că comenzile de configurare au fost aplicate corect și ce să faci în cazul unei erori?
Nu vreau să spun că toate aceste întrebări sunt imposibil de rezolvat. Pur și simplu, spunând „A”, probabil că este înțelept să spui și „B”, și dacă vrei să folosești aceleași procese pentru controlul modificărilor ca și în dezvoltare, atunci trebuie să ai, pe lângă producție, și medii de dev și staging. Atunci această abordare ar părea completă. Dar cât va costa aceasta?
Dar există o situație în care dezavantajele sunt practic anulate, iar rămân doar avantajele. Vorbesc despre lucrările de proiectare.
Proiect
În ultimii doi ani am participat la un proiect pentru construirea unui centru de date pentru un furnizor important. Eu sunt responsabil pentru F5 și Palo Alto în acest proiect. Din perspectiva Cisco, acesta este un «echipament de terță parte».
Pentru mine, există două etape bine definite în acest proiect.
Prima etapă
În primul an am fost constant ocupat, lucram noaptea și în week-end-uri. Nu puteam să îmi ridic capul. Presiunea din partea managementului și a clientului era puternică și continuă. În rutina zilnică nu puteam chiar încerca să optimizez procesul. A fost nu doar configurarea echipamentelor, ci și redactarea documentației de proiect.
Apoi au început primele teste și am fost uimit de câte greșeli și inexactități au fost admise. Sigur că totul funcționa, dar acolo lipsea o literă în nume, aici lipsea o linie în comandă... Testele continuau și continuau, iar eu eram într-o luptă constantă, zilnică, cu greșelile, testele și documentația.
Așa a continuat timp de un an. Proiectul, din câte înțeleg, a fost dificil pentru toți, dar treptat clientul devenea din ce în ce mai mulțumit și aceasta a permis să angajăm ingineri suplimentari care au putut prelua o parte din rutină.
Acum puteam să arunc o privire mai atentă.
Și aceasta a fost începutul celei de-a doua etape.
A doua etapă
Am decis să automatizez procesul.
Ce am înțeles din comunicarea de atunci cu dezvoltatorii (și trebuie să recunosc, am avut o echipă puternică) este că formatul text, deși pare la prima vedere ceva din lumea sistemului de operare DOS, are o serie de proprietăți valoroase.
De exemplu, formatul text va fi util dacă doriți să profitați pe deplin de avantajele GIT și ale tuturor derivatelor sale. Și eu voiam.
Ei bine, pare că ai putea pur și simplu să păstrezi configurația sau lista de comenzi, dar a face modificări este destul de inconvenient. În plus, în proiectare există o altă sarcină importantă. Trebuie să aveți documentație care să descrie designul dvs. în ansamblu (Low Level Design) și implementarea specifică (Network Implementation Plan). Și în acest caz, utilizarea șabloanelor pare a fi o opțiune foarte potrivită.
Astfel, utilizând YAML și Jinja2, fișierul YAML cu parametrii de configurare, cum ar fi adresele IP, numerele BGP AS,... joacă excelent rolul de NIP, în timp ce template-urile Jinja2 includ sintaxă specifică designului, adică, în esență, sunt o reflexie a LLD.
Studierii limbajelor YAML și Jinja2 i-au fost alocate două zile. Pentru a înțelege cum funcționează, sunt suficiente câteva exemple bune. Apoi, a fost nevoie de aproximativ două săptămâni pentru a crea toate template-urile conform designului nostru: o săptămână pentru Palo Alto și încă o săptămână pentru F5. Totul a fost încărcat pe GitHub-ul corporativ.
Acum, procesul de schimbare arăta astfel:
- am modificat fișierul YAML
- am creat, folosind template-ul (Jinja2), fișierul de configurare
- l-am salvat în repository-ul remote
- am încărcat configurația creată pe echipament
- am văzut o eroare
- am modificat fișierul YAML sau template-ul Jinja2
- am creat, folosind template-ul (Jinja2), fișierul de configurare
- …
Este clar că, la început, am dedicat mult timp modificărilor, dar după o săptămână-două, asta a devenit mai degrabă o raritate.
O verificare bună și o oportunitate de a depura toate acestea a fost dorința clientului de a schimba convenția de denumire. Cei care au lucrat cu F5 înțeleg subtilitatea situației. Dar pentru mine, totul a fost destul de simplu. Am schimbat numele în fișierul YAML, am șters toată configurația de pe echipament, am generat una nouă și am încărcat-o. La toate acestea, ținând cont de corectarea erorilor, au fost necesare 4 zile: câte două zile pentru fiecare tehnologie. După asta am fost pregătit pentru următoarea etapă, și anume crearea datacentrelor DEV și Staging.
Dev și Staging
Staging reproduce în esență producția. Dev este o copie mult redusă, construită în principal pe echipamente virtuale. O situație ideală pentru aplicarea unei noi abordări. Dacă excludem timpul petrecut de mine din procesul general, munca a durat, cred, nu mai mult de 2 săptămâni. Timpul principal a fost timpul de așteptare a celeilalte părți și căutările comune ale problemelor. Implementarea terților a trecut aproape neobservată de cei din jur. A fost chiar timp să învăț ceva și să scriu câteva articole pe Habra 🙂
Să tragem concluzii
Așadar, ce am în rezumat?
- tot ce am nevoie pentru a modifica configurația — este să modific un fișier YAML simplu, clar structurat cu parametrii de configurare. Niciodată nu modific scriptul Python și foarte rar (doar dacă există o eroare) schimb template-ul Jinja2.
- Din perspectiva documentației, avem o situație aproape ideală. Schimbați documentația (fișierele YAML joacă rolul NIP) și încărcați această configurație pe echipamente. Astfel, documentația dumneavoastră este întotdeauna actualizată.
Toate acestea au dus la faptul că
- procentul de erori a scăzut practic la 0
- a dispărut 90% din rutină
- viteza de implementare a crescut de mai multe ori
PAY, F5Y, ACY
Am spus că câteva exemple sunt suficiente pentru a înțelege cum funcționează.
Aici este o versiune scurtă (și desigur, modificată) a ceea ce a fost creat în procesul muncii mele.
= implementare Palo Alto from Yaml = Palo Alto din YAML
= implementare F5 from Yaml = F5 from Yaml (în curând va fi)
= implementare ACi from Yaml = F5 from Yaml
Voi adăuga câteva cuvinte despre ACY (nu trebuie confundat cu ACI).
Cei care au lucrat cu ACI știu că această minune (și în sens bun) a fost creată cu siguranță nu de rețeliști :). Uitați tot ce știți despre rețea — nu vă va fi de folos!
Puțin exagerat, dar transmite aproximativ sentimentul pe care l-am experimentat constant, timp de 3 ani, lucrând cu ACI.
Și în acest caz, ACY nu oferă doar posibilitatea de a construi un proces de control al schimbărilor (ceea ce este deosebit de important în cazul ACI, deoarece se presupune că este parte centrală și cea mai critică a centrului dumneavoastră de date), ci oferă și o interfață prietenoasă pentru crearea configurației.
Inginerii din acest proiect folosesc Excel în loc de YAML pentru a configura ACI în scopuri de precizie similare. Există, desigur, unele avantaje în utilizarea Excel:
- NIP-ul dumneavoastră într-un singur fișier
- grafice frumoase, care sunt plăcute pentru client
- puteți utiliza unele instrumente Excel
Dar există o problemă, iar din punctul meu de vedere, aceasta overshadowează avantajele. Controlul schimbărilor și coordonarea muncii echipelor devine mult mai complicat.
ACY este practic aplicarea acelorși abordări pe care le-am folosit pentru terți, pentru configurarea ACI.
Sursa: habr.com
