{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Come prendere il controllo della rete. Capitolo quarto. Automazione. Template","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Questo articolo \u00e8 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. qui<\/a><\/noindex><\/i>.<\/p>\n

Lasciandomi alle spalle alcuni argomenti, ho deciso comunque di iniziare un nuovo capitolo.<\/p>\n

Torner\u00f2 alla sicurezza pi\u00f9 avanti. Qui voglio discutere un approccio semplice, ma efficace, che sono sicuro, in un modo o nell'altro, pu\u00f2 essere utile a molti. \u00c8 pi\u00f9 una storia breve su come l'automazione pu\u00f2 cambiare la vita di un ingegnere. Parleremo dell'uso dei template. Alla fine, c'\u00e8 un elenco dei miei progetti dove puoi vedere come tutto ci\u00f2 che \u00e8 descritto qui funziona.<\/p>\n

DevOps per la rete<\/h2>\n

\nCreazione 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.<\/p>\n

Quando pi\u00f9 di 5 anni fa, i nostri sviluppatori sono venuti da noi, dai network engineer, con queste proposte, non eravamo entusiasti.
\n<\/a><\/noindex>
\nDevo 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\u00f9 a mio agio lavorando direttamente tramite cli. Cos\u00ec posso vedere rapidamente se qualcosa non va e \"annullare\" le modifiche. Tutto ci\u00f2 era in qualche modo in contrasto con le loro idee.<\/p>\n

Sorgono anche altre domande, ad esempio, da una versione all'altra del software, l'interfaccia pu\u00f2 cambiare leggermente. Questo, alla fine, porter\u00e0 al fatto che il tuo script creer\u00e0 una \"configurazione\" errata. Non mi piacerebbe usare l'ambiente di produzione per \"testare\". <\/p>\n

Oppure, come capire che i comandi di configurazione sono stati applicati correttamente e cosa fare in caso di errore?<\/p>\n

Non voglio dire che tutte queste domande siano senza risposta. Semplicemente, dopo aver detto \"A\", \u00e8 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\u00e0?<\/p>\n

Ma c'\u00e8 una situazione in cui gli svantaggi si annullano praticamente, e rimangono solo i vantaggi. Parlo di lavori di progetto.<\/p>\n

Progetto<\/h2>\n

\nNegli 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\".<\/p>\n

Personalmente, ci sono due fasi chiaramente definite in questo progetto. <\/p>\n

Prima fase<\/h3>\n

\nNel 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. <\/p>\n

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\u00ec mancava una lettera nel nome, qui era stata omessa una riga nel comando\u2026 I test continuavano e continuavano, e mi trovavo costantemente in una lotta quotidiana con errori, test e documentazione. <\/p>\n

Cos\u00ec \u00e8 andato avanti per un anno. Il progetto, per come lo capisco, non \u00e8 stato semplice per nessuno, ma gradualmente il cliente diventava sempre pi\u00f9 soddisfatto, e questo ha permesso di prendere ingegneri aggiuntivi, che potevano prendersi parte della routine.<\/p>\n

Ora era possibile guardarsi intorno.
\nE questo \u00e8 stato l'inizio della seconda fase. <\/p>\n

Seconda fase<\/h3>\n

\nHo deciso di automatizzare il processo.<\/p>\n

Quello che ho capito dai colloqui di allora con gli sviluppatori (e va dato atto, avevamo un team forte) \u00e8 che il formato di testo, anche se sembra a prima vista qualcosa dal mondo del sistema operativo DOS, possiede una serie di qualit\u00e0 preziose.
\nAd esempio, il formato di testo sar\u00e0 utile se desideri sfruttare appieno i vantaggi di GIT e di tutte le sue derivazioni. E io volevo. <\/p>\n

Beh, sembrerebbe che si potrebbe semplicemente utilizzare un file di configurazione o un elenco di comandi, ma apportare modifiche \u00e8 piuttosto scomodo. Inoltre, durante la progettazione c'\u00e8 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.<\/p>\n

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 \u00e8 fondamentalmente un riflesso del LLD. <\/p>\n

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\u00f2 \u00e8 stato caricato sul repository aziendale GitHub.<\/p>\n

Ora il processo di cambiamento appariva nel seguente modo:<\/p>\n