Uso di un server dentro una Virtual Machine

L’idea `e quella di sviluppare lavorando dal proprio sistema operativo di preferenza (host ) ma ottenere una preview del sistema in sviluppo eseguendo i suoi sorgenti dentro un sistema operativo virtualizzato (guest ) dello stesso tipo di quello richiesto dal progetto. PRO Permette di scovare la quasi totalit`a dei tipici bug dovuti all’uso di sistemi ope-

rativi diversi.

PRO Permette di portare avanti pi`u progetti facendo coesistere pi`u versioni di software senza creare conflitti e senza inquinare la worksation.

PRO Permette di praticare approcci distruttivi in quanto in caso di disastri `e semplice ripristinare un backup e non serve l’intervento di un sistemista.

CONTRO Occorre escogitare un sistema per portare dopo ogni modifica i file del pro- getto (che risiedono sulla macchina fisica host) dentro al sistema operativo guest. Esistono varie possibilit`a quali l’uso di protocolli di trasferimento o network share, ma ognuna presenta un compromesso da ottimizzare.

CONTRO Questa proposta (come le altre) condivide il problema per cui quando oc- corre fare una modifica sull’ambiente di produzione (es. l’installazione di un nuovo modulo PHP) occorre propagarla manualmente su tutte le istanze di tutti gli svi- luppatori. Questa cosa oltre ad essere una attivit`a tediosa che interferisce con il flusso naturale di sviluppo rischia di mettere in circolazione diverse VM di sviluppo sollevando problemi di integrazione futuri.

CONTRO L’immagine configurata specificatamente per il progetto pu`o pesare anche diversi GB quindi non `e facilmente portabile.

CONTRO Una volta costruita questa VM a distanza di tempo `e difficile dire quali tool erano stati installati all’interno, con quali prassi e per quali scopi. In generale il procedimento `e di difficile ripetizione se operato manualmente.

CONTRO Nel caso di doversi trovare a lavorare in una situazione di emergenza (es. da una workstation diversa, magari in viaggio) `e molto laborioso ricreare il corredo minimo per eseguire il sistema.

3.4.2

Vagrant

Tra le varie possibilit`a elencate, quella basata sulla virtualizzazione `e quella pi`u promet- tente perch´e prende il meglio dalle altre due soluzioni.

Affiancandovi l’uso dell’automazione questa soluzione pu`o diventare ottima.

Vagrant `e lo strumento che abbiamo scelto per rendere il processo di

creazione della Virtual Machine uniforme, ripetibile e veloce. Le entit`a chiave sono le seguenti:

Vagrantfile ´E il file descrittore (scritto in linguaggio Ruby) che incapsula quali sono le caratteristiche che deve avere la VM e quali sono le procedure da fare per crearla ed amministrarla.

Il tool vagrant legge le specifiche da questo file e mette a disposizione dello svilup- patore una serie di comandi per eseguire in maniera automatizzata le procedure di maintenance sulla VM (creazione, prima preparazione, avvio, reboot eccetera). Questo file deve essere distribuito insieme ai sorgenti versionandolo sul repository in modo che ogni sviluppatore coinvolto nel progetto possa processarlo sulla propria workstation per confezionare la VM necesaria per il progetto.

Ogni volta che per la soluzione sviluppata risulta necessario dotare gli ambienti di nuove features, queste devono essere codificate nel vagrantfile, in modo che ogni sviluppatore possa percepire queste modifiche ed allineare il proprio ambiente. Provider La tecnologia vagrant permette di generare in maniera automatica delle vir-

tual machines ma non `e una tecnologia di virtualizzazione.

Per questo si appoggia ad altri servizi esterni che devono essere disponibili a livello di sistema. Attraverso dei plugin `e possibile supportare qualunque provider ma nativamente `e gi`a possibile usare Virtual Box, VM Ware, Docker e Hyper-V. Noi abbiamo scelto Virtual Box perch´e `e una soluzione che eravamo gi`a abituati ad usare anche per altri scopi ed ha il vantaggio di permettere l’esecuzione di qualsiasi OS (mentre ad esempio il provider Docker ha la limitazione di non permettere di eseguire OS diversi da quelli Linux-based).

Box I box sono immagini di sistemi operativi pre installati prelevabili da repository pubblici ed il vagrantfile deve indicare quale usare per inizializzare l’hard disk virtualizzato della VM al momento della sua prima creazione.

L’azienda che supporta il software Vagrant offre un catalogo di boxes ufficiale9

contenente le principali distribuzioni libere.

Volendo `e possibile caricare delle boxes personalizzate ma questo comporta il paga- mento di un canone. Noi abbiamo preferito realizzare le nostre macchine partendo da una box di base ed eseguendo una routine di configurazione.

Quella che abbiamo scelto sia per l’ambito platform che per quello app `e la ubuntu/xenial64 che corrisponde ad una Ubuntu Linux a 64bit del 2016.

Script di provision Sono gli script che il tool Vagrant invocher`a a macchina avviata con lo scopo di prepararla per l’uso specifico del progetto. Tipicamente `e in questi script che si codificano i comandi shell per l’installazione dei software che devono essere resi disponibili a bordo della VM.

L’esecuzione di questi script pu`o essere programmata attraverso il vagrantfile per avvenire solo durante la fase di provision oppure ad ogni avvio della macchina. Ho trovato interessante l’organizzazione proposta da [16] che prevede di suddividere la procedura di provisioning in 3 script e di ospitarli in una directory bootstrap insieme alle risorse da essi impiegate.

Spesso `e infatti indispensabile portare dentro l’ambiente virtualizzato anche spe- cifici files di configurazione che non possono essere recuperati dalla rete come i software.

Sono un esempio di questi i certificati SSL, i file di configurazione dei virtual host di Apache ed i file di identit`a SSH. Tutto questo sempre nell’ottica di creare una Vagrant Machine il pi`u simile possibile all’host di produzione.

I comandi della procedura di installazione sono stati suddivisi secondo questo criterio:

01-prepare-xenial64.sh Contiene i comandi di preparazione dell’ambiente, in- stallando tutti i servizi a livello di sistema necessari.

Essendo la nostra installazione una Xenial 16.04 dispone del package manager della famiglia Ubuntu che permette di installare molto facilmente i software con il comando: apt-get install <package-name>

Sono un esempio di comandi eseguiti in questa fase quelli per installare a livello di sistema i server Apache e MySQL, l’interprete PHP, l’ambiente di esecuzione Node.js, i vari package manager ed i task runner che hanno una interfaccia a linea di comando.

Questo script deve essere eseguito una tantum al momento del primo avvio della macchina, detto fase di provision.

02-configure-app-for-xenial64 In questo script vengono eseguite le configura- zioni di sistema necessarie per far funzionare l’applicazione su questa parti- colare distribuzione.

Sono un esempio di questi comandi la creazione del database, l’installazione dei moduli PHP necessari per supportare le librerie usate a livello software (es. SOAP), l’installazione dei certificati SSL e dei virtual hosts in Apache, la creazione di utenti di sistema ed il setup del cron daemon.

Anche questo script deve essere eseguito una tantum.

03-prepare-application Questo script a differenza degli altri viene configurato per essere eseguito ad ogni avvio della macchina.

In questa procedura ha senso programmare tutte quelle attivit`a di routine da eseguire all’inizio di una sessione di lavoro.

Sono un esempio di queste il recupero delle dipendenze aggiornate tramite i package manager (NPM, Composer e Bower), l’allineamento del database in base alle migrations ed una prima compilazione di sorgenti (in modo che il software sia subito eseguibile in preview senza eseguire alcun comando manualmente).

Plugins Vagrant dispone di un ecosistema di plugin sviluppati dalla community per gli scopi pi`u disparati. Quello che abbiamo trovato di fondamentale utilit`a `e vagrant-hostmanager.

Essendo la nostra soluzione web based, affinch´e sia possibile vedere in esecuzione il sistema virtualizzato occorre mappare il dominio della web app sull’indirizzo IP locale della VM.

Questa attivit`a pu`o essere fatta manualmente modificando il file hosts di sistema cos`ı da truccare la risoluzione DNS per quel paricolare nome.

Il plugin sopra menzionato aggiunge questa configurazione all’avvio della macchina e la rimuove al suo spegnimento in modo da non lasciare refusi di configurazione nel sistema e di permettere di tornare ad accedere alla versione pubblica del sistema quando la VM `e spenta.