Listino Supporto Partner Contatti 800 13.40.41

KNOWLEDGE BASE

Knowledge Base
× Non sei ancora nostro cliente stellar? Diventa Partner CoreTech e visita il nostro configuratore prezzi

Vai al Video

Infrastructure as a code

Layer dell’automazione: hardware, virtualizzazioni, applicazioni

L’automazione è un poì la chiave per creare la fornitura e l’utilizzo on-demand dell’infrastruttura Cloud e viene abilitata ad ogni livello (layer) attraverso l’API (application layer). Il concetto è ben schematizzato dal diagramma proposto nell’immagine seguente, che mostra i tre livelli: Application Layer, Virtualization Layer e Hardware Layer.

Se pensiamo al Private Cloud dobbiamo pensare anche a come stiamo organizzando l’infrastruttura, perché è ovvio che il Cloud come paradigma dobbiamo anche scontrarci con concetti come la crescita lineare.

Nel caso delle infrastrutture tradizionali, in casa, queste non saranno mai linearmente scalabili perché perché l’incremento delle risorse non potrà avvenire linearmente ma a gradini: per esempio se occorre passare da una capienza di storage a un’altra si compreranno dischi o unità di storage con taglie discrete, fin quando magari occorrerà cambiare il server di storage perché oltre una certa capacità non gestisce. Ciò comporta costi che non crescono linearmente ma a gradini e che talvolta trattengono dall’incrementare una risorsa.

Lo stesso discorso si può applicare alle risorse di calcolo: se serve un processore più veloce occorre cambiare l’intera scheda madre e magari poi questa ha nuovi standard e richiede la sostituzione di schede video o di rete magari costate una fortuna. E allora bisogna cambiare tutta la macchina, il che implica magari acquisire un’architettura non supportata dai software e dai sistemi operativi in uso nell’infrastruttura.

Analogo concetto vale per le risorse di rete, perché, ad esempio, se servono due porte in più e lo switch non le ha, bisogna comperare un ulteriore apparato. 

Con l'avvento dell’iperconvergenza è stata possibile la scalabilità, naturalmente nei limiti di quelle che sono le strutture che andranno a consumare queste risorse.

Vicino al concetto di iperconvergenza vediamo nascere il concerto anche di Blueprints cioè il poter definire come deve essere l’infrastruttura finale a livello, ad esempio, di configurazione di rete, di sistemi di storage ecc. Quindi costruire una ricetta di come dev’essere il sistema e questa ricetta guardacaso può essere già automatizzata (immagine seguente).

Questo può essere ottenuto già dall’introduzione di v-Sphere autodeploy: andando a fornire un po' le linee di base, le linee guida di come deve essere l’infrastruttura, prendiamo un server vuoto, lo connettiamo alla nostra rete questo server entra già automaticamente a far parte dell’infrastruttura. Si tratta di una grande semplificazione perché vuol dire che non è più necessario installare monitor e tastiera, fare l’installazione con la chiavetta USB o con ilCD, tirare su un sistema ESXI, configura l’ESXI e via di seguito, ma si connette il server, lo si accende e tempo 10-20 minuti, mezz'ora (dipende da come è stato strutturato il blueprint) la macchina è pronta.

Questa automazione, alla fine è un po' quello che c'è alla base della gestione dei grandi Service Provider, nei cui data center praticamente non c’è personale tecnico che installa e configura, ma quando servono nuove risorse arriva un tecnico che introduce fisicamente un server nel rack, lo connette, lo accende e va via: il resto lo fa un’automazione che provvede al resto e che megari segnala ai supervisori se qualcosa va storto.

Stiamo parlando di sistemi di infrastrutture in genere, ovviamente VMware ha già di base queste componenti: autodeploy e i famosi ESXI profile.

Sopra l’hardware layer si trova il virtualization layer, che sostanzialmente prevede un'organizzazione dei Tenant; questo significa che una volta che abbiamo delle risorse disponibili e vogliamo renderle utilizzabili, dobbiamo trovare un po' il punto di incontro tra un’infrastruttura fisica e una virtuale e questo significa che costruiamo i Tenant. Anche questi possono essere accompagnati da delle Cloud Definitions, ossia una serie di script.

Se abbiamo abilitato un sistema di virtualizzazione sappiamo che possono essere applicate delle Cloud Definition utilizzando delle API del nostro sistema di virtualizzazione; VMware e v-Sphere vengono forniti insieme a vCenter con una serie di API che possono essere tranquillamente implementate (immagine seguente).

Poi abbiamo l'ultimo step che quello applicativo: spesso questa parte l’abbiamo un po' ignorata, nel senso che tipicamente prendiamo un po' di applicazioni, le carichiamo nella macchina virtuale e via.

Ma volte avete installato la macchina virtuale ancora col vecchio metodo, ossia avete magari implementato il template (avete creato la macchina virtuale template da copiare) e quante configurazioni gli avete definito? Quante volte avete dovuto assistere lo sviluppatore nel delivery delle proprie applicazioni e soprattutto, cosa succede quando arriva kubernetes?

Quindi capite bene che alla fine anche questo livello di automazione merita una certa considerazione e attualmente tale procedimento, ossia l’Application Layer, è automatizzato.

Automazione con v-Sphere

Ma da dove partiamo per implementare l’automazione con v-Sphere? Abbiamo accennato che ci sono delle API, ma anche degli altri componenti che ci servono.

Innanzitutto partiamo da v-Sphere, che già dispone di quasi l’80% degli elementi che ci servono o che comunque possiamo utilizzare sperando di contenere il livello di scalabilità.

Poi dobbiamo affrontare il discorso sulla scalabilità lineare per quello che riguarda lo storage; mettendo a disposizione Vsan, VMware permette anche di andare interagire un poco con lo storage. Tramite queste API possiamo andare a gestire, magari, dei volumi direttamente sulla parte di virtualizzazione soprastante e anche su quella che sarà la parte applicativa.

Con NSX di VMware gestiamo non solo il Virtual Networking, ma tutto lo stack di sicurezza. Si tratta di una cosa sicuramente tassativa se siamo Cloud Provider, ma comunque utile anche in altri ambiti perché possiamo abilitare altri elementi che possano costruire reti sicure, virtuali, protette e interconnesse, non solo tra macchine virtuali ma anche tra container di un sistema Kubernetes.

Quindi partiamo dal livello di base, quindi dal livello hardware e arriviamo al livello più alto, che è quello dei container.

Con l'avvento di v-Spheare 7 ovviamente avremo costruito un altro elemento che sarà quello di gestione della parte Kubernetes.

La realtà e le sfide dell’automazione

Nell’automazione a livello industriale esistono componenti che possono essere riutilizzati e reiimpiegati e che fondamentalmente vanno a consolidare e integrarsi con la realtà aziendale; quindi non è che l’automazione si realizza premuto Invio e lanciando uno script, ma andando a introdurre anche delle condizioni all’interno dell'automazione, perché magari è partito un processo commerciale e questo processo poi è andato integrandosi con l’infrastruttura.

Le sfide che l’automazione pone sono parecchie: innanzitutto quelle delle architetture e degli engine coinvolti, che implicano la presenza di più linguaggi e più interfacce.

L'organizzazione è un’altra sfida: normalmente lo sviluppatore e il sistemista sono due figure che vivono due condizioni di lavoro completamente differenti e farle collaborare in sinergia rimane una sfida, perché se pensiamo a paradigma Dev Ops che oggi è quello più utilizzato, constatiamo che in molte aziende, un po' per convenzione e un po' per cultura o per organizzazione, si fa fatica a introdurre. Purtroppo l’interazione tra queste due figure spesso può diventare un problema.

Peraltro gli sviluppatori, per cultura, non sono in grado di dimensionare una VM ma vorrebbero utilizzare tecnologie come AWS e Kubernetes.

Altre sfide sono poste dai problemi di sicurezza nell’accesso, di policy e gestione delle password, che nell’automazione non sono più come eravamo abituati.

Altro problema è il Time to Project, perché molti progetti richiedono customizzazione e specifici workflow, quindi occorre che l’automazione sia progettata in modo da rendere meno dispendiose queste evenienze.

Automazione a livello applicativo - Configurazione del sistema operativo

Arriviamo a questo punto a capire come automatizzare a livello applicativo: sicuramente l'automazione del livello applicativo implica l’utilizzo di una pipeline e secondo la cultura DevOps box il concetto di CI/CD viene introdotto proprio a livello di cultura.

Quindi abbiamo sviluppato un’applicazione insieme al nostro codice, l’abbiamo messa in un repository GitHub, costruiamo una pipeline Jenkins e questa va a posizionare l’applicazione  all'interno di un registry interno o un Docker Hub esterno. Pertanto, oggi Jenkins risolve la parte CI/CD verso la parte Kubernetes (immagine seguente).

Per quanto riguarda il sistema operativo, costruire una macchina partendo da un template è veramente facile; la possiamo scriptare, ma come facciamo a configurare a livello di sistema operativo tutti i sistemi? E come possiamo dare uno strumento anche gli sviluppatori o comunque ai DevOps per poter configurare le loro macchine virtuali quando le macchine virtuali stesse vengono messe a disposizione?

Sicuramente non possiamo coninvolgere ancora il sistemista, perché significa fargli perdere del tempo, perché queste cose oggi non sono più un argomento che va seguito a mano ma va scriptato e va messo in qualche modo a disposizione.

E allora vediamo come fare: abbiamo un nostro repository  a queste riposi c'erano dei fogli sono file di configurazione che vengono “mangiati” da sistemi come Puppet, CHEF o come Ansible ma ce ne sono anche altri; questi vanno a rilasciare la nostra configurazione all’interno delle nostre VM  (immagine seguente).

Un'altra metodologia è quella di costruire degli script di automazione che vanno a pushare configurazione oppure gli script già presenti nelle macchine virtuali si configurano sulla base di quello che è il loro scopo all’interno dell’infrastruttura.

Nell’immagine seguente vediamo i concetti di Scripted Configuration e Desired State of configuration: nel primo caso abbiamo uno script che esegue una serie di istruzioni per configurare la macchina. Il secondo invece è una modalità un po' più dichiarativa nella quale definimao come dovrebbe essere il sistema finale e la macchina virtuale trova il modo di realizzarlo

Infrastrucuture provisioning - Approccio imperativo e approccio dichiarativo

Quando parliamo di Infrastructure Provisioning intendiamo che esistono due approcci: uno imperativo, dove uno script contiene una sequenza di istruzioni, con cicli, metodi ecc. con cui si vanno a configurare macchine e fare tante cose come anche deployare l'applicazione direttamente, magari quelle tradizionali, utilizzando una sequenza d’istruzioni.

Noi possiamo gestire le cosiddette eccezioni a questa sequenza, ma questo diventa un argomento a cavallo tra i sistemisti e sviluppatori perché è ovvio che un sistema di questo tipo presuppone che quando scriviamo degli script siamo competenti nel linguaggio del linguaggio che stiamo utilizzando.

Nell’ambito Wmware, sicuramente l'avvento di Power CLI è stato un grande aiuto per i sistemisti che volevano cominciare ad automatizzare dei processi; attenzione che l'approccio presuppone comunque il fatto che si esegua una sequenza.  Ma Power CLI ci dà anche comunque una serie di strumenti che sono derivati comunque dalla piattaforma origine di Power CLI, che è PowerShell, la quale permette di scriptare all'interno un po’ di tutte le infrastrutture, dato che non è limitata a sistemi Microsoft perché può essere utilizzata anche in Linux, per esempio.

Un esempio di approccio dichiarativo è lo script seguente:

$vc = connect-viserver $vcenter -User $vcenteruser -Password $vcenterpw

New-VM -RunAsync:$VM_create_async -Name $VM_Name -ResourcePool

$Cluster -numcpu $numcpu -MemoryMB $MBram -DiskMB $MBguestdisk -

DiskStorageFormat $Typeguestdisk -Datastore $Datastore -GuestId $guestOS -

Location $Folder

if ($VM_power_on) {

write-host “Power On of the VM $VM_name initiated" -foreground green

Start-VM -VM $VM_name -confirm:$false -RunAsync

L’altro approccio all’Infrastructure Provisioning è quello dichiarativo e consiste in un design di infrastruttura e un engine che realizza lo stato desiderato dei sistemi. Qui entriamo nel vivo dell’Infrastructure as a Code: descriviamo il sistema e la sequenza delle operazioni è affidata all’engine e comunque al sistema che abilita l’IaaC; questo, nel caso di Terraform è Terraform stessa, ma possiamo citare AWS Transformation, che è un altro sistema che attraverso l’approccio dichiarativo, dato un particolare codice va ad applicarlo e a costruire delle risorse.

La cosa importante da notare è che tramite questo approccio dichiarativo andiamo a descrivere l’infrastruttura e andiamo a consegnare uno strumento importante e potente anche allo sviluppatore.

Un esempio di approccio dichiarativo con terraform è la descrizione seguente:

resource vsphere_virtual_machine "allvms" {

for_each = var.vms

resource_pool_id = data.vsphere_compute_cluster.this[each.key].resource_pool_id

datastore_id = data.vsphere_datastore.this[each.key].id

name = each.value.vmname

num_cpus = 2

memory = 1024

guest_id = data.vsphere_virtual_machine.template[each.key].guest_id

scsi_type = data.vsphere_virtual_machine.template[each.key].scsi_type

cdrom {

client_device = true

}

network_interface {

network_id = data.vsphere_network.this[each.key].id

adapter_type

= data.vsphere_virtual_machine.template[each.key].network_interface_types[0]

}

}

I principi dell’Infrastructure as a Code

L’IaaC serve a gestire e provvisionare Data Center attraverso una definizione di file leggibili dalle macchine, che possono sia riguardare l'hardware fisico, sia entrare a far parte di quelli che sono strumenti di configurazione Internet; questo con il codice alla fine è possibile definire provvisionare tutte le infrastrutture e non solo le macchine virtuali.

Attraverso il codice è possibile:

  • definire e provvisionare gli elementi costituenti l’infrastruttura, che non sono solo VM ma anche reti virtuali, per esempio;
  • definire e provvisionare le configurazioni tramite l'integrazione con diversi tool;

definire e fornire servizi e piattaforme attraverso Cloud multipli;

  • codificare l’intera infrastruttura o muovere le applicazioni e deployandole con parametri specifici di determinati ambienti e Cloud.

Per quel riguarda definire e provvisionare la configurazione di una macchina virtuale, prendiamo l'esempio di Puppet, che tramite il sistema Iera definisce fondamentalmente tutti gli elementi della configurazione voluta e ci permette di andare a provvisionare le configurazioni ma su una sola VM, fermo restando che tutte le macchine che “sentono” di appartenere a quella configurazione lo fanno già in automatico. Quindi è un bel livello di automazione. 

Terraform cos'è e quali le sue potenzialità

Arriviamo dunque a Terraform: nato da HashiCorp (https://www.hashicorp.com/), introduce un unico linguaggio per il provisioning e la gestione di ogni tipo di Cloud, infrastruttura o servizio. Insieme ad altri prodotti Hashicorp quali Consul, Vault e via di seguito completa le proprie funzionalità per integrare elementi enterprise e workflow.

Terraform è reso disponibile in due modalità: CLI (per enterprise) e Cloud; la prima è gratuita, mentre la parte Cloud è a pagamento. L’interfaccia di Terraform Cloud è proposta nell’immagine seguente.

Invece l’attività con la versione CLI è qualcosa di simile alla schermata seguente; Terraform CLI è disponibile per Windows, Linux e Mac. In questo tutorial vediamo come si lavora con Terraform CLI.

 

Vediamo dunque come iniziare, premettendo il concetto che il tool è ready-to-use, quindi per utilizzarlo basta scaricare la CLI. Il workflow che descrive l’inizio con terraform è quello qui di seguito.

 

In pratica una volta scaricata la versione d’interesse e installata, impartite il comando:

Terraform -Help

per vedere che tutto sia stato installato in maniera corretta. Possiamo anche accedere alla guida del caso. Poi possiamo andare a rilasciare la nostra prima applicazione.

Ora, installando nel vostro PC la suite di Docker e costruendo un semplicissimo file d’esempio che si chiama main.tf (immagine seguente), potete deliverare finalmente la vostra risorsa.

Quindi la risorsa alla fine che cos'è è né più né meno l'elemento fondamentale infrastrutturale del mio Infrastructure as a Code. Nel listato qui sopra abbiamo due risorse: una è la docker_image e l’altra la docker_container. La Docker Image è l’immagine che verrà utilizzata all’interno dell’ambiente Docker

La seconda è la fase di app di RAM del container definito con un nome (“tutorial”) e con delle porte (internal ed external).

Ad ogni modo, gli step per iniziare a lavorare sono:

  • terraform.ini per inizializzare l’ambiente;
  • terraform apply per deliverare l’ambiente (l’applicazione) ossia per eseguire il codice infrastrutturale;
  • test app per testare l’applicazione;
  • terraform destroy, ossia la fase finale una volta testata l’applicazione, consistente nel riportare allo stato originale ogni sistema.

Terraform - Sintassi e organizzazione dei file

Vediamo ora la sintassi richiesta dalla linea di comando. In Terraform le risorse sono un po’ l’elemento fondamentale e ogni risorsa è composta da particolari elementi che sono il tipo di blocco (che in questo caso è la risorsa, il nome della risorsa e alla fine l'etichetta della risorsa.

Ogni resource block descrive uno o più oggetti dell’infrastruttura, come reti virtuali, istanze di calcolo, o componenti di livello più elevato come record DNS. Il nome della risorsa dipende da cosa contiene e quindi dai cosiddetti provider, i quali sono realizzati con GO e non sono nient'altro che tutta una serie di sviluppi che sono stati fatti intorno a Terraform per fare in modo che esso interagisca con gli altri elementi attraverso API.

Nel caso di VMware, esiste un provider illustrato qui di seguito che mette a disposizione delle risorse, le quali possiamo considerare un po' come metodi di un grande oggetto che è VMware.

All’interno delle risorse si trovano degli identificatori, degli argomenti (gli argomenti assegnano un valore a un nome) che sono specifici della risorsa: un po' come la funzione e gli argomenti, oppure l’oggetto e gli attributi dell’oggetto.

Vedete che come linguaggio è molto semplice. Le espressioni sono definite all'interno della risorsa e queste costruiscono altri elementi dinamici.

Notate che nell’esempio le risorse non sono descritte, nel resource pool id così come sono all'interno del vCcenter perché altrimenti non si automatizza nulla, ma casomai attraverso comunque un sistema di variabili (le variabili d’ambiente) e quindi la parte variabile del sistema, bisogna prelevare un particolare oggetto che all'interno di questo ciclo corrisponde al pool id.

Normalmente negli script ci si aspetta che sia rispettato un ordine di esecuzione, invece nell’Infrastructure as a Code l’ordine non conta, come in tutti i modelli dichiarativi; ciò significa che tutte le risorse, se non diversamente specificato, assumono la stessa priorità. Quindi se in un sistema IaaC c’e una sequenza di risorse per dipendenza, bisogna andare a specificare una dipendenza. Questo è molto importante perché si tratta di sistemi dichiarativi e descrittivi, cioè non sono dei workflow; lo diventano solo se andiamo a stabilire un ordine.

I Moduli sono qualcosa che si intreccia con il concetto di risorsa, in quanto sono container dedicati a più risorse utilizzate insieme.

I Blocchi sono invece dei container dedicati ad altri contenuti e solitamente rappresentano la configurazione di qualche tipo di oggetto, come una risorsa (un esempio è proposto qui di seguito).

La Expression rappresenta un valore, che può essere letterale oppure facendo riferimento e combinando altri valori.

I provider, come dice il termine, mettono a disposizione delle risorse e sono i costrutti primari che vengono utilizzati da Terraform. Mentre le risorse sono i costrutti primari nel linguaggio Terraform, i loro comportamenti dipendono dai tipi di risorsa associati, i quali a loro volta vengono definiti dai provider.

Un esempio scritto in Terraform è proposto qui di seguito:

e riguarda vSphere; come vedete non vengono scritti lo username e la password del server. Questo perché nei modelli astratti la componente dichiarativa è una cosa e la componente variabili, che poi dipende dall’ ambiente, è un’altra. Nel caso specifico, in realtà ci sono delle interazioni con altri sistemi per quanto riguarda proprio la gestione degli username e delle password, quindi si dà allo sviluppatore uno strumento ma senza dichiarare i rispettivi valori; questo perché l’interazione con Terraform permette di gestirli in maniera trasparente.

Sintassi e organizzazione dei file - Files e State files

In Terraform sono contemplate due macro-categorie di file: la prima è quella dei file che descrivono ossia il codice descrittivo dell’infrastruttura e sono:

  • tf;
  • tf (e Terraform.tfvars)
  • tf and other custom files 

La seconda categoria è quella de gli State files, ovvero i file i stato:

  • tfstate
  • tfstate.backup

I file variables servono per esternalizzare le variabili, in modo da dare un ordine all’insieme; ciò non toglie che in realtà con la presenza del file main.tf si può fare già tutto, nel senso che possiamo mettere le variabili nello stesso file main.tf. Chiaro che più cose si riesce a portare in altri file specifici, meglio è perché si hanno file main.tf più snelli e quindi più facili da manutenere. Di seguito è proposto un esempio di file variables.

 

Idem per file data, che possono contenere dati specifici, ad esempio, dell’ambiente vSphere.

Quindi più l’infrastructure code è separato in tanti file, più è facile gestirlo, così come quando occorre fare una modifica la facciamo su un file specifico e non sull’insieme.

Vediamo i file Terraform tfvars che contiene le variabili e sono sostanzialmente la dichiarazione variabili; queste variabili rientrano un po' in quelle che sono le specificità dell’ambiente, quindi che tipo è, quali sono le password usate per accedere ecc. Come già spiegato, in realtà Terraform supporta e consiglia di utilizzare dei sistemi per la gestione delle password che non preveano la scrittura delle stesse in chiaro all’interno dei file, per ovvie ragioni di sicurezza.

Andiamo alla seconda categoria di file Terraform che sono un pochino più nascosti: i tfstate. I file di stato si spiegano col fatto che ogni volta che lavoriamo con Terraform esso registra uno stato, quindi se due persone lavorano su un file di Terraform in un lavoro di gruppo, ogni soggetto coinvolto avrà uno stato. Quindi se entrambi lavorano lo stesso file si verifica un duplicato delle risorse; nel caso più sfortunato, se i due utenti hanno specificato anche un IP address si troveranno anche con un conflitto di IP.

Quindi l’importante quando si lavora in gruppo è che determinati file devono essere condivisi con tutti e fare in modo che tutti quanti li vedano per evitare proprio questa cosa; e occorre evitare che tutti non vadano a deliverare le stesse risorse. Possono condividere il file Terraform ma quello che sicuramente va a creare la specificità dell’ambiente sono in tfvars.

Allora vediamo qualche esempio di file main:

In questo file main vedete la descrizione delle risorse, il pool_id, la memoria, il numero di CPU; come accennato, questa cosa la possiamo far diventare un po' estrarre, ossia farla diventare le variabili di input.

Andiamo avanti e vediamo un esempio di file di variables:

Qui trovate le variabili e potete definire dei default, sebbene questi non sia obbligatori; anche qui abbiamo la possibilità di andare a dichiarare delle variabili che poi verranno utilizzate all'interno dei profile.

Notate che sebbene appaiano le credenziali, ovvero i loro riferimenti, non sono palesati ma rimandati (string) a un file tfvars come quello qui di seguito:

Qui si definiscono altri elementi e variabili, ma si può anche andare definire in server DNS: per esempio in domain_env troviamo IP address, server DNS e nome dominio; queste variabili valgono per tutti, cioè non per tutti i sistemi deliverati all'interno del Terraform file ma per tutti i sistemi che verranno deliverare nello stesso ambito.

Variabili di input, variabili di output e variabili locali - Architettura

Giunti a questo punto possiamo definire variabili di input, variabili di output e variabili locali: le prime servono da parametri per i moduli Terraform, consentendo di customizzare aspetti dei moduli senza alterare il codice sorgente dei moduli stessi e consentendo la condivisione dei moduli fra varie configurazioni. Le variabili locali sono confinate nell’ambito del modulo, mentre le altre possono concatenarsi tra moduli.

I valori di uscita sono come i valori ritornati di un modulo Terraform ed hanno vari utilizzi:

  • un modulo figlio può utilizzare gli output per esporre un subset degli attributi delle proprie risorse ad un modulo genitore;
  • un modulo root può utilizzare gli output per stampare determinati valori nell’output CLI dopo aver eseguito l’applicazione Terraform;
  • quando si utilizza il remote state, l’uscita del modulo root può essere acceduta da altre configurazioni attraverso la risorsa terraform_remote_state data source.

Un valore local assegna un nome a un’espressione, permettendone l’utilizzo più volte all’interno di un modulo senza ripeterlo.

Tutti i modelli dichiarativi ma comunque tutti i modelli Infrastructure as a Code devono essere trattati alla fine come se fossero sistemi di variabili di input e output; le variabili di output di un modello possono a loro volta essere l’input di un altro, di un modello successivo, quindi è possibile  a concatenare i modelli dichiarativi.

Questo avviene per esempio con sistemi come AWS Cloud Formation con la quale di definisce uno strato di base strutturale sopra il quale si vanno a definire gli altri elementi; con terraform può essere fatto lo stesso, quindi si definisce come dev’essere il nostro Virtual Environment. Per esempio abbiamo acquistato una risorsa Cloud sulla quale non abbiamo macchine virtuali ma c’è Terraform: definiamo le reti, gli storage ecc e questi producono variabili di output e ciò che queste producono potrebbe diventare l’input di un altro modulo che verrà costruito dagli sviluppatori. Ciò permette di limitare l’attività degli sviluppatori al loro ambito, senza che possano alterare il lavoro del sistemista e che accedano o conoscano le proprietà della rete.

Proviamo a vedere un esempio di infrastruttura virtuale organizzata in ambienti: abbiamo un ambiente di produzione ed uno di management separati da un firewall; ci serve un repository GitLab in cui inserire il codice, una macchina di deploy (opzionale per la piena automazione) e una VM Template (Vanilla).

Notare che GitLab non è semplicemente un bucket di codice ma anche degli elementi di automazione che possono fare in modo che al momento in cui si consolida il codice (che si fa un push) si possono scatenare dei processi, che hanno come variabile di input i file Terraform, il tfvars e altri elementi a contorno e questa macchina qui fondamentalmente fa da Runner, cioè è la macchina con installata la Terraform CLi e applicherà il modello.

Nello specifico non ci servirà costruire un template perché utilizzeremo Vanilla, che è una Cloud Image utilizzabile direttamente all'interno della macchina di produzione spoglia di qualsiasi configurazione, perché la logica dell’IaaC è che siamo noi tramite il codice ad applicare la configurazione.

Costruire una macchina virtuale

Spieghiamo adesso come si costruisce una VM partendo dalle configurazioni preliminari.

Per costruire una VM tramite automazione si parte da un template e si costruisce tutta la relativa configurazione in un progetto Terraform, quindi si arriva alla fase cruciale, nella quale il template viene clonato sul target, ovvero si esegue il clone di tutto il sistema operativo; attenzione che non si va a clonare la macchina virtuale compresi i dischi e cosa in genere ma il sistema operativo.

La parte di codice contenente ’istruzione di clonazione è:

 

clone {

            template_uuid = data.vsphere_virtual_machine.template.id

}

Passiamo all’avvio della console e del comando Terraform init

Integrazioni con Cloud-init e vSphere

Terraform consente l’integrazione con Cloud-init e vSphere. Cloud-init è un’interessante soluzione industriale per la distribuzione di risorse computazionali sulle infrastrutture dei maggiori Cloud Provider, inclusi i Cloud Privati; in essa IP address, utenti, pacchetti e via di seguito vengono applicati nella configurazione senza bisogno dell’interazione  con l’utente e perciò in maniera automatica. Quindi è un elemento chiave per automatizzare il delivery di istanze in Cloud.

Cloud Init è diventato di fatto lo standard di molti sistemi di virtualizzazione compreso di vSphere; l'unico problema su vSphere è che può essere implementato a livello di API, ma Cloud Init nella sua gestione complessiva è composto da altri elementi che sono oltre che quello che chiamiamo Cloud Config, il Metadata Config e User Config che non sono nient'altro che la parte di configurazione di KickOff relativa a quello che è il sistema.

Un esempio di Cloud Config è quello riportato di seguito.

Ecco invece un esempio di Metadata Config:

Quindi questi tre elementi contengono la configurazione degli ambienti a livello di sistema, per esempio a livello di indirizzi IP (immagine precedente) e poi finalmente ai arriva alla definizione di quello che vogliamo installare sulla macchina: un esempio è quello di seguito riportato.

 

Ora, come facciamo a integrare questo sistema con Terraform? La domanda sorge spontanea perché se abbiamo un sistema che mi definisce quello che è il livello infrastrutturale ma non entra nel merito della configurazione, come si fa a coniugarli? Ebbene, l’integrazione è specifica per ogni provider ed è permessa da appositi strumenti; utilizzando le proprietà vApp properties è possibile definire gli user-data con uno script KickOff per Cloud Init. Con la seguente implementazione VMware guestinfo è possibile definire gli user-data (User Config) e i metadati (Metadata Config).

 

Le vApp attraverso le proprie userdata permettono di andare a prelevare un file (nel caso dell’esempio seguente lo chiamiamo Cloud.init)  che contiene al suo interno un'implementazione che ha fatto VMware reperibile nel Git pubblico di VMware, che abilita altri moduli che si chiamano extra_config utilizzando due proprietà.

Utilizzando delle proprietà, che in questo caso sono quattro, presenti all'interno della macchina virtuale (contenenti le definizioni della VM chiamate guestinfo) è possibile eseguire ulteriormente gli script di Cloud Init.

Riepilogando, il primo passaggio è inserire, tramite vApp, la variabile user-data che contiene l’istruzione per scaricare dal repository pubblico il componente aggiuntivo; notare che in ambito Enterprise potrebbe essere magari clonata in locale e poi a sua volta presa attraverso un indirizzamento locale in una deployer machine).

Successivamente attraverso l'utilizzo di questi guestinfo metadata e userdata, anch'essi valorizzati da due file (rispettivamente metadata.yaml e userdata yaml), costruiscono le altre componenti: le definizione dell’IP e la definizione finale dello username.

Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft