host | Tutti per Linux

Docker ed i Microservices

Su questo portale abbiamo gia piu’ volte scritto e descritto la tecnologia che sta dietro al progetto Docker, sicuramente una delle nuove scoperte informatiche degli ultimi anni, a livello dell’uscita della Virtualizzazione; ma nonostante tutto, non sempre e’ facile capire in poche righe concetti nuovi non sempre semplici da comprendere, quindi eccovi un nuovo articolo, che fara’ parte di una piccola serie di episodi, in cui cercheremo di fare ulteriormente luce su cos’e’ e come funziona questo fantastico progetto.

Dagli script PHP ai microservice
Alla fine degli anni ’90 i siti erano per lo più ancora statici, con qualche script CGI , o altre soluzioni oggi considerate poco eleganti. Poi arrivarono ASP JAVA e PHP. Da li in avanti un progetto Web era prettamente fondato, ad esempio, su file PHP, CSS e immagini; in queste soluzioni tecnologiche era sufficiente copiare tutti questi file su uno spazio hosting e al più modificare qualche file di configurazione, per ricreare un nuovo ambiente web e ricominciare su di un nuovo sito.

Venti anni dopo gli scenari sono drasticamente diversi, le architetture SOA hanno preso piede, si è iniziato a parlare di microservice e tutto è diventato più complesso. Un’applicazione web, soprattutto in ambito enterprise, non è più la directory di cui parlavamo prima, ma un’ insieme di componenti autonomi, ognuno col suo ciclo di vita indipendente, rilasciati su macchine diverse e a ritmi sempre crescenti.

Una complessità così grande non può piu’ essere amministrata con il vecchio copia e incolla, diventa cosi’ necessario uno strumento affidabile che consenta di manipolare o spostare intere applicazioni limitando errori umani, checklist lunghissime da controllare e tutti i passaggi snervanti e carichi di rischi necessari per il deployment.

I container
Cosi’ come nell’industria dei trasporti nacque l’esigenza di una soluzione unica intercambiabile, vennero cosi creati i container: contenitori multiuso, realizzati in formati standard che possono essere passati con facilità da un camion a una nave, poi magari su un treno merci e così via.

Anche nel campo informatico abbiamo bisogno di qualcosa che “contenga” la nostra applicazione, che ci consenta di manovrarla con facilità senza sapere nulla, o quasi, riguardo il suo contenuto. In pratica, abbiamo bisogno anche noi del nostro container!

Docker
L’intuizione del team di Docker è stata quella di prendere il concetto di container e costruirvi attorno un’ ecosistema che ne semplificasse l’impiego. Di questo ecosistema fanno parte una serie di tool: Docker engine, Docker Toolbox, Swarm, Kitematic e tant’ altro ancora per rendere i container qualcosa di accessibile anche a chiunque, sfruttando anche il fatto che la community di sviluppatori che utilizza Docker è davvero molto vasta. Ad esempio, Docker Hub è un repository di container pubblici pronti per l’uso, mentre il codice sorgente del Docker engine è liberamente disponibile su GitHub e vanta quasi 1500 contributor.

Container VS Virtual Machine
Apparentemente i container e le virtual machine sembrano due concetti molto simili ma, sebbene queste due soluzioni abbiano delle caratteristiche in comune, si tratta di tecnologie profondamente diverse tra loro, così come diverso è anche il modo in cui dobbiamo iniziare a pensare all’architettura delle nostre applicazioni. Possiamo creare un container con la nostra applicazione monolitica all’interno, ma così non sfrutteremmo a pieno la forza dei container e quindi di Docker.

Una possibile architettura software adatta per un’infrastruttura a container è la classica architettura a microservizi. L’idea, in pratica, è quella di scomporre l’applicazione in tante piccole componenti ognuna col suo compito specifico ma capaci di scambiarsi messaggi e di cooperare tra loro, cio’ che e’ alla base dei sistemi SOA. Il deploy di tali componenti avverrà poi effettuato singolarmente, come tanti container.

Uno scenario come quello ipotizzato è assolutamente poco pratico con una macchina virtuale, in quanto ogni nuova macchina virtuale istanziata richiederebbe un bel dispendio di energia per la macchina host. I container, al contrario, sono molto leggeri, poiché effettuano una virtualizzazione completamente diversa da quella praticata dalle macchine virtuali.
Nelle macchine virtuali, lo strumento detto hypervisor si preoccupa di riservare (staticamente o dinamicamente) un certo quantitativo di risorse dal sistema operativo host da dedicare poi ad uno o più sistemi operativi, detti guest o ospiti, inoltre ogni sistema operativo guest sarà completamente isolato dal sistema operativo host. Questo meccanismo è molto dispendioso in termini di risorse, per cui l’idea di associare un micro-servizio ad una macchina virtuale è del tutto irrealizzabile.

I container, d’altro canto, apportano un contributo completamente diverso alla questione, l’isolamento è molto più blando e tutti i container in esecuzione condividono lo stesso kernel del sistema operativo sottostante, host. Scompare completamente l’overhead dell’hypervisor, e un singolo host può arrivare a ospitare centinaia di container.

Docker VS VirtualMachine

Nel prossimo articolo rivedremo come installare Docker tramite i Docker-ToolBox, e come interagire con i container.
Alla prossima

PREMESSA

Una delle crescenti necessità dei grandi sistemi server Linux, cosi come dei piccoli esperimenti casalinghi, è fornire la possibilità ad amministratori, sistemisti ed utenti smanettoni di godere delle funzionalità di più sistemi operativi. Questo genere di richieste può essere soddisfatto dal supporto alla virtualizzazione, ovvero la possibilità di rendere virtuali le risorse hardware di cui un sistema operativo ha bisogno, per poi installare l’intera piattaforma “virtualmente” su di esse. Per capire quanto ciò sia conveniente, si pensi ai dischi che un sistema virtuale utilizza, che in realtà non sono altro che semplici file, e come essi si prestino meglio alle operazioni di backup, ed anche le periferiche virtuali sono facilmente standardizzabili e, quindi, uniformabili; ciò rende l’hardware (che può essere cosi’ molto vario…), “virtualmente compatibile” con qualsiasi sistema virtualizzato, azzerando i problemi di compatibilità, ed è a questo che serve KVM.

KVM = Kernel-based Virtual Machine
(KVM) è un’infrastruttura di virtualizzazione del kernel Linux. KVM attualmente supporta una completa virtualizzazione usando Intel VT o AMD-V. KVM è implementato come un modulo kernel caricabile, e dotato d’interfaccia grafica, un vero e proprio Virtual Manager Interface , per la gestione completa delle vostre VM. Il progetto nato gia nel 2007, grazie all’opera di Moshe Bar (gia fondatore di Xensource) che fonda l’azienda Qumranet per occuparsi dello sviluppo di questo nuovo modo di fare virtualizzazione. La Qumranet verra’ acuistata circa un anno piu’ tardi direttamente da RedHat che passera’ tutti i suoi progetti di virtualizzazione proprio su KVM.

I vantaggi di KVM
come dicevamo poco fa, per prima cosa KVM è integrato nel kernel di Linux, quindi dal punto di vista di un sysadmin, ci sono molti meno problemi, basta effettuare i normali update della tua distribuzione e sei a posto (per Xen invece sono una vagonata di Patch, non incluse nel kernel).

KVM non richiede alcun kernel modificato lato guest, quindi meno problemi e più libertà per gli utenti. Ed in caso di distribuzioni Linux come guest, anche qui fai i normali update della distro, senza preoccuparci di quale kernel installare (sembra una sciocchezza ma non è così.)

Ciascun guest KVM viene visto a livello di sistema come un normalissimo processo e puo’ essere gestito con i comandi più consueti (top, ps, kill, etc). Xen ad esempio ti obbliga ad usare una vagonata di strumenti e per sapere quanto sta occupando un domU sei costretto ad installare i tools lato client.

KVM è più flessibile in ambienti eterogenei, ad esempio puoi migrare da un nodo 32 bit verso un 64 e viceversa (ovviamente il guest può essere solo a 32 in questo caso, un 64 su un 32 non può andare mentre il 32 può andare sul 64). Puoi migrare da AMD a Intel e viceversa. Xen ti obbliga ad avere un cluster di nodi tutti uguali, o per meglio dire *identici*.

Verificare il supporto alla virtualizzazione

KVM sfrutta il supporto hardware alla virtualizzazione che il processore installato nel PC deve, necessariamente, poter implementare. Molte delle moderne CPU soddisfano questo requisito, considerando che sia AMD che Intel (che insieme raggiungono circa il 98% del mercato dei processori) includono da tempo le tecnologie AMD-V ed Intel VT-x rispettivamente, in grado proprio di supportare la virtualizzazione. Ciò è fondamentale, poiché senza tale supporto hardware, KVM non può funzionare.

Quindi, prima d’installare KVM dobbiamo verificare che l’hardware supporti la virtualizzazione. Per farlo, possiamo digitare, sul terminale, il comando seguente:

Per farlo, possiamo digitare, sul terminale, il comando seguente:

egrep -c ‘(svm|vmx)’ /proc/cpuinfo

Se l’output è diverso da 0, siamo certi che la nostra CPU è compatibile con la virtualizzazione, e possiamo passare al processo di installazione vera e propria. Altrimenti, ahimé, non sarà possibile sfruttare questo potentissimo strumento.

Installare KVM

A questo punto possiamo finalmente installare KVM. La procedura è abbastanza semplice, soprattutto se si utilizzano le maggiori distribuzioni server :

# apt-get install qemu-kvm libvirt-bin bridge-utils virt-manager

Se, invece, non è così, e possiamo avvalerci di yum, utilizzeremo i comandi seguenti:

# yum groupinstall "Virtualisation Tools" "Virtualization Platform"
# yum install python-virtinst

oppure, in alternativa:

# yum install kvm qemu-kvm python-virtinst libvirt libvirt-python virt-manager libguestfs-tools

Terminata l’installazione, c’è ancora un dettaglio da tenere in considerazione. Di norma, le virtual machine di KVM possono essere gestite ed utilizzate soltanto dall’utente root, o da tutti gli utenti appartenenti al gruppo libvirtd. Per questo motivo, se vogliamo utilizzare KVM con il nostro account (diciamo, ad esempio, con l’account pippo), dovremo ultimare l’installazione con il comando seguente:

# adduser pippo libvirtd

Fatto ciò, possiamo verificare che KVM sia stato correttamente installato, riavviando il sistema e verificando che il comando seguente:

$ virsh -c qemu:///system list
@lorenzo:~# virsh -c qemu:///system list

Id    Nome                           Stato

—————————————————-
Se ciò non dovesse accadere, potrebbe non essere stato avviato libvirtd, il demone che gestisce il sistema di virtualizzazione. Possiamo avviarlo con i seguenti comandi:



# chkconfig libvirtd on
# service libvirtd start



A questo punto non resta che configurare in maniera esauriente KVM, ed iniziare a creare ed avviare le macchine virtuali. Se abbiamo a disposizione un ambiente grafico, possiamo affidarci a virt-manager.
virt-manager
Una volta avviato, possiamo subito creare una nuova virtual machine, cliccando sul primo pulsante da sinistra, sulla barra principale della finestra di virt-manager. Qui possiamo:
inserire il nome della macchina virtuale
scegliere come installare il sistema operativo guest (se utilizzando un’immagine ISO locale, o se effettuare un’installazione via network)
selezionare il tipo di sistema operativo che stiamo installando
impostare la quantità di memoria RAM da assegnare al sistema, nonché il numero di CPU
definire alcune impostazioni avanzate, come l’architettura del sistema, nonché le preferenze di rete
Una nota importante riguarda proprio queste ultime impostazioni relative alla rete. Per default, la virtual machine accede ad internet non come macchina a sé stante, ma tramite un NAT bridge che la rende, dal punto di vista della rete, un tutt’uno col sistema host. E’ possibile modificare questa impostazione tramite le Opzioni avanzate subito prima della fine del processo di creazione della macchina virtuale. Ciò può risultare molto utile se si vuole utilizzare la macchina virtuale come server accessibile all’esterno (una situazione abbastanza tipica). Non resta che giocarci il piu’ possibile ed impratichirsi con tutte le opzioni a disposizione. Buon divertimento.