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.