Pillole di Infrastructure as Code con Terraform
In questo articolo spieghiamo a grandi linee gli argomenti toccati nel webinar tenuto poco più di una settimana fa in cui abbiamo parlato di Infrastructure as Code con Terraform.
Qual è il target che di solito un’azienda si pone quando vuole sfruttare al meglio gli ambienti cloud?
Per Criticalcase è quello di arrivare a realizzare il cosiddetto Devops sul multicloud ibrido, ovvero riuscire a raggiungere un livello di automazione in vari ambiti tale da coinvolgere anche le procedure interne all’azienda e le metodologie, per arrivare a un cambio di paradigma che permetta di sfruttare al meglio gli ambienti multicloud.
L’approccio di Criticalcase è un approccio ibrido in quanto agnostici sulle piattaforme cloud.
Partire dall’infrastructure as code, a nostro avviso dovrebbe essere il primo passo che un’azienda deve affrontare, in quanto è il primo step per la realizzazione delle piattaforme.
Infrastructure as code (IaC)
E’ un processo che permette la gestione ed il provisioning di componenti infrastrutturali sia on premise presso data center proprietari o di terze parti sia su Cloud.
Viene realizzato attraverso file di definizione che sono leggibili da un programma come Terraform.
L’infrastructure as a code ha molteplici vantaggi, tra i più importanti:
- Rendere dinamica l’infrastruttura, tanto che possiamo integrare le componenti infrastrutturali in pipeline di devops
- Standardizzare l’infrastruttura, per cui i change a livello di codice infrastrutturali, se applicati tramite IaC, si ripercuotono sulle diverse infrastrutture remote senza rischi di disallineamenti
- Attuare policy di DR
- Avere un punto unico per la vista di tutte le risorse relative ad una piattaforma, che siano SaaS, PaaS, o IaaS
Terraform è un progetto opensource della HashiCorp in grado di gestire qualsiasi piattaforma Cloud disponibile
- Automazione
- Gestione Workflows
- Ecosystem
Avendo un ecosistema molto vasto, è facile approcciarsi al cloud direttamente tramite Terraform, in quanto sono disponibili circa 150 Providers ufficiali o verificati e oltre 800 community.
- UFFICIALI –> sono quelli direttamente gestiti da Terraform
- VERIFICATI –> i fornitori verificati sono di proprietà e gestiti da partner tecnologici di terze parti, ma verificati comunque da Terraform
- COMMUNITY –> i fornitori della comunità sono pubblicati nel registro Terraform da singoli manutentori o altri membri della comunità terraform.
A differenza degli altri sistemi IAC (Infrastructure as code) che nascono con un approccio imperativo, Terraform è uno strumento importante nato con un approccio dichiarativo che permette di rappresentare gli oggetti infrastrutturali.
Questo vuol dire che viene dichiarato quello che deve essere lo “stato finale” dell’infrastruttura ovvero come si vuole che sia l’infrastruttura.
Sarà quindi Terraform, che con i suoi plugin e i suoi fornitori, si occuperà di implementare l’infrastruttura disegnata inizialmente.
- Lo scopo principale del linguaggio Terraform è dichiarare le risorse che rappresentano gli oggetti dell’infrastruttura. Tutte le altre caratteristiche del linguaggio esistono solo per rendere la definizione delle risorse più flessibile e conveniente.
- I file di configurazione (formato HCL) descrivono a Terraform i componenti necessari per eseguire una singola applicazione o l’intero datacenter.
- Terraform genera un piano di esecuzione che descrive cosa farà per raggiungere lo stato desiderato, quindi lo esegue per costruire l’infrastruttura descritta.
- Quando la configurazione cambia, lo stato di Terraform cambia
Da qualche settimana è uscita la nuova versione 1.0 di Terraform che introduce parecchie features come:
- Maggiore interoperabilità tra gli stati di Terraform
- Periodi di manutenzione estesi
- Esperienza di aggiornamento migliorata
BEST PRACTICE
Questa è una lista delle best practice che derivano dall’esperienza che Criticalcase ha avuto con l’utilizzo di Terraform
- MODULI
- Un modulo è un contenitore per più risorse che vengono usate insieme.
- Ogni configurazione Terraform ha almeno un modulo, noto come root module, che consiste nelle risorse definite nei file .tf nella directory di lavoro principale.
- Un modulo può chiamare altri moduli, il che permette di includere le risorse del modulo figlio nella configurazione in modo conciso.
- I moduli possono anche essere chiamati più volte, sia all’interno della stessa configurazione che in configurazioni separate, permettendo alle configurazioni delle risorse di essere impacchettate e riutilizzate.
- È anche molto importante creare dei propri moduli
Noi di Criticalcase abbiamo sviluppato molti moduli per ogni tipo di componente AWS che andiamo ad utilizzare all’occorrenza.
- SCALE
Primo punto da affrontare quando si deve scalare il sistema è la centralizzazione del management dello stato ed il suo lock (se usato da più punti).
- DATA RESOURCES
Le data sources permettono a Terraform di utilizzare informazioni definite al di fuori di Terraform, definite da un’altra configurazione separata di Terraform, o modificate da funzioni.
Ogni provider può offrire data sources insieme al suo set di tipi di risorse.
- EXTERNAL DATA SOURCES
In questo caso non si andrà ad utilizzare una risorsa già presente su Terraform ma si andrà a far eseguire un programma al codice sviluppato.
- PROVISIONERS
Anche se i proprietario di Terraform (HasciCorp) consiglia di non utilizzare i Provisioners se non quando non se ne può realmente fare a meno, con Terraform non è però possibile gestire ogni cosa e quindi si dovrà intervenire sulle macchine remote (se si tratta di Server), oppure eseguire delle azioni locali.
Sono di 3 tipi due dei quali richiedono la connessione ssh ai server:
- Local Exec
- Remote Exec – Via SSH
- File – Via SSH
- DYNAMIC BLOCK
Alcuni tipi di risorse includono nested blocks che possono essere reiterati N volte sui “setting“, che in genere rappresentano oggetti separati correlati (o incorporati all’interno) dell’oggetto contenitore.
Oltre alle best practice, ci sono anche dei WARNING che possono essere riassunti in 3 punti:
- Spazi di lavoro: a volte troppo rischiosi
- Terraform Cloud – Secrets on Cloud – Lock-in
- Registro moduli esterni – Sei veramente consapevole di quello che stai facendo?
Se siete interessati ad approfondire l’argomento, qui di seguito trovate il video del webinar tenuto dal nostro Delivery Manager e Cloud Architect Pasquale Lepera
Se vuoi approfondire qualche argomento in merito al webinar, o se vuoi ricevere le slide che sono state proiettate, contattaci tramite il seguente form.
