Questo articolo è il sesto di un ciclo di articoli "Come prendere il controllo delle infrastrutture di rete". Puoi trovare il contenuto di tutti gli articoli del ciclo e i link. .
Lasciandomi alle spalle alcuni argomenti, ho deciso comunque di iniziare un nuovo capitolo.
Tornerò alla sicurezza più avanti. Qui voglio discutere un approccio semplice, ma efficace, che sono sicuro, in un modo o nell'altro, può essere utile a molti. È più una storia breve su come l'automazione può cambiare la vita di un ingegnere. Parleremo dell'uso dei template. Alla fine, c'è un elenco dei miei progetti dove puoi vedere come tutto ciò che è descritto qui funziona.
DevOps per la rete
Creazione di configurazioni tramite script, utilizzo di GIT per il controllo delle modifiche all'infrastruttura IT, caricamento remoto: queste idee vengono in mente immediatamente quando pensi all'implementazione tecnica del metodo DevOps. I vantaggi sono evidenti. Ma ci sono, purtroppo, anche svantaggi.
Quando più di 5 anni fa, i nostri sviluppatori sono venuti da noi, dai network engineer, con queste proposte, non eravamo entusiasti.
Devo dire che abbiamo ereditato una rete piuttosto complessa, composta da apparecchiature di circa 10 diversi fornitori. Alcuni erano facili da configurare tramite il nostro amato cli, ma in altri casi preferivamo usare il GUI. Inoltre, una lunga esperienza con l'hardware "vivo" ci ha abituati al monitoraggio in tempo reale. Personalmente, quando apporto modifiche, mi sento molto più a mio agio lavorando direttamente tramite cli. Così posso vedere rapidamente se qualcosa non va e "annullare" le modifiche. Tutto ciò era in qualche modo in contrasto con le loro idee.
Sorgono anche altre domande, ad esempio, da una versione all'altra del software, l'interfaccia può cambiare leggermente. Questo, alla fine, porterà al fatto che il tuo script creerà una "configurazione" errata. Non mi piacerebbe usare 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 domande siano senza risposta. Semplicemente, dopo aver detto "A", è sensato dire anche "B" e, se vuoi utilizzare gli stessi processi per il controllo delle modifiche che usi nello sviluppo, allora devi avere, oltre all'ambiente di produzione, anche ambienti dev e staging. Solo allora questo approccio appare completo. Ma quanto costerà?
Ma c'è una situazione in cui gli svantaggi si annullano praticamente, 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, ci sono due fasi chiaramente definite in questo progetto.
Prima fase
Nel primo anno sono stato costantemente occupato, lavoravo 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 di configurare l'attrezzatura, ma anche di redigere la documentazione di progetto.
Ecco che sono iniziati i primi test, e sono rimasto colpito da quante piccole errori e imprecisioni fossero stati commessi. Certo, tutto funzionava, ma lì mancava una lettera nel nome, qui era stata omessa una riga nel comando… I test continuavano e continuavano, e mi trovavo costantemente in una lotta quotidiana con errori, test e documentazione.
Così è andato avanti per un anno. Il progetto, per come lo capisco, non è stato semplice per nessuno, ma gradualmente il cliente diventava sempre più soddisfatto, e questo ha permesso di prendere ingegneri aggiuntivi, che potevano prendersi parte della routine.
Ora era possibile guardarsi intorno.
E questo è stato l'inizio della seconda fase.
Seconda fase
Ho deciso di automatizzare il processo.
Quello che ho capito dai colloqui di allora con gli sviluppatori (e va dato atto, avevamo un team forte) è che il formato di testo, anche se sembra a prima vista qualcosa dal mondo del sistema operativo DOS, possiede una serie di qualità preziose.
Ad esempio, il formato di testo sarà utile se desideri sfruttare appieno i vantaggi di GIT e di tutte le sue derivazioni. E io volevo.
Beh, sembrerebbe che si potrebbe semplicemente utilizzare un file di configurazione o un elenco di comandi, ma apportare modifiche è piuttosto scomodo. Inoltre, durante la progettazione c'è un'altra importante esigenza. Devi avere una documentazione che descriva il tuo design in generale (Low Level Design) e l'implementazione specifica (Network Implementation Plan). E in questo caso, utilizzare dei template sembra essere un'opzione molto appropriata.
Quindi, nell'uso di YAML e Jinja2, il file YAML con i parametri di configurazione, come indirizzi IP, numeri AS BGP, ... svolge eccellentemente il ruolo di NIP, mentre i modelli Jinja2 includono una sintassi conforme al design, che significa che è fondamentalmente un riflesso del LLD.
Ho impiegato due giorni per apprendere i linguaggi YAML e Jinja2. Per capire come funziona, bastano alcuni buoni esempi. Successivamente, ci sono volute circa due settimane per creare tutti i modelli che corrispondono al nostro design: una settimana per Palo Alto e un'altra settimana per F5. Tutto ciò è stato caricato sul repository aziendale GitHub.
Ora il processo di cambiamento appariva nel seguente modo:
- ho modificato il file YAML
- ho creato un file di configurazione utilizzando il modello (Jinja2)
- ho salvato nel repository remoto
- ho caricato la configurazione creata sull'hardware
- ho visto un errore
- ho modificato il file YAML o il modello Jinja2
- ho creato un file di configurazione utilizzando il modello (Jinja2)
- …
È chiaro che inizialmente molto tempo veniva speso per le correzioni, ma dopo una o due settimane questo è diventato piuttosto raro.
Una buona verifica e opportunità per risolvere tutto è stata la volontà del cliente di cambiare la convenzione di denominazione. Chi ha lavorato con F5 capisce la delicatezza della situazione. Ma per me è stato piuttosto semplice. Ho cambiato i nomi nel file YAML, ho rimosso tutta la configurazione dall'hardware, ho generato un nuovo set e l'ho caricato. Per tutto, considerando le correzioni dei bug, ci sono voluti 4 giorni: due giorni per ogni tecnologia. Dopo di che, ero pronto per la fase successiva, ovvero la creazione dei data center DEV e Staging.
Dev e Staging
Staging replica praticamente totalmente la produzione. Dev è una copia fortemente ridotta e costruita principalmente su hardware virtuale. Situazione ideale per applicare un nuovo approccio. Se escludiamo il tempo che ho impiegato, penso che il lavoro non abbia richiesto più di 2 settimane. Il tempo principale è stato dedicato all'attesa dell'altra parte e alla ricerca collaborativa dei problemi. L'implementazione di terze parti è avvenuta quasi senza che gli altri se ne accorgessero. È persino avanzato del tempo per imparare qualcosa e scrivere un paio di articoli su Habr 🙂
Riassumiamo
Quindi, cosa ho in estrema sintesi?
- tutto ciò che mi serve per cambiare la configurazione è modificare un semplice file YAML ben strutturato con i parametri di configurazione. Non cambio mai lo script python e molto raramente (solo se c'è un errore) modifico il modello Jinja2.
- Dal punto di vista della documentazione, si ha una situazione quasi perfetta. Si modifica la documentazione (i file YAML svolgono il ruolo di NIP) e si carica questa configurazione sull'hardware. Così la vostra documentazione è sempre aggiornata.
Tutto ciò ha portato a
- una riduzione quasi a zero del tasso di errori.
- il 90% della routine è scomparso.
- la velocità di implementazione è aumentata di diversi fattori.
PAY, F5Y, ACY
Ho detto che alcuni esempi sono sufficienti per capire come funziona.
Ecco una versione breve (e naturalmente modificata) di ciò che è stato creato nel corso del mio lavoro.
= deployment Palo Alto from Yaml = Palo Alto from Yaml
= deployment F5 da Yaml = F5 da Yaml (presto disponibile)
= deployment ACi from Yaml = F5 da Yaml
Aggiungerò alcune parole su ACY (non confondere con ACI).
Coloro che hanno lavorato con ACI sanno che quest'innovazione (e in senso positivo) non è stata realizzata da persone del settore della rete :). Dimenticate tutto ciò che sapevate sulla rete: non vi servirà!
È un po' esagerato, ma rende approssimativamente l'idea che provo costantemente da 3 anni, lavorando con ACI.
E in questo caso, ACY non è solo la possibilità di costruire un processo di controllo delle modifiche (cosa particolarmente importante nel caso di ACI, poiché si presume che sia la parte centrale e più critica del vostro data center), ma offre anche un'interfaccia intuitiva per la creazione della configurazione.
Gli ingegneri di questo progetto utilizzano Excel invece di YAML per configurare ACI, per raggiungere gli stessi obiettivi. Ci sono vantaggi nell'usare Excel:
- il vostro NIP in un unico file
- bellissimi fogli di calcolo, che sono piacevoli da mostrare al cliente
- potete usare alcuni strumenti di Excel
Ma c'è un grosso svantaggio, che a mio avviso supera i vantaggi. Controllare le modifiche e coordinare il lavoro del team diventa molto più difficile.
ACY è praticamente l'applicazione degli stessi approcci che ho usato per i third party, per la configurazione di ACI.
Fonte: habr.com
