Questo articolo è il sesto della serie "Come assumere il controllo della propria infrastruttura di rete". È possibile trovare il contenuto di tutti gli articoli della serie e i collegamenti .
Dopo aver lasciato alle spalle diversi argomenti, ho deciso di iniziare un nuovo capitolo.
Tornerò alla sicurezza un po' più tardi. Qui voglio discutere un approccio semplice ma efficace, che sono sicuro, in una forma o nell’altra, può essere utile a molti. Questa è più una breve storia su come l'automazione può cambiare la vita di un ingegnere. Parleremo dell'utilizzo dei modelli. Alla fine c'è un elenco dei miei progetti dove puoi vedere come funziona tutto quanto qui descritto.
DevOps per la rete
Creazione di una configurazione con uno script, utilizzo di GIT per controllare le modifiche all'infrastruttura IT, "caricamento" remoto: queste idee vengono prima di tutto quando si pensa all'implementazione tecnica dell'approccio DevOps. I vantaggi sono evidenti. Ma sfortunatamente ci sono anche degli svantaggi.
Quando più di 5 anni fa i nostri sviluppatori si sono rivolti a noi, i networker, con queste proposte, non ne siamo rimasti entusiasti.
Devo dire che abbiamo ereditato una rete piuttosto eterogenea, composta da apparecchiature di circa 10 fornitori diversi. È stato conveniente configurare alcune cose tramite la nostra CLI preferita, ma in altre abbiamo preferito utilizzare la GUI. Inoltre, il lungo lavoro sulle apparecchiature “vive” ci ha insegnato il controllo in tempo reale. Ad esempio, quando apporto modifiche, mi sento molto più a mio agio lavorando direttamente tramite la CLI. In questo modo posso vedere rapidamente che qualcosa è andato storto e ripristinare le modifiche. Tutto ciò era in qualche contraddizione con le loro idee.
Sorgono anche altre domande, ad esempio l'interfaccia può cambiare leggermente da versione a versione del software. Ciò alla fine farà sì che il tuo script crei la "config" sbagliata. Non vorrei utilizzare la produzione per il “rodaggio”.
Oppure, come capire che i comandi di configurazione sono stati applicati correttamente e cosa fare in caso di errore?
Non voglio dire che tutti questi problemi siano irrisolvibili. Dire semplicemente "A" probabilmente ha senso dire anche "B" e, se si desidera utilizzare gli stessi processi per il controllo delle modifiche dello sviluppo, è necessario disporre di ambienti di sviluppo e di staging oltre alla produzione. Quindi questo approccio sembra completo. Ma quanto costerà?
Ma c'è una situazione in cui gli svantaggi sono praticamente livellati e rimangono solo i vantaggi. Sto parlando del lavoro di progettazione.
Progetto
Negli ultimi due anni ho partecipato a un progetto per costruire un data center per un grande provider. Sono responsabile di F5 e Palo Alto in questo progetto. Dal punto di vista di Cisco, si tratta di "apparecchiature di terze parti".
Per me personalmente, ci sono due fasi distinte in questo progetto.
Primo stadio
Il primo anno ero infinitamente occupato, lavoravo di notte e nei fine settimana. Non potevo alzare la testa. La pressione da parte del management e del cliente è stata forte e continua. In una routine costante, non potevo nemmeno provare a ottimizzare il processo. Non si trattava solo e non tanto della configurazione delle apparecchiature quanto della preparazione della documentazione di progettazione.
Sono iniziati i primi test e rimarrei stupito di quanti piccoli errori e imprecisioni siano stati commessi. Naturalmente tutto ha funzionato, ma mancava una lettera nel nome, mancava una riga nel comando... I test continuavano all'infinito e io ero già in una lotta costante e quotidiana con errori, test e documentazione .
La cosa andò avanti per un anno. Il progetto, a quanto ho capito, non è stato facile per tutti, ma gradualmente il cliente è diventato sempre più soddisfatto e questo ha permesso di assumere ulteriori ingegneri che hanno potuto farsi carico di parte della routine.
Ora potremmo guardarci un po' intorno.
E questo fu l'inizio della seconda fase.
Secondo stadio
Ho deciso di automatizzare il processo.
Ciò che ho capito allora dalla mia comunicazione con gli sviluppatori (e dobbiamo rendergli omaggio, avevamo una squadra forte) è che il formato del testo, anche se a prima vista sembra qualcosa proveniente dal mondo del sistema operativo DOS, ha un numero di immobili di pregio.
Quindi, ad esempio, il formato testo sarà utile se si vuole sfruttare appieno GIT e tutti i suoi derivati. E volevo farlo.
Bene, sembrerebbe che tu possa semplicemente memorizzare una configurazione o un elenco di comandi, ma apportare modifiche è piuttosto scomodo. Inoltre, durante la progettazione c'è un altro compito importante. Dovresti avere la documentazione che descrive il tuo progetto nel suo insieme (Progettazione di basso livello) e l'implementazione specifica (Piano di implementazione della rete). E in questo caso, l'uso dei modelli sembra un'opzione molto adatta.
Quindi, quando si utilizza YAML e Jinja2, un file YAML con parametri di configurazione come indirizzi IP, numeri AS BGP, ... svolge perfettamente il ruolo di NIP, mentre i modelli Jinja2 includono la sintassi corrispondente al design, cioè è essenzialmente un riflesso del LLD.
Ci sono voluti due giorni per imparare YAML e Jinja2. Bastano pochi esempi concreti per capire come funziona. Poi ci sono volute circa due settimane per creare tutti i modelli che corrispondevano al nostro design: una settimana per Palo Alto e un'altra settimana per F5. Tutto questo è stato pubblicato su githab aziendale.
Ora il processo di modifica era simile al seguente:
- ha cambiato il file YAML
- creato un file di configurazione utilizzando un modello (Jinja2)
- salvato in un repository remoto
- caricato la configurazione creata sull'apparecchiatura
- Ho visto un errore
- ha cambiato il file YAML o il modello Jinja2
- creato un file di configurazione utilizzando un modello (Jinja2)
- ...
È chiaro che all'inizio veniva dedicato molto tempo alle modifiche, ma dopo una o due settimane questa è diventata piuttosto una rarità.
Un buon test e un'opportunità per eseguire il debug di tutto è stato il desiderio del cliente di modificare la convenzione di denominazione. Coloro che hanno lavorato con F5 comprendono la piccantezza della situazione. Ma per me è stato tutto abbastanza semplice. Ho cambiato i nomi nel file YAML, ho cancellato l'intera configurazione dall'apparecchiatura, ne ho generata una nuova e l'ho caricata. Tutto, comprese le correzioni dei bug, ha richiesto 4 giorni: due giorni per ciascuna tecnologia. Successivamente ero pronto per la fase successiva, ovvero la creazione di data center DEV e Staging.
Sviluppo e messa in scena
La messa in scena in realtà replica completamente la produzione. Dev è una copia fortemente ridotta, costruita principalmente su hardware virtuale. Una situazione ideale per un nuovo approccio. Se isolo il tempo impiegato dal processo complessivo, penso che il lavoro non abbia richiesto più di 2 settimane. Il momento principale è aspettare l'altra parte e cercare insieme i problemi. L'implementazione di terze parti è passata quasi inosservata agli altri. C'è stato anche il tempo per imparare qualcosa e scrivere un paio di articoli su Habré :)
Per riassumere
Allora, cosa ho in fondo?
- Tutto quello che devo fare per modificare la configurazione è modificare un file YAML semplice e chiaramente strutturato con parametri di configurazione. Non cambio mai lo script python e molto raramente (solo se c'è un errore) cambio il heatlate Jinja2
- Dal punto di vista della documentazione, questa è una situazione quasi ideale. Si modifica la documentazione (i file YAML fungono da NIP) e si carica questa configurazione sull'apparecchiatura. In questo modo la tua documentazione sarà sempre aggiornata
Tutto ciò ha portato al fatto che
- il tasso di errore è sceso quasi a 0
- Il 90% della routine è sparito
- la velocità di attuazione è aumentata in modo significativo
PAGAMENTO, F5Y, ACY
Ho detto che bastano pochi esempi per capire come funziona.
Ecco una versione breve (e ovviamente modificata) di quanto realizzato durante il mio lavoro.
= distribuzione Palo Alto da Yaml = Palo Alto da Yaml
= distribuzione F5 da Yaml = F5 da Yml (disponibile a breve)
= distribuzione ACio da Yaml = F5 da Yaml
Aggiungerò alcune parole su ACY (da non confondere con ACI).
Chi ha lavorato con ACI sa che questo miracolo (e anche in senso positivo) non è stato sicuramente creato dai networker :). Dimentica tutto quello che sapevi sulla rete: non ti sarà utile!
È un po’ esagerato, ma rende grossomodo la sensazione che ho costantemente provato, negli ultimi 3 anni, lavorando con ACI.
E in questo caso, ACY non è solo un'opportunità per costruire un processo di controllo delle modifiche (che è particolarmente importante nel caso di ACI, perché dovrebbe essere la parte centrale e più critica del tuo data center), ma ti offre anche un'interfaccia intuitiva per la creazione della configurazione.
Gli ingegneri di questo progetto utilizzano Excel per configurare ACI invece di YAML esattamente per gli stessi scopi. Ci sono ovviamente dei vantaggi nell’usare Excel:
- il tuo NIP in un unico file
- insegne belle e piacevoli da guardare per il cliente
- puoi usare alcuni strumenti di Excel
Ma c'è uno svantaggio e, secondo me, supera i vantaggi. Controllare i cambiamenti e coordinare il lavoro di squadra diventa molto più difficile.
ACY è in realtà un'applicazione degli stessi approcci utilizzati da terze parti per configurare ACI.
Fonte: habr.com