Infrastructure as Code con Terraform

di , in DevOps,

Senza buttare uno sguardo al passato, è evidente che la trasformazione digitale che stiamo vivendo, soprattutto in ambiti legati al cloud, sia senza precedenti. È sempre più importante, infatti, stare al passo con i tempi, adottare tecniche innovative di sviluppo ed essere pronti a soddisfare tutte le richieste che arrivano dagli utilizzatori del nostro software, che sono sempre più esigenti.

Indipendentemente dal fatto che si parli di startup o di enterprise, la trasformazione digitale e in generale il cloud computing ha avuto grossi impatti su come compiliamo il software, come lo distribuiamo, come lo rendiamo accessibile su scala globale, come lo rendiamo scalabile e fruibile da milioni di persone.

Pensandoci bene, soprattutto in ambito corporate, richiedere un server in più per distribuire una nuova applicazione web o per allocare nuove virtual machine era un'operazione che richiedeva potenzialmente settimane: si passava dalla richiesta iniziale con la definizione dei requisiti, passando per la revisione del budget, approvazioni da parte di manager di vario titolo per arrivare, solo giorni (o peggio settimane) dopo, a comprare l'hardware necessario per fare il vero e proprio provisioning e configurazione dell'infrastruttura richiesta.

Quello che fino a qualche anno fa era fantascienza, oggi è standard: per fare il provisioning di un nuovo server o di un database ci basta fare un paio di click in Azure (o in una qualsiasi altra piattaforma) e nel giro di secondi (o peggio minuti) abbiamo tutto ciò che ci serve, disponibile ovunque nel mondo e con protezione dei dati.

Infrastructure as Code

Effettuare uno spin-up rapido delle risorse tramite UI dei cloud vendor ha indubbiamente portato un sacco di vantaggi nel modo in cui lavoriamo. Ad esempio:

  • Non dobbiamo più aspettare i tempi necessari per l'acquisto di hardware, quindi possiamo essere più veloci nel creare le infrastrutture richieste, senza passare da vendor dedicati (IBM, Dell, etc.);
  • Non dobbiamo assumere personale specializzato nel setup hardware ma, al contrario, possiamo riciclare le competenze DevOps;
  • Possiamo fare a meno di acquistare un datacenter on-prem e spendere milioni di euro per la loro configurazione e mantenimento (gestione, configurazione, backup...);
  • Non dobbiamo necessariamente buttare via le procedure che abbiamo definito con le conoscenze pregresse;
  • L'alta affidabilità (con protezione dei dati) e disponibilità sono spesso garantiti seguendo determinati standard e best practice.

Per quanto facile sia andare verso il cloud e creare risorse con un semplice click, il processo è ancora manuale e, in quanto tale, ancora potenzialmente soggetto ad errori umani. Inoltre, può essere difficile conoscere l'intera infrastruttura di una realtà grande come quella aziendale e capire come far scalare delle istanze di un determinato servizio tenendo la stessa configurazione delle precedenti già deployate, spesso la documentazione è introvabile e così via. I vantaggi derivanti dal cloud favoriscono certamente un'evoluzione, ma introducono anche nuove problematiche che dobbiamo risolvere.

Per cercare di risolvere tutti questi problemi nasce Infrastructure as Code (IaC).

"Infrastructure as code is an approach to managing IT infrastructure for the age of cloud, microservices and continuous delivery." – Kief Morris, head of continuous delivery for ThoughtWorks Europe.

Fare Infrastructure as Code significa, come detto giustamente nella citazione riportata, essere più agili nel fare il provisioning e nel gestire tutta l'infrastruttura. Questo può essere fatto seguendo un approccio semplice ma funzionale: tutta l'infrastruttura è descritta e definita esattamente come il software e, pertanto, questa può adottarne tutti i benefici, tra cui:

  • Mantenere lo stesso ciclo di vita: l'infrastruttura cambia in base al software, ad esempio in un passaggio tra .NET Framework e .NET Core potrei voler dei server Linux anziché Windows per poter risparmiare sui costi ed avere performance migliori;
  • Automatizzare tutto il processo di provisioning e de-provisioning, con configurazione e minimizzazione dei rischi: utile in scenari di ambienti non-multitenant in cui dobbiamo replicare la stessa infrastruttura e configurazione su N clienti e quindi eliminarla quando questa non ci serve più, oppure quando vogliamo replicare fedelmente un ambiente di produzione;
  • Velocità e semplicità di provisioning: non servono ulteriori conoscenze sistemistiche o persone dedicate, ma essendo tutto definito tramite codice anche gli sviluppatori possono sistemare la configurazione a loro piacimento e farla scalare quanto necessario. Essendo tutto costruito come script, il deploy richiederà lo stesso tempo che richiede nel fare il deploy direttamente sul portale di Azure (o di altri vendor) a meno della configurazione (manuale o automatica);
  • Documentazione: il codice se scritto bene è auto-descrittivo, ma nel caso in cui non lo sia la documentazione può essere definita insieme all'infrastruttura, così che non sia centralizzata in un dipartimento IT, piuttosto che nella testa di una sola persona;
  • Verifica e validazione: seguendo lo stesso ciclo di vita del software (ALM), si possono applicare gli stessi meccanismi di security e validazione tramite pull request, code review e test pre-deployment;
  • Versionamento: essendo definita come codice, anche l'infrastruttura può seguire git o un qualsiasi altro sistema di source control e quindi può avere un suo numero di versione, così che si possa fare rollback, ad esempio, per un deploy non andato a buon fine;
  • Distribuzione come template: potenzialmente tra una infrastruttura ed un'altra cambiano solamente dei parametri di ingresso, ma le basi architetturali sono le stesse, per cui può venire comodo creare e riutilizzare dei template (anche di terze parti);
  • Riduzione dei costi: meno intuitivo, ma qualsiasi sistema di IaC può essere integrato in un sistema di verifica dei costi (ad esempio con Azure Pricing) che, quindi, può fare l'analisi prima dell'introduzione di una change e fare una validazione con le policy aziendali per mantenere i costi bassi. In alternativa all'analisi proattiva, possiamo fare un'analisi a posteriori ed eliminare facilmente le risorse che non utilizziamo più perché non più fondamentali.

I benefici, come abbiamo visto, sono innumerevoli e non si fermano qui, ma per questi invitiamo ad approfondire l'argomento poiché i vantaggi dipendono anche dal luogo target in cui fare il deployment.

Come approcciamo il tema di Infrastructure as Code? Nonostante possa sembrare strano, come abbiamo già visto più volte per DevOps, la parte più complessa è sempre il cambio di mindset per approcciare questa nuova modalità di lavoro, mentre la parte tecnica è, invece, la più semplice. All'interno dell'articolo cercheremo naturalmente di far emergere la componente tecnica, nella speranza che questo possa aiutare a capire il perché sia comodo sfruttare meccanismi di questo tipo e ci auguriamo che il mindset verrà di conseguenza.

Se guardiamo tutto il landscape dei tool disponibili, spaziamo tra Chef, Puppet, Ansible, CloudFormation e moltissimi altri. Se guadiamo il panorama Microsoft-oriented, ci sono diversi strumenti che ci permettono di definire l'infrastruttura come codice in Azure:

  • ARM è la definizione dell'infrastruttura sottoforma di file JSON creata da Microsoft e utilizzata per fare il deployment delle risorse tramite Resource Manager;
  • Bicep, creato sempre da Microsoft e attualmente rilasciato in preview (e non ancora finalizzato nella sintassi) che pone l'obiettivo di rimuovere la complessità di ARM con una definizione più semplice.

Bicep è ancora in fase di definizione del linguaggio, pertanto è molto difficile poterne parlare ora. Tuttavia, esiste Terraform, che si pone esattamente a metà tra i tool "generalisti" e quelli Microsoft, che fa uso di un linguaggio custom, chiamato HCL, adatto per qualsiasi esigenza e il cui provider per Azure è sviluppato proprio da Microsoft.

4 pagine in totale: 1 2 3 4
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

Infrastructure as Code con Terraform 1010 4
| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

Articoli via e-mail

Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!

In primo piano

I più letti di oggi

In evidenza

Misc