Studente/i
Elia Oggian
RelatoreAngelo Consoli
CorrelatoreAngelo Consoli
CommittenteElia Oggian (EOC)
Corso di laurea
Ingegneria informatica (PAP)
Modulo
M00002P Progetto di diploma
Anno
2018
Indice
Abstract 1 Progetto assegnato 3 1 Introduzione 5 1.1 Area ICT . . . 5 1.1.1 Geco . . . 6 1.2 Situazione attuale . . . 8 1.2.1 Componenti dell’infrastruttura . . . 81.2.2 Applicazione attuale delle modifiche . . . 10
1.3 Situazione desiderata . . . 11 2 Analisi e progettazione 13 2.1 Infrastruttura tradizionale . . . 13 2.1.1 Rischi . . . 14 2.2 Infrastruttura immutabile . . . 14 2.3 Pets vs. Cattle . . . 14 2.3.1 Esempio 1 . . . 15 2.3.2 Esempio 2 . . . 17 2.3.3 Concetto . . . 18 2.4 Vantaggi e svantaggi . . . 19 2.5 Strumenti . . . 21 2.5.1 VMware vSphere . . . 21 2.5.2 Terraform . . . 22 2.5.3 Packer . . . 23 2.5.4 Puppet . . . 24 2.5.5 Docker . . . 25 2.5.6 Rancher . . . 26 2.5.7 Jenkins . . . 26
2.8 Specifiche . . . 27
3 Implementazione 29 3.1 Flusso di sostituzione delle macchine virtuali . . . 29
3.1.1 Creazione dell’ambiente . . . 29
3.1.2 Upgrade dell’ambiente . . . 30
3.2 Primo approccio di integrazione con VMware . . . 30
3.2.1 Creazione del template . . . 31
3.2.2 Installazione di Terraform . . . 32
3.2.3 Sintassi di base di Terraform . . . 33
3.2.4 Creazione delle VM con Terraform . . . 34
3.2.5 Sostituzione delle VM con Terraform . . . 38
3.2.6 Terraform lifecycle . . . 44
3.3 Secondo approccio di integrazione con VMware . . . 46
3.3.1 VLAN dedicata . . . 46
3.3.2 DHCP server . . . 47
3.3.3 DNS server . . . 49
3.3.4 Creazione dinamica delle VM con Terraform . . . 52
3.3.5 Sostituzione dinamica delle VM con Terraform . . . 57
3.4 Integrazione con Rancher . . . 58
3.4.1 Aggiunta di host in Rancher con Terraform . . . 59
3.4.2 Rimozione di host in Rancher con Terraform . . . 61
3.4.3 Creazione di un servizio in Rancher . . . 66
3.4.4 Sostituzione di host in Rancher con Terraform . . . 68
3.4.5 Terraform bug #13549 . . . 70
3.5 Integrazione con Barracuda ADC Load Balancer . . . 70
3.5.1 Servizio TERRAFORM . . . 71
3.5.2 REST API . . . 73
3.5.3 Creazione dei server reali con Terraform . . . 74
3.5.4 Rimozione dei server reali con Terraform . . . 78
3.6 Integrazione con Jenkins . . . 80
3.6.1 Job terraform-apply . . . 80
3.6.2 Job terraform-destroy . . . 81
3.7 Infrastruttura completa . . . 81
3.7.1 Interazioni tra i componenti . . . 81
3.7.2 Creazione dell’infrastruttura . . . 83
3.7.3 Applicazione di una nuova versione . . . 85
3.7.4 Distruzione dell’infrastruttura . . . 87
4 Conclusioni 91
4.1 Risultati ottenuti . . . 91
4.2 Sviluppi futuri . . . 93
4.2.1 Creazione dei template da codice . . . 93
Elenco delle figure
1.1 Tipica interazione client-server di un’applicazione verso un microservizio . . . 6
1.2 Numero di client Geco concorrenti il 24.07.2018 . . . 7
1.3 Schema generale delle interazioni tra i componenti . . . 9
1.4 Applicazione delle modifiche senza infrastruttura immutabile . . . 10
1.5 Applicazione delle modifiche con infrastruttura immutabile . . . 12
2.1 Due server considerati uguali . . . 16
2.2 Due server considerati "Pets" . . . 16
2.3 Due server considerati uguali . . . 17
2.4 Due server considerati comunque uguali, che eseguono applicazioni diverse . 18 2.5 Suddivisione degli ambienti in Rancher . . . 20
2.6 Un server che esegue diversi container docker (App A, App B, ...) . . . 26
3.1 Installazione del plugin per il provider vsphere . . . 37
3.2 Richiesta di conferma per l’applicazione del piano . . . 37
3.3 Verifica della raggiungibilità via rete della VM creata . . . 38
3.4 La risorsa vsphere_virtual_machine viene sostituita . . . 39
3.5 L’applicazione della definizione terminata con successo . . . 42
3.6 Viene richiesta la conferma per la sostituzione delle macchine virtuali . . . 42
3.7 Distruzione delle vecchie macchine virtuali . . . 42
3.8 Creazione delle nuove macchine virtuali . . . 43
3.9 L’avvenuta sostituzione delle macchine virtuali . . . 43
3.10 Errore di applicazione del piano . . . 45
3.11 Flusso delle richieste e risposte DHCP . . . 47
3.12 Configurazione dello scope DHCP . . . 48
3.13 Configurazioni dell’interazione tra DHCP e DNS . . . 49
3.14 Configurazione della zona eoc.ch in DNS . . . 50
3.15 Configurazione delle credenziali per l’aggiornamento dei record sul DNS . . . 51
3.16 Credenziali per l’aggiornamento dei record sul DNS . . . 51
3.19 Installazione del plugin random . . . 55
3.20 Piano di creazione delle macchine virtuali . . . 56
3.21 L’applicazione della definizione terminata con successo . . . 56
3.22 Verifica del funzionamento del DHCP server e creazione dei record DNS dinamica . . . 56
3.23 Piano di sostituzione delle macchine virtuali . . . 57
3.24 Sostituzione delle macchine virtuali e test della configurazione IP e DNS . . . 58
3.25 Richiesta di conferma per l’applicazione del piano . . . 61
3.26 Host visibili nell’ambiente terraform di Rancher . . . 61
3.27 Host non raggiungibili ma ancora visibili nell’ambiente "terraform" di Rancher . 62 3.28 Descrizione delle API di Rancher per evacuare un host . . . 62
3.29 Descrizione delle API di Rancher per rimuovere un host . . . 63
3.30 Host eliminati dall’ambiente "terraform" in Rancher . . . 65
3.31 Creazione del servizio webserver in Rancher . . . 66
3.32 Opzioni di scheduling dei container del servizio webserver . . . 67
3.33 Host in Rancher eseguono le 2 istanze del servizio webserver . . . 67
3.34 Verifica del corretto funzionamento del webserver Apache httpd . . . 68
3.35 Macchine virtuali eliminate ma host ancora presenti in Rancher in stato "di-sconnected" . . . 69
3.36 Schema di funzionamento del servizio configurato sul load balancer . . . 71
3.37 Schema di instradamento delle richieste dei client verso i server . . . 72
3.38 Verifica del funzionamento dei load balancers . . . 73
3.39 Applicazione della definizione terminata con successo . . . 77
3.40 Server reali del servizio "TERRAFORM" sul Barracuda ADC Load Balancer . 77 3.41 Server reali eliminati dal servizio "TERRAFORM" sul Barracuda ADC Load Balancer . . . 79
3.42 Schema delle interazioni tra i componenti dell’infrastruttura . . . 82
3.43 Flusso di creazione dell’infrastruttura . . . 83
3.44 Flusso di aggiornamento dell’infrastruttura . . . 85
Elenco delle tabelle
1.1 Ambienti di Geco . . . 7
1.2 Componenti dell’infrastruttura attuale . . . 8
2.1 Specifiche per il prototipo di infrastruttura immutabile . . . 28
3.1 Hardware virtuale della macchina virtuale di template . . . 31
3.2 Sequenza di sostituzione delle macchine virtuali . . . 43
3.3 Dettagli della VLAN 112 . . . 47
3.4 Attributi delle scope options . . . 48
Abstract
Il progetto prevede l’introduzione del concetto di infrastruttura immutabile, con lo scopo prin-cipale di minimizzare i rischi di interruzioni dei sistemi informatici, che vengono usati per la gestione dei pazienti negli ospedali dell’Ente Ospedaliero Cantonale (EOC).
L’infrastruttura immutabile viene integrata con i sistemi informatici attualmente in uso. L’in-tegrazione prevede l’automatizzazione dei processi e delle configurazioni dei componenti dell’infrastruttura. Questo ha permesso l’adozione del concetto di infrastruttura immutabile, permettendo quindi di apportare modifiche ai server sostituendoli con degli altri che sono stati modificati in base alle necessità.
Sono stati definiti i flussi di sostituzione e di integrazione necessari per garantire un’ottimale rotazione dei server all’introduzione di una nuova modifica.
Vengono inoltre utilizzati strumenti e concetti innovativi, grazie ai quali è stato possibile ot-tenere dinamismo nell’attuare la sostituzione dei server.
Il prototipo sviluppato si interfaccia con la piattaforma di virtualizzazione dei server per la creazione ed eliminazione degli stessi, con il load balancer per modificarne la sua confi-gurazione e, infine, con il container orchestrator per permettergli di erogare i microservizi utilizzando i server virtuali. L’intera implementazione volge a minimizzare il tempo di disser-vizio alla sostituzione dei server.
Durante l’implementazione sono state necessarie alcune modifiche all’infrastruttura di EOC per rendere più dinamica la gestione dei server, di conseguenza sono state esplorate ed adottate soluzioni innovative rispetto a quelle tradizionalmente utilizzate in azienda.
Il prototipo di infrastruttura immutabile implementato potrà essere utilizzato per esporre oltre 120 microservizi, i quali vengono interrogati dall’applicazione per la gestione e la cura dei pazienti negli ospedali cantonali di EOC.
Si prevede dunque un utilizzo dell’infrastruttura da parte di oltre 2000 utenti, 24 ore al giorno, ogni giorno. Il rischio che questi utenti riscontrino dei disservizi viene ridotto grazie alla migliore gestione dell’infrastruttura che è stata resa appunto immutabile.
Progetto assegnato
Persone coinvolte
Proponente: Consoli Angelo
Relatore: Consoli Angelo
Studente: Oggian Elia
Dati Generali
Codice: C09899
Anno accademico: 2017/2018
Semestre: Semestre estivo
Corso di laurea: Ingegneria informatica (Informatica PAP) Opzione: O1 Architetture software di rete
Tipologia del progetto: Diploma
Confidenziale: SI
Pubblicabile: NO
Descrizione
Si tratta di un lavoro esterno per studenti PAP. Con l’introduzione di nuove tecnologie nel contesto aziendale, si è deciso di passare ad un’infrastruttura che permetta di sfruttare la tecnologia dei containers, utilizzando Docker e Rancher come tool di orchestration per i vari ambienti.
L’infrastruttura attuale è composta da macchine virtuali (VM) linux create da template ma-nualmente. Le VM vengono mantenute costantemente applicando aggiornamenti, nuove configurazioni, ecc.
Questo approccio comporta queste principali problematiche: • Le VM non sono versionate
• VM eterogenee nello stesso ambiente (diverse versioni di docker per esempio) Si vorrebbe introdurre, per l’infrastruttura dedicata ai containers, il concetto di immutable infrastructure che prevede ad ogni modifica sulle VM la loro sostituzione invece della loro modifica, possibilmente automatizzando il processo di sostituzione.
Compiti
Il progetto prevede l’implementazione di un prototipo di Immutable Infrastructure che per-metta la sostituzione delle VM in uso con una nuova versione. Le VM saranno create a partire dal codice che le descrive.
• Ricerca dello stato dell’arte in ambito di VM provisioning e Infrastructure as Code • Definizione del flusso di sostituzione delle VM
• Integrazione con l’infrastruttura esistente
• Redazione di un manuale per l’uso dell’infrastruttura
• Definizione delle procedure e svolgimento di una campagna di test • Documentazione del lavoro svolto
Obiettivi
• Implementazione di un prototipo di Immutable Infrastructure che permetta la sostitu-zione delle VM in uso con una nuova versione.
• Ottima documentazione del lavoro svolto.
Tecnologie
Verranno discusse con l’azienda committente e con il docente responsabile del lavoro di diploma. Alcune tecnologie già note:
• VMware vSphere
• Barracuda ADC Load Balancer • Rancher
• Docker
• Vagrant, Terraform, Packer (per esempio) • Altre tecnologie intrinseche (DHCP, DNS, ecc.)
Capitolo 1
Introduzione
Questo capitolo è volto ad introdurre il lettore, non forzatamente informatico, agli argo-menti trattati, fornendogli le informazioni necessarie per comprendere la documentazione e dandogli una visione d’insieme del progetto.
1.1
Area ICT
[1] Citazione di Marco Bosetti, Capo Area ICT:
L’Area ICT (Informatica e Tecnologia della Comunicazione) ha come obiettivo quello di proporre e mettere in opera, scegliendo le opportune tecnologie, i pro-cessi inter-funzionali di base dell’EOC stesso, considerando l’ottica di servizio all’utenza, ivi compreso gli aspetti di comunicazione e connettività di dati. Lo spettro di attività in questi anni si è ampliata dagli aspetti d’informatica “clas-sica” al supporto di nuovi servizi e ambiti, specialmente nell’Area sanitaria e del personale e da ultimo verso le condizioni quadro per la ricerca.
Il compito base consiste nel gestire e implementare le soluzioni informatiche adeguate e atte a soddisfare i bisogni degli utenti, nei limiti fissati dalla pianifi-cazione finanziaria e del personale.
Partendo da questo presupposto, si mette in evidenza un aspetto dell’area ICT che risulta importante per questo progetto: EOC sviluppa in casa l’applicativo core per la cartella in-formatizzata dei pazienti, chiamato "Geco". Oltre allo sviluppo del software, l’Area ICT si occupa anche dell’infrastruttura necessaria per eseguire l’applicazione, sia lato server, sia lato client. In questo progetto ci si focalizza unicamente sul lato server.
1.1.1
Geco
Geco è il software sviluppato in casa da EOC ed è suddiviso in moduli per la cura del pazien-te. Nei vari moduli si possono visualizzare i documenti, prescrivere i farmaci, visualizzare le cure, eccetera.
Geco è basato su un’architettura a microservizi, questa tipologia di architettura implica una grande quantità di "piccole applicazioni" lato server (microservizi) che interagiscono tra di loro.
Un client, per esempio il computer di un infermiere, aprendo l’applicazione Geco fa del-le richieste a molti microservizi lato server, il quadel-le gli risponde dandogli del-le informazioni richieste, per esempio quelle del paziente. Ogni microservizio è responsabile di fornire determinate informazioni.
Requests
Client
Responses
Server
Figura 1.1: Tipica interazione client-server di un’applicazione verso un microservizio
Per dare un’idea del dimensionamento dell’applicazione Geco si danno alcune cifre: • Circa 70 server per l’ambiente di produzione
• Circa 120 componenti (microservizi), in aumento (aggiunta di funzionalità) • Utilizzo 24h/24h e 7gg/7gg
La quantità di client concorrenti è variabile, a scopo informativo è stato estratto il conteggio orario su un giorno infrasettimanale:
0 500 1'000 1'500 2'000 2'500 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Us ers Hour
GECO Concurrent users
Figura 1.2: Numero di client Geco concorrenti il 24.07.2018
Ci sono 4 ambienti di Geco, utilizzati per scopi differenti: Tabella 1.1: Ambienti di Geco
Ambiente Scopo Utilizzatori
DEV Sviluppo di nuove funziona-lità
Sviluppatori
FORM Formazione degli utenti Formatori e personale me-dico e infermieristico TEST Test di funzionalità o
proce-dure
Sviluppatori, IT Operations, utenti beta tester
PROD Produzione Personale medico e
infer-mieristico per la cura dei pazienti reali
1.2
Situazione attuale
Attualmente i microservizi girano su server virtuali creati manualmente dal gruppo IT Ope-rations.
I server virtuali vengono aggiunti manualmente in un container orchestrator che si occupa di decidere quali microservizi far girare su quali server virtuali.
In sostanza, si definisce nel container orchestrator quali servizi devono venire erogati e que-st’ultimo si occupa di utilizzare i server virtuali a disposizione per farlo.
Le richieste dei client verso i server sono bilanciate da un load balancer, che si occupa di inoltrare ai server virtuali le richieste, bilanciando il carico.
Il load balancer necessita di configurazione, al momento anch’essa effettuata manualmente.
1.2.1
Componenti dell’infrastruttura
Si identificano i componenti principali e le loro relative funzionalità: Tabella 1.2: Componenti dell’infrastruttura attuale
Componente Funzionalità
Load balancer Bilanciare le richieste fatte dai client verso i server virtuali
Container orchestrator Gestire l’erogazione dei servizi sui server virtuali Server virtuale Eseguire i microservizi su indicazioni del
contai-ner orchestrator
Lo schema seguente illustra a grandi linee l’interazione che c’è tra i componenti dell’infra-struttura: Virtual servers run applications in docker containers Container orchestrator Manage VMs Virtual machine manager Request forwarding and load balancing
Load Balancer
Requests
Client (PCs, Tablets, other servers)
Figura 1.3: Schema generale delle interazioni tra i componenti
Un client richiede le informazioni al load balancer, il quale inoltra la richiesta ad un server virtuale, che si occupa di ritornare la risposta al client che ha fatto la richiesta.
Il container orchestrator si occupa di fare in modo che i server virtuali espongano tutti i microservizi necessari ai client.
Il virtual machine manager si occupa di fare in modo che i server virtuali siano accesi e disponibili.
1.2.2
Applicazione attuale delle modifiche
Attualmente le modifiche vengono fatte su ogni server in maniera manuale, in questo mo-do si modificano i server in maniera diversa e ci si ritrova con server configurati in momo-do eterogeneo, denotati con versioni diverse.
IT Operators Virtual servers v2.0 v1.3 v0.9 v1.2 Security update
Upgrade docker version
Change to configuration
Add missing file
1.3
Situazione desiderata
Con il passare del tempo, i server nei vari ambienti (DEV, FORM, TEST e PROD) sono di-ventati diversi l’uno dall’altro, con aggiornamenti e configurazioni diverse tra loro, causando talvolta problemi di funzionamento e/o compatibilità.
Questa problematica ha fatto nascere la necessità di un migliore sistema di gestione dei server virtuali.
Con questo progetto si intende quindi sviluppare un sistema di integrazione tra i componenti dell’infrastruttura attuale, rendendola immutabile ed automatizzando i processi più importan-ti.
Gli obiettivi principali sono:
• Ottenere omogeneità tra i server nello stesso ambiente.
• Testare i server, utilizzando in ambiente di PROD solo le versioni che non hanno generato problemi negli altri ambienti.
• Sostituire i server in un intero ambiente in modo rapido e prevedibile minimizzando il tempo di disservizio per gli utenti.
• Automatizzare le integrazioni tra i componenti. Quando un server viene sostituito, tutte le configurazioni necessarie sono fatte in modo automatizzato.
• Facilitare l’applicazione di aggiornamenti su tutti i server di un ambiente
Per ottenere il risultato desiderato, si vuole sviluppare un prototipo di infrastruttura immu-tabile che alla necessità di una modifica ai server, per esempio l’applicazione degli aggior-namenti, questa avviene sostituendo i server con dei nuovi server che hanno gia gli ultimi aggiornamenti installati.
La sostituzione dei server implica diverse integrazioni con i componenti dell’infrastruttura. Si intende quindi integrare tutti i componenti per automatizzare la sostituzione e ottenere una soluzione che minimizzi il tempo di disservizio per gli utenti.
Security update Upgrade docker version Change to configuration
Add missing file
IT Operators Virtual servers v2.0 v1.0 v2.0 v1.0 v2.0 v1.0 v2.0 v1.0 Replace all servers Immutable infrastructure
Figura 1.5: Applicazione delle modifiche con infrastruttura immutabile
Le modifiche vengono fatte centralmente in un unico posto e grazie all’infrastruttura immu-tabile queste vengono applicate sostituendo tutti i server dell’ambiente con nuovi server modificati.
Capitolo 2
Analisi e progettazione
2.1
Infrastruttura tradizionale
In un’infrastruttura tradizionale, come quella attuale in EOC, i server virtuali vengono creati e gestiti manualmente. In particolare, i server vengono modificati continuamente da parte degli operatori per soddisfare le necessità delle applicazioni e/o degli utilizzatori.
Normalmente, al giorno d’oggi, la maggior parte delle aziende si appoggia su un’infrastrut-tura virtuale, in casa o in cloud. Questo permette una grande flessibilità per la gestione dei server virtuali, i quali possono venire creati in modo rapido a partire da un template (imma-gine) di partenza che fornisce già il sistema operativo e determinato software.
Una volta creato il server virtuale questo viene continuamente adattato in base alle neces-sità, apportando varie modifiche alla sua configurazione.
Modificando il server, lo si rende diverso da quello che il template ha generato e quindi si entra in uno stato irriproducibile.
Questo scenario è la norma nella maggior parte delle aziende al giorno d’oggi, EOC com-presa. Risulta comunque un netto miglioramento rispetto a quello che prevedeva l’era dei server fisici. Senza l’aiuto della virtualizzazione, infatti, era molto più difficile replicare in maniera rapida un server.
Questo approccio però presenta alcune problematiche. Basti pensare ad un team di alcuni membri che si occupano di gestire i server. Ogni membro apporta modifiche alla configura-zione in base alle sue necessità, dopo poco tempo si perde il controllo della configuraconfigura-zione sui vari server e li si rende univoci ed irriproducibili.
2.1.1
Rischi
In uno scenario come quello di EOC, con 4 ambienti in cui è presente l’applicativo core "Geco", un’infrastruttura tradizionale comporta principalmente i rischi seguenti:
• Avere server virtuali eterogenei nello stesso ambiente.
• Comportamenti diversi da un server all’altro del medesimo software.
• Andare in produzione e far girare il software su server con librerie di sistema mai testate negli altri ambienti.
• Compromettere l’erogazione del servizio.
• Mettere potenzialmente in pericolo la vita del paziente.
2.2
Infrastruttura immutabile
Una infrastruttura immutabile volge ad evitare i rischi che sono stati evidenziati in un infra-struttura tradizionale.
Sfruttando l’infrastruttura virtuale, si decide di non modificare la configurazione o il software di base dei server online, ma di generare una nuova versione dei server e prevedere la sostituzione (possibilmente automatizzata) dei vecchi server. L’ideale è quello di prevedere una sostituzione con zero downtime, dove possibile.
Questo approccio permette di evitare tutti i rischi elencati alla sezione 2.1
Generalmente, l’automatizzazione della sostituzione dei server implica diverse integrazioni da effettuare con l’infrastruttura circostante, questo aspetto comporta diverse complicazioni per l’implementazione di un infrastruttura immutabile.
2.3
Pets vs. Cattle
[2] Citazione di Randy Bias :
In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.
La citazione di Randy Bias viene spesso usata nel web. L’analogia è proprio pensata verso i server di un’infrastruttura. Finora l’approccio è sempre stato (e nella maggioranza dei casi
è tuttora) quello di trattare i server come dei Pet (dall’inglese, animali da compagnia).
Si usa quindi creare (nel caso di un’infrastruttura virtualizzata) e configurare un server e con-tinuare a modificare la sua configurazione ed i suoi pacchetti software in base alle neces-sità, per esempio applicando degli aggiornamenti. Proprio come si farebbe con un animale domestico, dal punto di vista delle cure, per esempio.
Queste operazioni vengono spesse effettuate da parte del team dell’IT Operation, normal-mente composto da più persone. Questo modo di lavorare porta spesso, se non sempre, ad avere dei server che sono a tutti gli effetti dei “Pet” ossia ognuno diverso dall’altro e configurato in maniera univoca ed irriproducibile.
Si dicono invece “Cattle” (dall’inglese, bestiame) i server che sono uno fra tanti, riproducibili, conosciuti e prevedibili.
Per riprendere l’espressione citata, se una mucca in fattoria, per esempio, ha una malattia, in genere non ci si accanisce per trovare una cura ma questa viene soppressa ed al suo posto ci sarà un altro esemplare che servirà allo stesso scopo del precedente animale. Questo è quello che accade in un’infrastruttura immutabile, con l’aggiunta dell’aspetto legato alle modifiche al server. Non si modificano i server “in place” ma si provvede a sostituirli con altri che già dalla creazione hanno la modifica voluta.
È importante definire a quale livello di modifica e/o configurazione, un server è considerato un “Pet” o meno. Per semplificare la definizione si fanno due esempi. Entrambi gli esempi partono dal presupposto che si lavora su di un’infrastruttura virtualizzata, e che ci sia quindi a disposizione un template per creare i server virtuali.
2.3.1
Esempio 1
In questo esempio vengono creati 2 server virtuali dal template menzionato sopra, “VM1” e “VM2”. Si hanno quindi due server virtuali che, partendo dallo stesso template, si possono definire uguali (cambiano solamente le configurazioni di rete, hostname, ecc).
Ora supponiamo che venga fatto il deploy1 di due istanze dello stesso applicativo, una su VM1 e l’altra su VM2, il tutto viene messo dietro ad un load balancer che gestisce le richieste e bilancia il carico tra le due istanze. Per facilitare la comprensione si è fatto uno schema:
VM1 VM2 Load Balancer App-1 App-2 Clients Java JDK 1.8.162 ... ... ... Java JDK 1.8.162 ... ... ...
Figura 2.1: Due server considerati uguali
In questo momento si hanno due server che sono considerati uguali, e quindi NON sono “Pets” (o non ancora. . . ). Notare le versioni di Java JDK uguali sulle due VM.
Ora, l’operatore IT si collega via SSH alla VM1 e subito dopo aver effettuato il login vede che sono disponibili degli aggiornamenti, decide quindi di applicarli. Con l’aggiornamento, oltre ad altri pacchetti software, la versione di Java JDK è stata portata alla versione 1.8.172.
Ora quindi la situazione è la seguente:
VM1 VM2 Load Balancer App-1 App-2 Clients Java JDK 1.8.172 ... ... ... Java JDK 1.8.162 ... ... ...
In questo momento i due server sono effettivamente considerabili dei “Pets” tra di loro. Infatti VM1 ha ricevuto un trattamento diverso da VM2.
Una richiesta fatta da parte di un client arriva sul load balancer il quale la redirige verso uno dei due server reali, e qui troviamo la differenza di versione di Java JDK e altri pacchetti che sono stati aggiornati. Potenzialmente, a causa della differenza di versioni di software installati, il comportamento dell’applicazione può risultare diverso sulla VM1 rispetto alla VM2.
2.3.2
Esempio 2
Partendo dalla stessa situazione di partenza dell’esempio 1:
VM1 VM2 Load Balancer App-1 App-2 Clients Java JDK 1.8.162 ... ... ... Java JDK 1.8.162 ... ... ...
Figura 2.3: Due server considerati uguali
Ora, l’operatore IT riceve la richiesta di effettuare il deploy di una nuova applicazione in singola istanza. Guardando il carico dei server virtuali, l’operatore decide di effettuare il deploy dell’istanza della nuova applicazione sul server VM1, la situazione che si viene a creare è quindi la seguente:
VM1 VM2 Load Balancer App-1 App-2 Clients Java JDK 1.8.162 Java JDK 1.8.162 NewApp-1
Figura 2.4: Due server considerati comunque uguali, che eseguono applicazioni diverse
In questo momento i server stanno servendo applicazioni diverse ma la base del server e le versioni del software di base del server, come per esempio Java JDK, sono le stesse. In questo caso i server sono considerati ancora uguali e non “Pets” poiché lo strato di base del software del server virtuale rimane lo stesso, cambiano solo le applicazioni deployate.
2.3.3
Concetto
Per riprendere il concetto di “Pets vs. Cattle”, si dicono “Pets” i server che sono unici, inimi-tabili e vengono modificati e coccolati, proprio come animali domestici. In questo scenario, ogni server ha le sue particolarità e spesso ci sono differenze non facilmente visibili tra server che dovrebbero essere uguali (a livello di software di base e versioni degli stessi). Se si immagina di avere un problema con un animale domestico, l’iter che verrebbe seguito sarebbe quello di curarlo e farlo seguire da esperti in materia, per capire esattamente quale sia la natura della problematica, e come riuscire a risolverlo sull’animale stesso. Mentre se fosse un esemplare fra tanti, verrebbe rimpiazzato con un’altro esemplare che non ha il problema.
2.4
Vantaggi e svantaggi
Adottare il concetto di infrastruttura immutabile comporta diversi vantaggi, ma non è esente da svantaggi.
È importante sapere quale è l’utilizzo che si fa dell’infrastruttura alla quale si vuole applicare il concetto di “immutabile”.
Per quanto riguarda EOC, è in corso il progetto “265 - Service Containerization” che prevede l’adozione di Docker e quindi dei concetti legati ai container, quale l’isolamento delle librerie usate dall’applicazione, e la semplicità di delivery di un’applicazione su un server. L’unica dipendenza necessaria è il “motore” di Docker, il quale può eseguire il/i container partendo dall’immagine dell’applicazione.
Partendo da questo presupposto, si può dire che la complessità di provisioning della VM è piuttosto ridotta, poiché quel che occorre rendere disponibile, in fin dei conti, sono:
• Risorse (CPU, RAM, HD, NETWORKING) • Sistema operativo (kernel)
• Docker engine
Restando ad un livello astratto, questi strumenti si possono definire sufficienti per poter eseguire le applicazioni in container docker sui server.
In EOC è stato adottato Rancher quale tool di orchestration di containers docker, questo tool permette di definire degli ambienti, ognuno dei quali è composto da uno o più host (macchi-ne virtuali), che eseguono quelli che vengono chiamati Stack di servizi. Per semplificare la comprensione a livello logico di Rancher, si è fatto il seguente schema:
Rancher
Testing Environment Production Environment host-dev-1 host-prod-1 host-prod-2 App Stack App Stack App-backend-1 App-backend-1 App-backend-2 App-frontend-1 App-frontend-1 App-frontend-2 rancher-agent rancher-agent rancher-agentFigura 2.5: Suddivisione degli ambienti in Rancher
Come si evince dallo schema, ogni host esegue un rancher-agent, che è a sua volta un con-tainer Docker. L’agent comunica con il Rancher server e viene usato per eseguire operazioni sull’host, come per esempio eseguire un’applicazione sull’host, in un container docker. Il Rancher server si trova su una macchina virtuale separata, che non fa altro che eseguire il Rancher Server, a sua volta in un container docker.
Per identificare i vantaggi e svantaggi di un’infrastruttura immutabile rispetto ad una tradi-zionale si è stilata la lista seguente:
• Vantaggi:
– Facile riproduzione di una VM
– Versionamento dei templates dai quali vengono creati le macchine virtuali che compongono l’infrastruttura.
– Consistenza degli ambienti, tutte le VM in quell’ambiente sono uguali, e la diffe-renza tra un ambiente di test e uno produttivo è conosciuta e facilmente parifica-bile.
• Svantaggi:
– Una piccola modifica comporta la sostituzione di tutte le VM dell’ambiente, in sé occorre più tempo.
∗ Soluzione: processi automatizzati, il tempo “uomo” necessario rimane il medesimo.
– Debug di problemi reso più difficile, per esempio se manca un tool sulla VM (per esempio tcpdump), per installarlo devo creare una nuova versione.
∗ Soluzione 1: Fare la modifica sulla macchina e prevedere la sua distruzione dopo aver effettuato il debug
∗ Soluzione 2: Aggiungere il tool voluto sul template.
2.5
Strumenti
In questa fase di analisi si analizzano i principali strumenti che possono essere utili all’im-plementazione del prototipo di infrastruttura immutabile.
Si analizzano gli strumenti che, durante la fase di analisi e ricerca dello stato dell’arte, hanno suscitato interesse per un possibile utilizzo in EOC e/o sono già presenti. Non necessariamente si utilizzano tutti gli strumenti citati in questa sezione.
2.5.1
VMware vSphere
Prodotto dell’azienda VMware (Palo Alto, California, USA).
VSphere è la piattaforma di virtualizzazione leader di mercato2, già presente e fortemen-te utilizzata in EOC. Al momento conta oltre 500 macchine virtuali (principalmenfortemen-te server Windows e Linux).
Questo è lo strumento fondamentale per l’adozione del concetto “Infrastruttura immutabile”. Senza virtualizzazione non ha senso considerare utile il cambiamento, comporterebbe un enorme quantità di lavoro non automatizzabile.
La flessibilità che offre VMware si adatta perfettamente ai requisiti di un’infrastruttura immu-tabile, infatti viene anche spesso riportato come tool adatto allo scopo.
2.5.2
Terraform
Terraform è uno strumento open source dell’azienda HashiCorp (San Francisco, USA).
Questo strumento permette di creare, cambiare e distruggere (volutamente) un’infrastruttura in modo prevedibile, attraverso l’utilizzo di un linguaggio dichiarativo. Questo approccio è spesso indicato come “Infrastructure as code”.
I vantaggi che Terraform propone sono molteplici, i principali sono:
• Descrivere l’infrastruttura con del codice per permetterne una comprensione più sem-plice
• Collaborare e condividere l’informazione con i colleghi permette una migliore cono-scenza e condivisione del sapere tra i collaboratori
• Tenere traccia dei cambiamenti che l’infrastruttura ha subito nel tempo, grazie al codice che viene salvato in un version control system (e.g. git)
• Integrazione con diversi sistemi grazie ai providers, si mostrano particolarmente inte-ressanti i providers seguenti:
– VMware vSphere – Rancher
• Riproducibilità dell’infrastruttura
– A livello di ambiente, utile per testare in modo efficiente l’infrastruttura prima di andare in produzione con la medesima configurazione
– A livello cloud, ad esempio cambiando provider di cloud è possibile riprodurre la medesima infrastruttura.
• Risoluzione interna delle dipendenze, ad esempio se un file deve essere generato per poi venire utilizzato per la creazione di una VM, questa dipendenza viene risolta da Terraform.
Terraform è disponibile in 3 modalità: 1. Open Source:
• Funzionalità di base di Terraform senza restrizioni • Supporto della community
2. Pro:
• Tutto quello che offre la Open Source • Interfaccia grafica
• Gestione remota dello stato di Terraform (per lavorare in team) • API per l’integrazione di Terraform
• Connessione con il repository del codice di Terraform per automatizzare l’appli-cazione delle modifiche effettuate al codice di Terraform
• Installazione SaaS (Software as a Service)
• Supporto Silver 9x5 (negli orari di lavoro) con SLA (Service Level Agreement) 3. Premium:
• Tutto quello che offre la Pro
• SSO (Secure Sign On) con SAML (utilizzo di token con crittografia invece di passwords)
• Audit Logging
• Private install (on site)
• Supporto Gold 24x7 (Service Level Agreement)
Terraform è molto “giovane”, al momento della redazione di questo rapporto si è alla versio-nev0.11.7.
2.5.3
Packer
Packer è uno strumento open source dell’azienda HashiCorp (San Francisco, USA). Questo strumento permette di creare delle immagini macchina da utilizzare successivamen-te, ad esempio, con Terraform.
Anche Packer, come Terraform, prevede diversi providers con cui lavorare. Ad esempio, per-mette la creazione di immagini macchina (chiamati templates in ambiente VMware vSphere) per diverse piattaforme di virtualizzazione, tra cui VMware, Amazon (le cosiddette “ami”), Mi-crosoft Azure, ecc.
Il grande vantaggio offerto da Packer è la funzionalità di descrivere, con del codice, come un’immagine è composta, e quindi di aumentare notevolmente la riproducibilità della stessa. In questo modo si ottiene un metodo per versionare le immagini macchina che vengono create.
In aggiunta, creando le macchine virtuali partendo da immagini, si cerca di mantenere gli ambienti più consistenti possibile.
Uno use-case interessante per Packer è quello della creazione di appliance virtuali. Per esempio, un’azienda produttrice di un software, potrebbe mettere a disposizione del cliente il proprio software sotto forma di immagine macchina, pronta per essere deployata nell’in-frastruttura di virtualizzazione del cliente. In questo caso con del software già installato.
2.5.4
Puppet
Puppet è uno strumento di configuration management dell’azienda Puppetlabs (Portland, Oregon, USA).
EOC utilizza già Puppet per il provisioning e la gestione delle macchine virtuali Linux che ospitano i microservizi del software Geco.
Puppet viene utilizzato in EOC con la configurazione agent-master, ossia ogni nodo ha un agent che contatta il server master periodicamente per richiedere il catalogo delle sue configurazioni da apportare. Il master prende le informazioni dal repository di controllo (Bitbucket via git) nel quale risiede la configurazione.
Puppet sfrutta un linguaggio dichiarativo, attraverso al quale si definisce quale stato si vuole ottenere.
Tramite l’utilizzo di moduli, che possono essere sia presi dal Puppet Forge (repository di mo-duli Puppet), sia sviluppati individualmente per soddisfare necessità più particolari, si appli-cano le classi ai nodi. Le classi puppet contengono le risorse che apportano effettivamente le modifiche al nodo, le risorse più usate sono:
• File • Service • Exec • User • Cron
• Mount • Archive • Yumrepo • . . .
Le risorse si possono anche definire componendo risorse semplici.
Come è facile intuire da questa breve descrizione, Puppet permette un controllo molto gra-nulare della configurazione dei server, andando a gestire ogni singolo file di configurazione necessario e gestendo, ad esempio, anche il riavvio del servizio legato al file che viene modificato.
L’approccio di Puppet va quindi in contrasto con quanto propone il concetto di infrastrut-tura immutabile, poiché prevede la modifica della configurazione di server esistenti, ma perlomeno in modo controllato e dichiarato.
Tuttavia, potrebbe essere utile per effettuare delle configurazioni sulle macchine dalle quali si generano i templates. In questo modo si ottiene un modo semplice e replicabile per apportare delle modifiche ad un template.
Riassumendo, si potrebbe integrare Puppet con Packer per la generazione dei templates.
2.5.5
Docker
Docker è uno strumento open source per l’esecuzione di docker containers. Un docker container, è un pacchetto che include tutto quello che è necessario per eseguire un appli-cazione: codice, librerie, strumenti, configurazioni.
Docker è il motore che gestisce i containers, i quali sono simili ad una macchina virtuale, ma senza il sistema operativo e quindi molto più leggeri.
Figura 2.6: Un server che esegue diversi container docker (App A, App B, ...)
2.5.6
Rancher
Rancher è uno strumento open source dell’azienda Rancher Labs (San Francisco, USA), fa parte della famiglia dei container orchestrator.
Rancher gestisce i cluster di server che eseguono i container docker, per esempio spostan-do i container su altri server in caso di necessità (ad esempio se il server viene spento). Rancher è uno strato ulteriore tra i servizi da esporre ed i server virtuali.
2.5.7
Jenkins
Jenkins è uno strumento di automazione open source. Con migliaia di plugins è possibile in-tegrare moltissimi sistemi con Jenkins per eseguire dei processi automatizzati, le cosiddette builds.
Jenkins potrebbe essere interessante per eseguire dei job su un server, ovvero un builder. Il vantaggio di eseguire su un builder è quello di non dipendere dalla macchina dell’opera-tore.
Jenkins permette di fare Continuous Integration e Continuous Delivery, per esempio posso-no venire scatenate delle build quando del nuovo codice viene caricato sul repository. Nel caso specifico potrebbe essere utile principalmente per 2 utilizzi:
• Creazione dei template utilizzando Packer in un job Jenkins.
2.6
Analisi dei requisiti
Per la progettazione del prototipo di infrastruttura immutabile è necessario analizzare alcuni requisiti della stessa.
Sono necessari i seguenti strumenti per la realizzazione del prototipo:
• Infrastruttura virtuale che permetta la creazione di server virtuali a partire da templa-tes.
• Load Balancer per bilanciare il carico delle richieste verso i server virtuali. La configu-razione deve poter essere automatizzata.
• Sistema di container orchestration per la distribuzione delle applicazioni sui server virtuali.
• Sistema di integrazione tra i componenti dell’infrastruttura per la gestione delle risorse e delle configurazioni.
• Repository del codice nel quale salvare la definizione dell’infrastruttura.
2.7
Vincoli
Si analizzano alcuni vincoli posti per la realizzazione del prototipo di infrastruttura immuta-bile.
Data l’infrastruttura tradizionale già esistente e produttiva di EOC per l’applicativo core Geco, si vuole ottenere un’integrazione con buona parte di quanto già in uso.
In particolare, sono posti i seguenti vincoli:
• L’infrastruttura immutabile deve essere integrata con il sistema di container orchestra-tion già presente in EOC (Rancher).
• L’unica infrastruttura di virtualizzazione da utilizzare è VMware vSphere in quanto già presente. Non si vuole aggiungere un’ulteriore piattaforma di virtualizzazione dedicata.
2.8
Specifiche
In base all’analisi effettuata alle sezioni precedenti di questo capitolo, si decidono le seguenti specifiche per il prototipo di infrastruttura immutabile.
Tabella 2.1: Specifiche per il prototipo di infrastruttura immutabile Prodotto Motivazioni Terraform Open Source (sistema di integrazione) • Open Source • Grande community
• Buona documentazione online
• Diversi providers interessanti per l’integrazione con i sistemi di EOC
• Mancanza di valide alternative al momento
VMware vSphere (infrastruttura vir-tuale)
• Obbligatorio, le VM devono venir create in VMware vSphere
• Già presente ed utilizzato in EOC • Conoscenze preliminari del prodotto • Prevista integrazione con Terraform
Rancher (sistema di container orche-stration)
• Obbligatorio, i microservizi Geco essere in Rancher • Già presente ed utilizzato in EOC
• Conoscenze preliminari del prodotto • Prevista integrazione con Terraform
Barracuda ADC Load Balancer (load balancer)
• Già presente ed utilizzato in EOC • Doppia appliance fisica in HA
• REST API per l’integrazione con Terraform
Bitbucket
(reposi-tory del codice) • Già presente ed utilizzato in EOC • Già sotto backup
Capitolo 3
Implementazione
In questo capitolo, date le specifiche alla sezione 2.8, si documenta l’implementazione del prototipo di infrastruttura immutabile.
3.1
Flusso di sostituzione delle macchine virtuali
In questa sezione si definisce l’ipotetico flusso di sostituzione delle macchine virtuali e delle configurazioni che la sostituzione comporta.
Il flusso prevede la sostituzione delle macchine virtuali riducendo al minimo l’impatto per gli utenti finali, minimizzando il tempo di downtime degli applicativi che i server virtuali stanno eseguendo (sotto forma di containers docker).
3.1.1
Creazione dell’ambiente
Ipotizzando di avere un ambiente senza alcun host, e quindi nessuna applicazione in ese-cuzione, il flusso di creazione è ininfluente, l’obiettivo è quello di creare l’infrastruttura da zero. Il flusso è definito come segue:
• Creazione delle macchine virtuali su VMware vSphere a partire dal template versione v1.0.
• Esecuzione dei container docker rancher-agent sulle macchine virtuali create per aggiungerle in Rancher.
• Configurazione del servizio su Barracuda ADC Load Balancer aggiungendo i server reali appena creati.
Questo flusso permette all’ambiente Rancher di ospitare dei servizi, ovvero applicazioni in container docker. La configurazione del load balancer permette alle richieste dei client di
3.1.2
Upgrade dell’ambiente
Si ipotizza che l’infrastruttura creata in precedenza necessita ora di venire aggiornata. Co-me previsto dal concetto di infrastruttura immutabile, le macchine virtuali non si modificano direttamente, ma si sostituiscono con una nuova versione.
Il flusso da seguire, per ogni macchina virtuale da sostituire, è quindi il seguente:
• Se non ancora presente, creazione del nuovo template versione v2.0 applicando gli aggiornamenti desiderati
• Disattivazione del server reale da sostituire sul servizio di Barracuda ADC Load Ba-lancer
• Evacuazione dei servizi attualmente in esecuzione sulla macchina virtuale • Rimozione della macchina virtuale da Rancher
• Eliminazione della macchina virtuale da VMware vSphere
• Creazione della nuova macchina virtuale su VMware vSphere partendo dal template versione v2.0
• Esecuzione del container docker rancher-agent sulla macchina virtuale creata • Riattivazione del server reale sul servizio di Barracuda ADC Load Balancer
Questo flusso di sostituzione permette di sostituire una macchina virtuale con una più ag-giornata, utilizzando però il medesimo indirizzo IP e Hostname. Per questo motivo il server reale è sufficiente disattivarlo e riattivarlo.
3.2
Primo approccio di integrazione con VMware
In seguito alla raccolta di informazioni effettuata precedentemente e alla definizione dell’ipo-tetico flusso di sostituzione, si è deciso di proseguire con l’implementazione dell’infrastrut-tura immutabile utilizzando i seguenti strumenti analizzati:
• VMware vSphere • Terraform
Sono stati scelti come strumenti per iniziare l’adozione del concetto di infrastruttura immu-tabile solamente quelli che sono strettamente necessari. Gli altri strumenti si potrebbero rivelare utili in ulteriori sviluppi dell’infrastruttura.
3.2.1
Creazione del template
Si decide di creare un template VMware vSphere così configurato:
Tabella 3.1: Hardware virtuale della macchina virtuale di template
Risorsa Valore
CPU 2 (2 sockets, 1 core per socket)
RAM 2 GB
Hard Disk 30 GB (Thick Provision Lazy Zeroed) Network Adapter VMXNET3
Le risorse allocate sono volutamente ridotte per ridurre al minimo l’impatto sull’infrastruttura virtuale durante la fase di implementazione, durante la quale si fanno molte prove. Questi valori sono riconfigurabili sulle macchine virtuali che si creano a partire da questo template. Il template è a tutti gli effetti per il momento una macchina virtuale, questa viene quindi ac-cesa e si inserisce nella periferica virtuale di CDROM l’immagine ISO del sistema operativo scelto per le macchine virtuali da creare, ossia Ubuntu Server 16.04 LTS (64bit).
Si esegue l’installazione del sistema operativo configurando i seguenti parametri: • Layout della tastiera (Swiss French)
• Timezone (Europe/Zurich) • Password di root
• Partizionamento dello spazio dell’hard disk – Una partizione unica di tipo ‘8e’ (LVM Linux) • LVM (Logical Volume Management)
– Un volume group unico – Due logical volumes:
∗ root (25 GB) montato su / ∗ swap (5 GB) per area di swap • NTP (Network Time Protocol) server interni
– Domain controller – Gateway
– IP statico
– Gateway della VLAN usata – Mask della VLAN
– DNS servers
– DNS search domains
A questo punto si converte la macchina virtuale in template.
Notare la presenza di IP statico, in EOC i server normalmente non utilizzano DHCP per l’as-segnamento dell’indirizzo IP, questo significa che ogni macchina virtuale che viene creata deve ricevere una configurazione dell’indirizzo IP, assegnato dall’operatore IT.
Per poter personalizzare la macchina virtuale al momento della creazione si fa uso dei cu-stomization wizards di VMware vSphere, che prevedono l’immissione di dati quali hostname, indirizzo IP e network mask al momento della creazione della macchina virtuale da template. Per garantire una maggiore flessibilità si è creato il datastore cluster "DS_TERRAFORM_01" in VMware vSphere, ossia un cluster di datastores (dischi) da poter utilizzare quale spazio disco per le macchine virtuali.
3.2.2
Installazione di Terraform
Terraform, nella versione open source, viene distribuito come un binario eseguibile e viene scaricato ed eseguito da linea di comando, per comodità si sposta in un percorso presente nella variabile d’ambiente PATH e si danno permessi di esecuzione al binario.
$ wget https :// releases . hashicorp .com/ terraform / 0.11.7/ terraform_0 .11.7 _linux_amd64 .zip
$ unzip terraform_0 .11.7 _linux_amd64 .zip
$ mv terraform /usr/bin/ terraform
$ chmod +x /usr/bin/ terraform
3.2.3
Sintassi di base di Terraform
Dalla documentazione di Terraform1, si riporta la sintassi base del HashiCorp Configuration Language (HCL):
• Commento linea singola con# • Commenti multi-linea tra/*e*/.
• I valori sono assegnati in modalità chiave = valore (gli spazi non contano). I valori possono essere di tipo primitivo (stringa, numero, booleano), una lista, o una mappa. • Le stringhe sono tra doppie virgolette: "stringa".
• Le stringhe possono utilizzare referenziare variabili tramite l’utilizzo di${}. Esempio: ${var.foo}.
• I numeri vengono considerati in base 10, con l’utilizzo del prefisso 0x, il numero viene interpretato in base 16.
• Valori booleani: true, false.
• Liste di tipi primitivi sono fatti con le parentesi quadre ([ ]). Esempio: ["foo", "bar", "baz"].
• Le mappe sono fatte con le parentesi graffe ({ }) e i doppi punti (:): Esempio: {"foo": "bar", "bar": "baz"}.
Le virgolette possono essere omesse sulle chiavi, fintanto queste non iniziano con dei numeri. Le virgole sono obbligatorie tra le coppie chiave-valore di una lista su una sola linea. Per una lista multi linea, un ritorno a capo è sufficiente.
La dichiarazione avviene nel modo seguente: resource " tipo " " nome " {
chiave = " valore "
lista = [" pippo ", " pluto "] mappa {
chiave = " valore "
altra_chiave = " altro_valore "
} }
3.2.4
Creazione delle VM con Terraform
Ora che il template è pronto e Terraform installato, si procede con la definizione di quello che Terraform dovrà eseguire, e quindi a descrivere l’infrastruttura desiderata con del codice (Infrastructure as Code).
Terraform utilizza dei providers per integrare gli strumenti, in questo caso si necessita del provider “VMware vSphere”.
Consultando la documentazione del provider direttamente dal sito web di Terraform 2 si scrive il codice necessario per creare una macchina virtuale partendo dal template appena creato in VMware vSphere.
Terraform richiede di scrivere il codice in files con estensione .tf. Si è quindi scritto il codice seguente nel file server.tf :
provider " vsphere " {
user = "${ var . vsphere_user }"
password = "${ var . vsphere_password }"
vsphere_server = "${ var . vsphere_server }"
# If you have a self - signed cert
allow_unverified_ssl = true }
data " vsphere_datacenter " "dc" { name = " EOC "
}
data " vsphere_datastore " " datastore " { name = " DS_Terraform_01 "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_resource_pool " " pool " { name = " Linux / Resources "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_compute_cluster " " compute_cluster " { name = " Linux "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_network " " network " { name = " V108 "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
2
}
data " vsphere_virtual_machine " " template " { name = " ubuntu -16.04 "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
resource " vsphere_virtual_machine " "vm" { name = " terraform - test "
resource_pool_id = "${ data . vsphere_resource_pool . pool .id}"
datastore_id = "${ data . vsphere_datastore . datastore .id}"
num_cpus = 2 memory = 2048
guest_id = "${ data . vsphere_virtual_machine . template . guest_id }"
scsi_type = "${ data . vsphere_virtual_machine . template . scsi_type }"
network_interface {
network_id = "${ data . vsphere_network . network .id}"
adapter_type = "${ data . vsphere_virtual_machine . template . network_interface_types [0] }"
}
disk {
label = " disk0 "
size = "${ data . vsphere_virtual_machine . template . disks .0. size }"
eagerly_scrub = "${ data . vsphere_virtual_machine . template . disks .0. eagerly_scrub }"
thin_provisioned = "${ data . vsphere_virtual_machine . template . disks .0. thin_provisioned }"
} clone {
template_uuid = "${ data . vsphere_virtual_machine . template .id}"
customize {
dns_server_list = [" 172.30.116.137 ", " 172.30.116.138 ", " 172.31.128.10 "]
dns_suffix_list = [" eoc .ch", " eoc . net "] linux_options {
host_name = " terraform - test "
domain = " eoc .ch"
time_zone = " Europe / Zurich "
network_interface { ipv4_address = " 172.31.146.19 " ipv4_netmask = 20 } ipv4_gateway = " 172.31.144.1 " } } }
In sintesi, questo codice descrive la creazione di una macchina virtuale utilizzando VMware vSphere. Nel blocco di codice “provider” viene configurato il provider per collegarsi al server vSphere sul quale operare.
In seguito nei blocchi “data” vengono selezionati gli elementi necessari per descrivere la macchina virtuale che si vuole creare. Qui si definisce quale Datacenter usare, quale cluster di hosts, quale datastore, quale Virtual Network (VLAN).
I valori che sono stati inseriti sono relativi all’istanza di VMware vSphere di EOC sulla quale si intende creare le macchine virtuali con Terraform. Questi elementi (data) non vengono gestiti da Terraform ma vengono usati solo in lettura.
Nel blocco “resource” viene invece definita la risorsa che Terraform deve effettivamente gestire e quindi creare, modificare o distruggere in base alle necessità.
Essendo questo il primo tentativo di integrazione tra Terraform e VMware vSphere, diversi parametri sono stati impostati manualmente. Altri, invece sono stati salvati in un file se-parato, chiamato variables.tf. Terraform ricerca le variabili in questo file se non sono state definite all’interno del file stesso, per esempio la configurazione del provider.
Terraform necessita di scaricare i provider utilizzati nel file server.tf, occorre quindi eseguire il seguente comando:
Figura 3.1: Installazione del plugin per il provider vsphere
Una volta scaricati i provider necessari, Terraform è pronto per applicare quanto descritto nel file server.tf.
Terraform, prima di applicare le modifiche, mostra un piano di esecuzione, che illustra quali saranno le azioni intraprese e quindi rende prevedibile il cambiamento. L’operatore deve confermare di voler eseguire il piano proposto con “yes”.
Si applica il file server.tf con il seguente comando: $ terraform apply
Terraform mostra in dettaglio quali sono i parametri che verranno usati per creare la risorsa richiesta, ed infine conteggia le risorse da aggiungere, modificare o distruggere, e richiede conferma:
Dopo la conferma, Terraform procede con la creazione della macchina virtuale richiesta, clonando il template, e impostando i valori richiesti, ad esempio hostname ed indirizzo IP. Al termine della creazione si verifica che la macchina virtuale sia raggiungibile:
Figura 3.3: Verifica della raggiungibilità via rete della VM creata
3.2.5
Sostituzione delle VM con Terraform
Si ipotizza che la macchina virtuale creata in precedenza necessita ora di applicare gli ultimi aggiornamenti. Come previsto dal concetto di infrastruttura immutabile, si prepara una nuova versione della macchina virtuale.
Seguendo il flusso di sostituzione definito in precedenza, si crea il nuovo template su VMware vSphere:
• Clonazione del template v1.0, creando così il template v2.0 • Conversione del template v2.0 a macchina virtuale
• Installazione degli aggiornamenti sulla macchina virtuale v2.0 • Conversione della macchina virtuale v2.0 a template
Ora il template v2.0 è pronto, si modifica la definizione della VM nel file server.tf, in partico-lare si modifica la riga di codice che indica quale template utilizzare:
data " vsphere_virtual_machine " " template " { name = " ubuntu -16.04 _v2 .0"
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
Ora si applica la modifica:
Figura 3.4: La risorsa vsphere_virtual_machine viene sostituita
Notare che la VM viene sostituita (1 to add, 0 to change, 1 to destroy), Terraform tramite l’ID del template, riconosce che è cambiato, questo comporta la creazione di una nuova VM e la distruzione della VM versione v1.0.
Applicando il cambiamento, Terraform procede in questa sequenza: 1. Distrugge la VM versione v1.0
2. Crea la VM versione v2.0
Si vuole ora incrementare la quantità di VM da creare. Si elimina quindi quanto fatto finora con il seguente comando:
$ terraform destroy
Per incrementare la quantità di risorse si sfrutta la funzionalità di Terraform “count” che permette di specificare una quantità di risorse da creare. Questa aggiunta necessita di ulteriori modifiche al codice tra cui lo spostamento di alcuni parametri in una variabile di tipo “lista di map”, la quale contiene i valori per le VM da creare.
Nel file variables.tf si ha quindi la seguente variabile: variable " hosts " {
description = " List of Hosts to create "
type = " list "
default = [ {
hostname = " terraform -test -1"
domain = " eoc .ch"
ip_address = " 172.31.146.15 "
}, {
hostname = " terraform -test -2"
domain = " eoc .ch"
ip_address = " 172.31.146.16 "
}, ] }
Per quanto riguarda il file server.tf, il file risulta il seguente: provider " vsphere " {
user = "${ var . vsphere_user }"
password = "${ var . vsphere_password }"
vsphere_server = "${ var . vsphere_server }"
# If you have a self - signed cert
allow_unverified_ssl = true }
data " vsphere_datacenter " "dc" { name = " EOC "
}
data " vsphere_datastore " " datastore " { name = " DS_Terraform_01 "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_resource_pool " " pool " { name = " Linux / Resources "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_compute_cluster " " compute_cluster " { name = " Linux "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_network " " network " { name = " V108 "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
data " vsphere_virtual_machine " " template " { name = " ubuntu -16.04 "
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
resource " vsphere_virtual_machine " "vm" {
count = "${ length ( var .dev - hosts )}"
name = "${ lookup ( var .dev - hosts [ count . index ], " hostname ")}"
resource_pool_id = "${ data . vsphere_resource_pool . pool .id}"
datastore_id = "${ data . vsphere_datastore . datastore .id}"
num_cpus = 2 memory = 2048
scsi_type = "${ data . vsphere_virtual_machine . template . scsi_type }"
network_interface {
network_id = "${ data . vsphere_network . network .id}"
adapter_type = "${ data . vsphere_virtual_machine . template . network_interface_types [0] }"
}
disk {
label = " disk0 "
size = "${ data . vsphere_virtual_machine . template . disks .0. size }"
eagerly_scrub = "${ data . vsphere_virtual_machine . template . disks .0. eagerly_scrub }"
thin_provisioned = "${ data . vsphere_virtual_machine . template . disks .0. thin_provisioned }"
}
clone {
template_uuid = "${ data . vsphere_virtual_machine . template .id}"
customize {
dns_server_list = "${ var . dns_server_list }"
dns_suffix_list = "${ var . dns_suffix_list }"
linux_options {
host_name = "${ lookup ( var .dev - hosts [ count . index ], " hostname ")}"
domain = "${ lookup ( var .dev - hosts [ count . index ], " domain ")}"
time_zone = " Europe / Zurich "
}
network_interface {
ipv4_address = "${ lookup ( var .dev - hosts [ count . index ], " ip_address ")}" ipv4_netmask = 20 } ipv4_gateway = " 172.31.144.1 " } } }
Notare la presenza del parametro “count” che viene impostato in modo dinamico dalla quan-tità di host definiti nella variabile “hosts” sfruttando la funzione di Terraform lenght(). Per
Si applica quindi la nuova definizione: $ terraform apply
Figura 3.5: L’applicazione della definizione terminata con successo
Le macchine virtuali sono create ed avviate, si effettua ora la medesima operazione di sostituzione, ma in questo caso le macchine virtuali da sostituire sono 2.
Si modifica quindi la versione del template alla v2.0: data " vsphere_virtual_machine " " template " {
name = " ubuntu -16.04 _v2 .0"
datacenter_id = "${ data . vsphere_datacenter .dc.id}"
}
Si applica ora la nuova definizione, in questo caso si decide di limitare il parallelismo ad 1, questo per evitare che entrambi i server vengano sostituiti allo stesso tempo lasciando le ipotetiche applicazioni senza risorse da utilizzare. Limitare il parallelismo significa limitare la quantità di nodi che Terraform interpreta parallelamente.
$ terraform apply -- parallelism =1
Figura 3.6: Viene richiesta la conferma per la sostituzione delle macchine virtuali
Figura 3.8: Creazione delle nuove macchine virtuali
Figura 3.9: L’avvenuta sostituzione delle macchine virtuali
La sostituzione viene effettuata, ed il risultato finale ottenuto è corretto, ossia avere due macchine virtuali della versione v2.0.
Purtroppo, però, il processo di sostituzione delle macchine virtuali avviene in modo differen-te da quanto desiderato.
Monitorando l’avanzamento del processo di sostituzione si nota la seguente discrepanza nella sequenza delle operazioni:
Tabella 3.2: Sequenza di sostituzione delle macchine virtuali
Sequenza di sostituzione desiderata Sequenza di sostituzione effettiva 1. Distruzione VM terraform-test-1 (v1.0) 1. Distruzione VM terraform-test-1 (v1.0) 2. Creazione VM terraform-test-1 (v2.0) 2. Distruzione VM terraform-test-2 (v1.0) 3. Distruzione VM terraform-test-2 (v1.0) 3. Creazione VM terraform-test-1 (v2.0) 4. Creazione VM terraform-test-2 (v2.0) 4. Creazione VM terraform-test-2 (v2.0)
Terraform, alla versione attuale, è poco configurabile sotto il punto di vista dell’ordine di inter-pretazione dei nodi e quindi delle operazioni da eseguire. Non è possibile modificare l’ordine di applicazione del piano per la risorsa singola, ma solo fra risorse separate, utilizzando le dipendenze.
Con questo approccio, rimane quindi il problema che per un determinato tempo, nel caso specifico 1 minuto e 10 secondi circa, non vi è alcuna macchina virtuale per eseguire le applicazioni.
3.2.6
Terraform lifecycle
Per ovviare alla problematica esposta alla sottosezione 3.2.5, si è analizzato ulteriormente le possibilità offerte da Terraform per evitare di distruggere tutte le macchine prima di creare le nuove risorse.
Durante la ricerca della possibile soluzione si è preso in considerazione un’opzione di Ter-raform applicabile alle risorse. Si tratta di un blocco di configurazione della risorsa, nel caso specifico della risorsa di tipovsphere_virtual_machine. Questo blocco di configurazione permette di impostare un valore booleano alla chiave “create_before_destroy”.
Questo flag viene usato per assicurare che il rimpiazzo di una risorsa venga creato prima che l’originale venga distrutta. L’opzione viene utilizzata come segue:
resource " vsphere_virtual_machine " "vm" { ... lifecycle { create_before_destroy = true } ... }
Questa funzionalità di Terraform potrebbe potenzialmente risolvere il problema esposto alla sottosezione 3.2.5.
La sequenza di sostituzione ottenuta risulterebbe la seguente: 1. Creazione della VM terraform-test-1 (v2.0)
2. Creazione della VM terraform-test-2 (v2.0) 3. Distruzione della VM terraform-test-1 (v1.0) 4. Distruzione della VM terraform-test-2 (v1.0)
Questa sequenza è comunque differente da quella definita in precedenza, ma soddisfa il principale requisito, ossia quello di avere sempre delle risorse computazionali a disposizione per poter eseguire le applicazioni.
Per quanto possa sembrare una soluzione rapida ed ottimale, l’ottenimento di questa se-quenza, con le attuali configurazioni statiche di rete, non è immediato.
Si intuisce facilmente che per un periodo di tempo vi saranno 2 macchine virtuali che hanno lo stesso indirizzo IP e addirittura lo stesso hostname. Anche questo scenario è inaccetta-bile.
Sono comunque stati effettuati alcuni tentativi per verificare l’ipotesi fatta in precedenza e, come previsto, si sono riscontrati conflitti tra le macchine virtuali. A partire dal nome delle VM stesse in VMware vSphere:
Figura 3.10: Errore di applicazione del piano
Ipotizzando che si riuscisse a creare le macchine virtuali con lo stesso indirizzo IP e hostna-me. Se ci fossero state delle applicazioni in esecuzione sulle macchine virtuali, ci sarebbero stati sicuramente conflitti tra le 2, il che risulterebbe in grandi rischi di riscontrare errori, e quindi disservizi per gli utenti finali.
In conclusione, questo primo approccio di gestione delle macchine virtuali su VMware vSphere con Terraform (con IP e hostname statici), non ha portato miglioramenti, se non quello di essere in grado di creare le macchine virtuali.
Nelle sezioni seguenti si valuta e si analizza cosa è necessario per un approccio più dina-mico verso l’infrastruttura immutabile.
