Cosa è Infrastructure as Code IaC. L’Infrastructure as code, detta anche IaC, è una pratica IT che codifica e gestisce l’infrastruttura IT sottostante come software. Lo scopo dell’infrastruttura come codice è quello di consentire agli sviluppatori o ai team operativi di gestire, monitorare e fornire automaticamente le risorse, anziché configurare manualmente dispositivi hardware e sistemi operativi discreti. L’infrastruttura come codice viene talvolta definita infrastruttura programmabile o definita dal software.
Il concetto di infrastruttura come codice è simile agli script di programmazione, utilizzati per automatizzare i processi IT. Tuttavia, gli script sono utilizzati principalmente per automatizzare una serie di passaggi statici che vengono ripetuti numerose volte su più server. L’Infrastructure as code utilizza un linguaggio di livello superiore o descrittivo per codificare processi di provisioning e deployment più versatili e adattivi. Ad esempio, le funzionalità di infrastructure-as-code incluse in Ansible, uno strumento di gestione e configurazione IT, possono installare il server MySQL, verificare che MySQL funzioni correttamente, creare un account utente e una password, impostare un nuovo database e rimuovere i database non necessari.
Il processo di automazione dell’infrastruttura basato sul codice (Infrastructure as Code IaC) ricorda molto da vicino le pratiche di progettazione del software, in cui i team di sviluppo controllano attentamente le versioni del codice, le iterazioni di test e limitano la distribuzione fino a quando il software non viene provato e approvato per la produzione.
Vantaggi dell’infrastruttura come codice
I vantaggi associati all’ infrastructure as code sono molti, dall’efficienza dell’automazione alla sua flessibilità nell’allineamento con altre pratiche IT moderne.
Velocità ed efficienza. Il provisioning e la gestione automatizzata sono più rapidi ed efficienti dei processi manuali. Questo vale non solo per le risorse in provisioning e la virtualizzazione, ma anche per i database, la rete, la gestione degli account utente e altri servizi vincolati. L’IaC può anche includere codice che scala automaticamente (aggiunge o chiude ambienti e risorse quando non sono più necessari).
Coerenza. Gli sviluppatori di software possono utilizzare il codice per il provisioning e la distribuzione di server e applicazioni in base alle pratiche e alle politiche aziendali, anziché affidarsi agli amministratori di sistema in un ambiente DevOps. Uno sviluppatore potrebbe creare un file di configurazione per eseguire il provisioning e la distribuzione di una nuova applicazione per l’assicurazione di qualità o per la distribuzione sperimentale, prima che le operazioni prendano il sopravvento per la distribuzione in produzione.
Allineamento con DevOps. Con la configurazione dell’infrastruttura scritta come codice, questa può passare attraverso lo stesso controllo di versione, i test automatizzati e altre fasi di una pipeline di continuous integration e continuous delivery (CI/CD) che gli sviluppatori utilizzano per il codice dell’applicazione. Un’organizzazione può scegliere di combinare l’infrastruttura come codice con i container, che astraggono l’applicazione dall’infrastruttura a livello di sistema operativo. Poiché il sistema operativo e l’infrastruttura hardware vengono forniti automaticamente e l’applicazione è incapsulata su di essi, queste tecnologie si rivelano complementari per diversi obiettivi di distribuzione, come test, staging e produzione.
Nonostante i suoi vantaggi, l’infrastruttura come codice presenta potenziali svantaggi. Richiede strumenti aggiuntivi, come un sistema di gestione della configurazione e di automazione/orchestrazione, che potrebbero introdurre curve di apprendimento e margini di errore. Eventuali errori possono proliferare rapidamente attraverso i server, soprattutto in presenza di un’ampia automazione, per cui è essenziale monitorare il controllo delle versioni ed eseguire test completi di pre-release.
Se gli amministratori modificano le configurazioni dei server al di fuori del modello di infrastructure-as-code impostato, è possibile che si verifichi una deriva della configurazione senza l’uso di strumenti aggiuntivi di gestione delle modifiche. È importante integrare completamente l’infrastruttura come codice nelle pratiche di amministrazione dei sistemi, operazioni IT e DevOps con politiche e procedure ben documentate. Se gli strumenti di sicurezza e monitoraggio esistenti non sono all’altezza di gestire l’infrastruttura come codice, sarà necessario investire in altri strumenti, con formazione e test aggiuntivi per integrarli nei flussi di lavoro.
Un’altra sfida dell’infrastruttura come codice è che gli sviluppatori hanno maggiori responsabilità nel capire come scrivere codice efficiente che si traduca senza problemi negli ambienti di produzione. Devono inoltre possedere una solida conoscenza dei linguaggi utilizzati per l’infrastruttura come codice, indipendentemente dall’implementazione dell’organizzazione, come JSON, YAML, Ruby, C++ o SQL.
Infrastruttura come codice e cloud computing
Il cloud computing condivide una visione di partenza generale con l’infrastruttura come codice: Le risorse IT, come calcolo, storage e networking, sono astratte dall’hardware fisico, legate a servizi aggiuntivi e caricate in istanze che vengono attivate e disattivate a seconda delle necessità.
L’IaC fa un ulteriore passo avanti, per automatizzare questo processo attraverso set di istruzioni predefinite:
- Predisporre le risorse.
- Configurare l’istanza.
- Configurare e distribuire un carico di lavoro nell’istanza.
- Collegare i servizi associati.
- Monitorare e gestire il deployment nel tempo.
Questa profondità di automazione è particolarmente importante a causa della vasta gamma di applicazioni, servizi e funzioni del cloud, impilati insieme e collegati principalmente tramite API. L’ampiezza e la portata del cloud richiedono un processo di governo automatizzato, piuttosto che fare tutto manualmente. Le organizzazioni con il cloud ibrido traggono ancora più vantaggi, in quanto tali configurazioni e risorse modulari possono essere applicati a più ambienti.
Infrastruttura immutabile e mutevole
L’infrastruttura mutabile si riferisce alla pratica per cui i componenti dell’infrastruttura vengono modificati in produzione, mentre il servizio o l’applicazione nel suo complesso continua a funzionare normalmente. L’infrastruttura immutabile assembla e imposta componenti e risorse per creare un servizio o un’applicazione completa. Se è necessaria una modifica per un qualsiasi componente, questi non vengono cambiati o riconfigurati: vengono tutti aggiornati ed effettivamente reinseriti in un’istanza. Una nuova iterazione viene assemblata, testata, validata e lanciata, mentre la vecchia iterazione viene interrotta e le sue risorse rilasciate per il riutilizzo.
L’infrastruttura immutabile ha guadagnato favore soprattutto per gli ambienti cloud e di microservizi, che sono altamente scalabili e coinvolgono molti più componenti e servizi interdipendenti. Qualsiasi aggiornamento una tantum per risolvere problemi specifici può causare una deriva della configurazione che si ripercuote a cascata quando gli aggiornamenti vengono rapidamente portati in produzione. È più efficiente ed efficace ripubblicare insiemi di servizi e componenti immutabili piuttosto che applicare patch e riconfigurare singoli componenti dell’infrastruttura.
Approcci e metodi dell’Infrastructure-as-code
Gli strumenti Infrastructure-as-code possono essere dichiarativi e imperativi.
Un approccio di programmazione dichiarativo delinea lo stato desiderato e previsto dell’infrastruttura, ma non elenca esplicitamente i passaggi per raggiungere tale stato. SQL è un linguaggio di programmazione dichiarativo comunemente conosciuto. I modelli di AWS CloudFormation, tra gli altri, sono scritti nello stile dichiarativo dell’infrastruttura come codice.
Al contrario, un approccio imperativo definisce i comandi che consentono all’infrastruttura di raggiungere lo stato desiderato. I linguaggi orientati agli oggetti, come C++ e Java, possono essere utilizzati per la programmazione imperativa. Uno strumento come Chef può essere usato in modo dichiarativo, ma anche imperativo, se necessario.
In entrambi gli approcci, l’infrastruttura come codice viene configurata su un modello, in cui l’utente specifica le risorse necessarie per ogni server dell’infrastruttura. Il modello viene utilizzato per verificare che un sistema sia configurato correttamente o per inserirlo nella configurazione appropriata. I modelli possono essere costruiti come un insieme di livelli di risorse, come in AWS CloudFormation, che costituisce uno stack.
Strumenti Infrastructure-as-code
Gli strumenti Infrastructure-as-code configurano e automatizzano il provisioning dell’infrastruttura. Questi strumenti possono eseguire automaticamente la distribuzione di infrastrutture, come i server, con funzionalità di orchestrazione. Possono anche configurare e monitorare i sistemi precedentemente forniti.
Gli strumenti Infrastructure-as-code applicano la configurazione dal modello tramite metodi push o pull. Nel metodo push, un server centralizzato invia la configurazione desiderata a uno o più sistemi specifici. Il metodo pull è avviato da una richiesta a un server centralizzato da uno o più sistemi dell’infrastruttura. Gli strumenti sono in genere progettati per default per la distribuzione push o pull del codice, ma possono essere impostati per istanze specifiche per fare l’altro. Questi strumenti dovrebbero anche essere in grado di eseguire il rollback delle modifiche al codice, come nel caso di problemi imprevisti dovuti a un aggiornamento.
Esempi di strumenti Infrastructure as Code IaC sono AWS CloudFormation, Red Hat Ansible, Chef, Puppet, SaltStack e HashiCorp Terraform. Alcuni strumenti si basano su un linguaggio specifico per il dominio (DSL), mentre altri utilizzano un formato di modello standard, come YAML e JSON.
Quando si sceglie uno strumento, le organizzazioni devono considerare la distribuzione di destinazione. Ad esempio, AWS CloudFormation è progettato per il provisioning e la gestione dell’infrastruttura su AWS e funziona con altre offerte AWS. In alternativa, Chef funziona con i server on-premises e con le offerte di infrastructure-as-a-service di diversi cloud provider.
(fonte)
Innovaformazione, scuola informatica specialistica promuove l’approccio IaC e la metodologia DevOps.
Per queste tematiche trovate il Corso Terraform e altri corsi per devops e microservizi QUI.
INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)