Questo post sul blog è un capitolo dell’eBook Da Amministratore a DevOps: Il modo migliore per avere successo con DevOps in Azure. Assicurati di dare un’occhiata se vuoi approfondire ciò che serve per avere successo con DevOps in Microsoft Azure imparando l’Infrastruttura come Codice.
Se hai mai creato un’infrastruttura cloud o virtuale su un’infrastruttura locale, saprai che ci sono molte operazioni di clic o di scrittura. L’Infrastruttura come Codice (IaC) si occupa di questo.
Per creare qualcosa, è necessario ricordare quale schermata consultare o quale comando eseguire. Se stai solo sperimentando per imparare Azure, va bene, ma una volta che si passa a processi di produzione critici in cui il tempo è denaro, qualcosa deve cambiare.
Una volta che la tua organizzazione inizia a prendere sul serio la fornitura e la gestione dell’infrastruttura, ti troverai di fronte a molte nuove sfide.
Incontrerai duplicazione inutile del lavoro, casi ripetuti di errori di battitura, problemi di gestione dei cambiamenti, deriva di configurazione e altro ancora. Più grande è l’organizzazione e il team, più grandi sono i problemi. Tutti questi problemi possono essere eliminati o, almeno, mitigati con un concetto chiamato Infrastruttura come Codice (IaC).
Infrastruttura come Codice (IaC): Un esempio
IaC è un termine dell’industria che si riferisce alla memorizzazione di tutto ciò che è necessario per creare componenti dell’infrastruttura nel codice. Di solito, questo codice è definito in file JSON o YAML che rappresentano come dovrebbe essere la tua infrastruttura.
Una volta che tutti i componenti sono definiti in un file strutturato, entra in gioco un altro processo, comprende il codice e inizia immediatamente a utilizzare quel documento come istruzioni per costruire l’infrastruttura.
Per fornire un esempio generico simile a pseudocodice, forse devi creare una VM. Quella VM ha bisogno di risorse come calcolo, archiviazione e networking. Un approccio IaC approssimativo sarebbe descrivere la VM e tutti i suoi componenti in un template.
Il Template
Nel frammento di codice seguente, puoi vedere un esempio di come ogni componente sia suddiviso da una gerarchia con attributi definiti per ciascun componente. Questo esempio immaginario è stato creato in un file JSON che la maggior parte dei servizi chiamerebbe un template.
Questo template definisce la VM e tutti gli attributi associati a quella VM. Ha uno specifico schema a cui gli autori del template devono attenersi per definire l’aspetto di quella VM. Supponiamo che questo template venga quindi salvato in un file chiamato myvm.json.
Controllo del Codice Sorgente
Ora hai tutto ciò che costituisce una VM salvato in un unico file. Come ogni buon professionista DevOps, controlli quel file nel controllo del codice sorgente. Ora hai un modo per tracciare le modifiche al file.
Lo Strumento
Ora che il file è stato creato, hai bisogno di uno strumento o servizio per leggere quel file che capisce ciò che stai cercando di costruire. Quello strumento utilizza il template come input e costruisce la VM secondo quelle specifiche esatte senza altra interazione.
Ottimo, vero? Ma non è tutto.
Combattendo la Deriva di Configurazione
Supponiamo ora che tu debba cambiare l’indirizzo IP statico assegnato all’interfaccia di rete (NIC) di quella macchina virtuale (VM). Potresti eseguire una connessione RDP alla VM e cambiare l’indirizzo IP, ma non vuoi farlo. Perché?
- Stai apportando la modifica manualmente, il che comporta una perdita di tempo ed è soggetto a errori umani.
- Non c’è un registro delle modifiche che indica chi ha cambiato l’indirizzo IP e quando.
- Non c’è un modo automatizzato per ripristinare la modifica nel caso in cui si inserisca un indirizzo IP errato.
L’Infrastructure as Code (IaC) può risolvere tutti i problemi sopra elencati. Con pochi tasti, puoi apportare quella modifica in modo tale che il tuo responsabile e il revisore dei conti ti ameranno.
Apri myvm.json, cambia l’attributo IPAddress, effettua la modifica nel controllo di versione e poi esegui nuovamente il tool. Fatto.
Il tool sarà sufficientemente intelligente da sapere cosa deve essere modificato. Non staccherà la NIC o ricostruirà l’intera VM. Tutti gli strumenti e i servizi di IaC sono sufficientemente intelligenti da comprendere come apportare la modifica. Magia!
Ma ora hai appena realizzato che hai utilizzato l’IP sbagliato e devi tornare indietro. Nessun problema. Ripristina la modifica nel controllo di versione, esegui il commit, avvia il tool e sei di nuovo operativo.
Ma aspetta, c’è di più.
Le basi della consegna continua.
Quando hai l’infrastruttura archiviata nei modelli sotto controllo sorgente, hai un insieme di ingredienti per l’inizio di un rilascio automatizzato o di un pipeline di delivery continuo.
Ricorda che dovevi eseguire quel tool ogni volta che cambiavi il modello. In un flusso di lavoro o pipeline automatizzata, quel tool si avvia automaticamente. Una volta che il processo per creare o apportare modifiche all’ambiente è automatizzato, nel momento in cui committi una modifica al modello, l’infrastruttura si allinea.
Costruisci abbastanza modelli e alla fine, l’intera infrastruttura potrebbe essere rappresentata nel codice o come codice.
Conclusione
L’IaC è una metodologia DevOps che consente alle operazioni di prendere una mossa dal playbook dello sviluppatore software. L’IaC porta molti vantaggi che uno sviluppatore software ha sfruttato per anni e li mette nelle mani dell’amministratore di sistema.
Source:
https://adamtheautomator.com/infrastructure-as-code-iac/