🥇Come prendere il controllo della propria infrastruttura di rete. Capitolo quarto. Automazione. Template

Questo articolo è il sesto di un ciclo di articoli intitolato "Come prendere il controllo dell'infrastruttura di rete". Puoi trovare l'indice di tutti gli articoli del ciclo e i link. qui.

Lasciandomi alle spalle alcuni argomenti, ho deciso di iniziare un nuovo capitolo.

Tornerò alla sicurezza più tardi. Qui voglio discutere un approccio semplice ma efficace che, ne sono certo, può essere utile a molti in un modo o nell'altro. È più una breve storia su come l'automazione possa cambiare la vita di un ingegnere. Si parlerà dell'uso dei template. Alla fine, troverai un elenco dei miei progetti dove puoi vedere come funziona tutto ciò che viene descritto qui.

DevOps per la rete

Creazione di configurazioni tramite script, utilizzo di GIT per il controllo delle modifiche all'infrastruttura IT, upload remoto — queste idee vengono in mente quando pensi all'implementazione tecnica dell'approccio DevOps. I vantaggi sono evidenti. Ma ci sono, sfortunatamente, anche svantaggi.

Quando più di 5 anni fa, i nostri sviluppatori ci hanno presentato queste proposte, noi, esperti di rete, non eravamo entusiasti.

È importante dire che abbiamo ereditato una rete piuttosto eterogenea, composta da attrezzature di circa 10 diversi fornitori. Alcuni aspetti erano facili da configurare tramite il nostro amato cli, ma in altri casi preferivamo utilizzare l'interfaccia grafica. Inoltre, il lungo lavoro su attrezzature "live" ci ha abituati al monitoraggio in tempo reale. Personalmente, quando faccio modifiche, mi sento molto più a mio agio lavorando direttamente tramite cli. In questo modo posso vedere rapidamente se qualcosa è andato storto e "annullare" le modifiche. Tutto ciò era in certa misura in contrasto con le loro idee.

Ci sono anche altre questioni, ad esempio, l'interfaccia del software può cambiare leggermente da una versione all'altra. Questo, alla fine, porterà a uno script che genera una "configurazione" errata. Non vorremmo utilizzare l'ambiente di produzione per "testare".

Oppure, come capire che i comandi di configurazione sono stati applicati correttamente e cosa fare in caso di errore?

Non voglio dire che tutte queste questioni siano irrisolvibili. Semplicemente, dicendo "A", è probabilmente saggio dire anche "B" e, se desideri utilizzare gli stessi processi per il controllo delle modifiche che utilizzi nello sviluppo, è necessario avere oltre all'ambiente di produzione anche gli ambienti di sviluppo e di staging. Allora questo approccio sembra completo. Ma quanto costerà?

Ma c'è una situazione in cui i difetti vengono praticamente annullati e rimangono solo i vantaggi. Parlo di lavori di progetto.

Progetto

Negli ultimi due anni ho partecipato a un progetto per la costruzione di un data center per un grande fornitore. In questo progetto sono responsabile di F5 e Palo Alto. Dal punto di vista di Cisco, si tratta di "attrezzature di terze parti".

Personalmente, vedo due fasi distintive in questo progetto.

Prima fase

Nel primo anno sono stato incessantemente impegnato, lavorando di notte e nei fine settimana. Non riuscivo a sollevare la testa. La pressione da parte della direzione e del cliente era forte e continua. Nella routine costante, non potevo nemmeno tentare di ottimizzare il processo. Non si trattava solo e nemmeno principalmente della configurazione dell'hardware, ma piuttosto della redazione della documentazione progettuale.

Ecco iniziati i primi test e sono rimasto colpito da quanti piccoli errori e imprecisioni sono stati commessi. Certo, tutto funzionava, ma mancava una lettera nel nome qui, c'era una riga mancante nel comando là... I test continuavano e continuavano, e mi trovavo già in una lotta quotidiana e costante con errori, test e documentazione.

Così è andata avanti per un anno. Il progetto, per quanto ne so, non è stato semplice per nessuno, ma gradualmente il cliente diventava sempre più soddisfatto, e questo ha consentito di assumere ingegneri aggiuntivi che potessero prendersi parte della routine.

Ora si poteva cominciare a guardarsi attorno.
E questo è stato l'inizio della seconda fase.

Seconda fase

Ho deciso di automatizzare il processo.

Quello che ho capito dai colloqui con gli sviluppatori dell'epoca (e devo dare atto, avevamo un ottimo team) è che il formato di testo, anche se sembra a prima vista qualcosa dal mondo dei sistemi operativi DOS, possiede una serie di proprietà preziose.
Ad esempio, il formato di testo sarà utile se desideri sfruttare appieno i vantaggi di GIT e di tutte le sue derivanti. E io li volevo.

Tuttavia, potrebbe sembrare possibile semplicemente memorizzare la configurazione o un elenco di comandi, ma apportare modifiche risulta abbastanza scomodo. Inoltre, nella progettazione c'è un'altra importante sfida. È necessario avere una documentazione che descriva il design nel suo complesso (Low Level Design) e una specifica implementazione (Network Implementation Plan). In questo caso, l'uso di template sembra essere un'opzione molto adatta.

Pertanto, utilizzando YAML e Jinja2, il file YAML con i parametri di configurazione, come indirizzi IP, numeri BGP AS,… svolge perfettamente il ruolo di NIP, mentre i template Jinja2 includono la sintassi corrispondente al design, essendo quindi essenzialmente un riflesso dell'LLD.

Ho impiegato due giorni per studiare i linguaggi YAML e Jinja2. Per comprendere come funzionano, bastano alcuni buoni esempi. Successivamente, ci sono volute circa due settimane per creare tutti i template in linea con il nostro design: una settimana per Palo Alto e un'altra settimana per F5. Tutto ciò è stato caricato sul nostro GitHub aziendale.

Ora il processo di modifica si presentava nel seguente modo:

modificato il file YAML
creato il file di configurazione utilizzando il template (Jinja2)
salvato nel repository remoto
ho caricato la configurazione creata sull'hardware
ho visto un errore
ho modificato il file YAML o il template Jinja2
creato il file di configurazione utilizzando il template (Jinja2)
…

È chiaro che inizialmente richiedeva molto tempo per le modifiche, ma dopo una o due settimane è diventato piuttosto raro.

Una buona verifica e opportunità per tutto il debug è stata la richiesta del cliente di cambiare la naming convention. Chi ha lavorato con F5 capisce la delicatezza della situazione. Ma per me è stato piuttosto semplice. Ho cambiato i nomi nel file YAML, ho eliminato tutta la configurazione dall'hardware, ho generato una nuova configurazione e l'ho caricata. Per tutto, considerando le correzioni dei bug, ho impiegato 4 giorni: due giorni per ogni tecnologia. Dopo di che ero pronto per il prossimo passo, ovvero la creazione dei data center DEV e Staging.

Dev e Staging

La fase di staging replica praticamente completamente la produzione. La fase di sviluppo è una copia fortemente ridotta e basata principalmente su hardware virtuale. Questo è il contesto ideale per implementare un nuovo approccio. Se escludiamo il tempo che ho speso nel complesso processo, i lavori penso non abbiano richiesto più di due settimane. Il tempo principale è stato impiegato nell'attesa dell'altra parte e nella ricerca congiunta di problemi. L'implementazione di terze parti è avvenuta quasi inosservata per chi ci circonda. È persino rimasto del tempo per imparare qualcosa e scrivere un paio di articoli su Habra 🙂

Riassumiamo

Quindi, qual è il risultato finale?

Tutto ciò che mi serve per modificare la configurazione è cambiare un semplice file YAML ben strutturato con i parametri di configurazione. Non modifico mai lo script Python e molto raramente (solo se c'è un errore) cambio il template Jinja2.
Dal punto di vista della documentazione, si arriva quasi a una situazione ideale. Si modifica la documentazione (i file YAML svolgono il ruolo di NIP) e si carica questa configurazione sull'hardware. In questo modo la vostra documentazione è sempre attuale.

Tutto ciò ha portato a

il tasso di errori è sceso praticamente a 0
il 90 percento della routine è stato eliminato
la velocità di implementazione è aumentata esponenzialmente.

PAGA, F5Y, ACY

Ho detto che alcuni esempi sono sufficienti per capire come funziona.
Ecco una versione breve (e chiaramente modificata) di ciò che è stato creato durante il mio lavoro.

PAGA = distribuzione Palo Alto da Yaml = Palo Alto da Yaml
F5Y = distribuzione F5 from Yaml = F5 from Yaml (prossimamente)
ACY = distribuzione ACi da Yaml = F5 from Yaml

Aggiungerò alcune parole su ACY (non confondere con ACI).

Chi ha lavorato con ACI sa che questa meraviglia (e in senso positivo) non è stata creata da addetti alla rete :). Dimentica tutto quello che sai sulla rete — non ti servirà!
Un po' esagerato, ma trasmette grossomodo la sensazione che provo da tre anni a questa parte lavorando con ACI.

In questo caso, ACY non è solo la possibilità di stabilire un processo di controllo delle modifiche (cosa particolarmente importante nel caso di ACI, dato che si presume che sia la parte centrale e più critica del tuo data center), ma offre anche un'interfaccia amichevole per creare configurazioni.

Gli ingegneri di questo progetto utilizzano Excel per configurare ACI al posto di YAML per la precisione degli stessi obiettivi. Usare Excel ha certamente i suoi vantaggi: