Immutable Infrastructure applied to a real use casetesi.supsi.ch/2393/1/DOC_OGGIAN.pdf · Il prototipo sviluppato si interfaccia con la piattaforma di virtualizzazione dei server

Immutable Infrastructure applied to a realuse case

Studente/i

Elia Oggian

Relatore

Angelo Consoli

Correlatore

Angelo Consoli

Committente

Elia Oggian (EOC)

Corso di laurea

Ingegneria informatica (PAP)

Modulo

M00002P Progetto di diploma

Anno

2018

Data

4 settembre 2018

i

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 . . . . . . . . . . . . . . . . . . . . . . . 8

1.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.6 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.7 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Immutable Infrastructure applied to a real use case

ii INDICE

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

3.8 Soluzione parziale del bug di Terraform . . . . . . . . . . . . . . . . . . . . . 88


iii

4 Conclusioni 91

4.1 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.2.1 Creazione dei template da codice . . . . . . . . . . . . . . . . . . . . 93

4.2.2 Ulteriori integrazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93


iv INDICE


v

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.17 Rinnovo della lease da parte del DHCP client verso il DHCP server . . . . . . 52

3.18 Configurazione delle interfacce della macchina virtuale . . . . . . . . . . . . . 53


vi ELENCO DELLE FIGURE

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

3.45 Flusso di distruzione dell’infrastruttura . . . . . . . . . . . . . . . . . . . . . . 87


vii

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

3.5 Parametri del body della richiesta POST . . . . . . . . . . . . . . . . . . . . . 74


viii ELENCO DELLE TABELLE


1

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.


2 Abstract


3

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

• Le VM non sono realmente testate prima di andare in ambiente di produzione


4 Progetto assegnato

• 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.)


5

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.

La completa infrastruttura è quindi di gestione di EOC.


6 Introduzione

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 quale gli risponde dandogli le informazioni

richieste, per esempio quelle del paziente. Ogni microservizio è responsabile di fornire

determinate informazioni.

Requests

ClientResponses

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

• Picco giornaliero di circa 2400 client concorrenti


7

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

Use

rs

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


8 Introduzione

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

Virtual machine manager Gestire le macchine virtuali sugli host fisici


9

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 machinemanager

Request forwarding and load balancing

Load BalancerRequests

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.


10 Introduzione

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 modo

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

Figura 1.4: Applicazione delle modifiche senza infrastruttura immutabile


11

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 hannogenerato problemi negli altri ambienti.

• Sostituire i server in un intero ambiente in modo rapido e prevedibile minimizzando iltempo 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.


12 Introduzione

Security update

Upgrade docker versionChange to configuration

Add missing file

IT Operators

Virtual servers

v2.0v1.0

v2.0 v1.0

v2.0v1.0

v2.0v1.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.


13

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 configurazione

sui vari server e li si rende univoci ed irriproducibili.


14 Analisi e progettazione

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 maitestate 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


15

è 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:

1Installare l’applicazione sul server ed avviarla



VM1 VM2

LoadBalancer

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

LoadBalancer

App-1 App-2

Clients

Java JDK 1.8.172 ... ... ...

Java JDK 1.8.162 ... ... ...

Figura 2.2: Due server considerati "Pets"


17

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

LoadBalancer

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

LoadBalancer

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.


19

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-agentrancher-agent

Figura 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.


21

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 ilmedesimo.

– 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 distruzionedopo 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 (principalmente server

Windows e Linux).2Fonte: Gartner Magic Quadrant for x86 Server Virtualization Infrastructure



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 alcodice 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 perpoi venire utilizzato per la creazione di una VM, questa dipendenza viene risolta da

Terraform.


23

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 dipasswords)

• 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-

ne v0.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.

A partire da queste immagini create con Packer, si possono creare macchine virtuali sulla

piattaforma in uso.



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


25

• 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.

• Applicazione delle modifiche utilizzando Terraform in un job Jenkins.


27

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 servervirtuali.

• Sistema di integrazione tra i componenti dell’infrastruttura per la gestione delle risorsee 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 quantogià 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 isistemi 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


29

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 versionev1.0.

• Esecuzione dei container docker rancher-agent sulle macchine virtuali create peraggiungerle in Rancher.

• Configurazione del servizio su Barracuda ADC Load Balancer aggiungendo i serverreali 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

raggiungere i server, i quali rispondo alle richieste.


30 Implementazione

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 gliaggiornamenti 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 templateversione 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.


31

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

• Rete


32 Implementazione

– 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

Questi semplici passi sono sufficienti per installare Terraform su una macchina linux.


33

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 valoripossono 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 vieneinterpretato 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"

}

}

1Fonte: https://www.terraform.io/docs/configuration/syntax.html


34 Implementazione

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"


}

data "vsphere_compute_cluster" "compute_cluster" {

name = "Linux"


}

data "vsphere_network" "network" {

name = "V108"


2Fonte: https://www.terraform.io/docs/providers/vsphere/index.html


35

}

data "vsphere_virtual_machine" "template" {

name = "ubuntu -16.04"


}

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"

}


36 Implementazione

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:

$ terraform init


37

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:

Figura 3.2: Richiesta di conferma per l’applicazione del piano


38 Implementazione

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:


name = "ubuntu -16.04 _v2.0"


}

Ora si applica la modifica:

$ terraform apply


39

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"

},

]

}


40 Implementazione

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"


}

data "vsphere_resource_pool" "pool" {

name = "Linux/Resources"


}

data "vsphere_compute_cluster" "compute_cluster" {

name = "Linux"


}

data "vsphere_network" "network" {

name = "V108"


}


name = "ubuntu -16.04"


}


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

guest_id = "${data.vsphere_virtual_machine.template.guest_id}"


41

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

leggere i valori della variabile “hosts” si sfrutta invece la funzione lookup().


42 Implementazione

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:


name = "ubuntu -16.04 _v2.0"


}

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.7: Distruzione delle vecchie macchine virtuali


43

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.

Questo scenario non è accettabile in EOC in quanto le applicazioni devono essere sempre

disponibili per minimizzare il tempo di downtime dell’applicativo Geco.


44 Implementazione

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 tipo vsphere_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:


...

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.


45

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.


46 Implementazione

3.3 Secondo approccio di integrazione con VMware

In questa sezione si valuta e si analizza un approccio alternativo all’infrastruttura immutabile.

Nella sezione precedente si è messo in evidenza quanto un’infrastruttura statica (a livello di

indirizzi IP e hostname) renda difficile l’introduzione dei concetti di infrastruttura immutabile.

In particolare sono emersi i seguenti aspetti, che costituiscono i principali ostacoli per l’ot-

tenimento di una sequenza di sostituzione delle macchine virtuali compatibile con l’opzione

“create_before_destroy”:

• Mancanza di flessibilità sugli indirizzi IP

– Si utilizzano indirizzi IP statici

– Nessun utilizzo di DHCP

• Mancanza di flessibilità sui nomi

– Record DNS creati manualmente per ogni server (macchina virtuale)

Valutando questi aspetti si decide di optare l’utilizzo di un DHCP Server per distribuire in

maniera dinamica gli indirizzi IP. L’utilizzo di un DHCP server implica la creazione di una

nuova VLAN.

3.3.1 VLAN dedicata

Per il primo approccio è stata utilizzata la VLAN 108, la quale è dedicata ai server virtuali, i

quali hanno una configurazione statica dell’indirizzo IP.

Per la VLAN 108 non vi sono configurati gli helper address, questo significa che le richieste

di DHCP DISCOVERY non vengono inoltrate a nessun DHCP server. Il client non rice-

ve quindi nessuna DHCP OFFER, di conseguenza non riceve un indirizzo IP in maniera

dinamica.


47

Figura 3.11: Flusso delle richieste e risposte DHCP

Per questo motivo occorre oltre ad un DHCP server anche una nuova VLAN con gli helper

address configurati verso il DHCP Server.

Si richiede quindi al gruppo networking la creazione della VLAN 112, la quale ha configurati

come helper address i 2 domain controller del dominio eoc.ch, che hanno attivo il ruolo di

DHCP server in modalità LoadBalance (Attivo/Attivo).

Vengono quindi fornite le specifiche per la VLAN creata:

Tabella 3.3: Dettagli della VLAN 112

Opzione Valore

VLAN Tag 112

Subnet Address 172.30.254.0

Gateway 172.30.254.1

Mask 255.255.255.0

Helper Address 172.31.128.10, 172.31.128.11

La VLAN creata viene configurata sul distributed switch in VMware per poterla assegnare

all’interfaccia virtuale della macchina virtuale.

3.3.2 DHCP server

In questa sezione si documenta la configurazione del DHCP server per rispondere alle

richieste DHCP fatte dalle macchine virtuali create da Terraform.

Importante notare che non vi è nessuna interazione tra Terraform e il DHCP server, ma la

comunicazione avviene direttamente dalla macchina virtuale verso il DHCP server.


48 Implementazione

Viene quindi creato uno scope DHCP dedicato al range IP della VLAN 112:

Figura 3.12: Configurazione dello scope DHCP

Vengono esclusi dalla distribuzione dinamica gli indirizzi da 172.30.254.1 a 172.30.254.9, si

riservano questi indirizzi per utilizzi statici, quale ad esempio appunto il gateway (172.30.254.1).

Si impostano quindi le scope options, volte a configurare il client DHCP, ovvero le macchine

virtuali create da Terraform. Nelle scope options si definiscono i seguenti valori:

Tabella 3.4: Attributi delle scope options

Opzione Valore

003 Router 172.30.254.1

006 DNS Servers 172.31.128.10,172.31.128.11

015 DNS Domainame eoc.ch


49

3.3.3 DNS server

In questa sezione si documenta la configurazione del DNS server, in particolare l’interazione

tra DHCP Server e DNS server.

Quando un DHCP server rilascia una DHCP lease, ovvero assegna un indirizzo IP ad un

client, è necessario che vengano creati (o aggiornati se già esistenti) i record DNS relativi

ad essa (record A e record PTR per la reverse).

Lo scope DHCP viene quindi configurato per eseguire tali aggiornamenti ed eliminazioni in

caso di lease eliminata:

Figura 3.13: Configurazioni dell’interazione tra DHCP e DNS

Questa configurazione, tuttavia, è considerata insicura dalla zona eoc.ch del DNS server, il

quale non accetta aggiornamenti non autentificati ai record DNS:


50 Implementazione

Figura 3.14: Configurazione della zona eoc.ch in DNS

Per permettere al DHCP server di eseguire degli aggiornamenti dinamici ai record DNS,

occorre creare un utente di servizio (in dominio) che ha lo scopo di effettuare questi aggior-

namenti.

Si crea quindi l’utente !servicedhcpdnsupdate in Active Directory.

L’utente appena creato viene quindi impostato sul DHCP server quale credenziale per ese-

guire gli aggiornamenti dinamici al DNS:


51

Figura 3.15: Configurazione delle credenziali per l’aggiornamento dei record sul DNS

Figura 3.16: Credenziali per l’aggiornamento dei record sul DNS

Il DNS server e il DHCP server sono configurati per interagire in modo sicuro e ottimale per

la gestione dinamica di indirizzi IP e nomi di dominio.


52 Implementazione

Un client nella VLAN 112 che fa una DHCP DISCOVERY riceve ora una DHCP OFFER, e

quindi un indirizzo IP:

Figura 3.17: Rinnovo della lease da parte del DHCP client verso il DHCP server

3.3.4 Creazione dinamica delle VM con Terraform

In questa sezione si definisce il codice Terraform per creare le macchine virtuali in maniera

dinamica.

Prima di continuare, si distrugge quanto creato con Terraform, questo perché modificando la

definizione di Terraform, non è più possibile distruggere le macchine virtuali con Terraform

ma è necessario farlo manualmente.

$ terraform destroy

Si inizia quindi con la corretta configurazione di rete del template della macchina virtuale in

VMware vSphere.

Documents

Immutable Infrastructure applied to a real use casetesi.supsi.ch/2393/1/DOC_OGGIAN.pdf · Il prototipo sviluppato si interfaccia con la piattaforma di virtualizzazione dei server