{"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 quattro. Automazione. Template","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

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

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

DevOps per la rete<\/h2>\n

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

Quando pi\u00f9 di 5 anni fa, i nostri sviluppatori ci hanno presentato queste proposte, noi, esperti di rete, non eravamo entusiasti.
\n<\/a><\/noindex>
\n\u00c8 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\u00f9 a mio agio lavorando direttamente tramite cli. In questo modo posso vedere rapidamente se qualcosa \u00e8 andato storto e \"annullare\" le modifiche. Tutto ci\u00f2 era in certa misura in contrasto con le loro idee.<\/p>\n

Ci sono anche altre questioni, ad esempio, l'interfaccia del software pu\u00f2 cambiare leggermente da una versione all'altra. Questo, alla fine, porter\u00e0 a uno script che genera una \"configurazione\" errata. Non vorremmo utilizzare 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 questioni siano irrisolvibili. Semplicemente, dicendo \"A\", \u00e8 probabilmente saggio dire anche \"B\" e, se desideri utilizzare gli stessi processi per il controllo delle modifiche che utilizzi nello sviluppo, \u00e8 necessario avere oltre all'ambiente di produzione anche gli ambienti di sviluppo e di staging. Allora questo approccio sembra completo. Ma quanto coster\u00e0?<\/p>\n

Ma c'\u00e8 una situazione in cui i difetti vengono praticamente annullati 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, vedo due fasi distintive in questo progetto. <\/p>\n

Prima fase<\/h3>\n

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

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\u00e0... I test continuavano e continuavano, e mi trovavo gi\u00e0 in una lotta quotidiana e costante con errori, test e documentazione. <\/p>\n

Cos\u00ec \u00e8 andata avanti per un anno. Il progetto, per quanto ne so, non \u00e8 stato semplice per nessuno, ma gradualmente il cliente diventava sempre pi\u00f9 soddisfatto, e questo ha consentito di assumere ingegneri aggiuntivi che potessero prendersi parte della routine.<\/p>\n

Ora si poteva cominciare a guardarsi attorno.
\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 con gli sviluppatori dell'epoca (e devo dare atto, avevamo un ottimo team) \u00e8 che il formato di testo, anche se sembra a prima vista qualcosa dal mondo dei sistemi operativi DOS, possiede una serie di propriet\u00e0 preziose.
\nAd esempio, il formato di testo sar\u00e0 utile se desideri sfruttare appieno i vantaggi di GIT e di tutte le sue derivanti. E io li volevo. <\/p>\n

Tuttavia, potrebbe sembrare possibile semplicemente memorizzare la configurazione o un elenco di comandi, ma apportare modifiche risulta abbastanza scomodo. Inoltre, nella progettazione c'\u00e8 un'altra importante sfida. \u00c8 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.<\/p>\n

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

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

Ora il processo di modifica si presentava nel seguente modo:<\/p>\n