Stefano Marinelli's Blog (Articoli su virtualizzazione)

Docker e la nuova separazione dei servizi

Stefano Marinelli — Tue, 03 Apr 2018 17:45:46 GMT

Se c'è una cosa che mi piace, nell'ambito informatico, è il trovare nuove soluzioni a vecchi problemi. O nuovi problemi a vecchie soluzioni, ma allo scopo di risolvere eventuali punti lasciati in sospeso da tempo, per mancanza di tempo o per mancanza di soluzioni a disposizione.

Una delle questioni più annose, per chi lavora nel settore (ma non solo) è sempre la vecchia scelta operativa: accentrare i servizi su un server o separarli il più possibile?

Continua la lettura… (ulteriori 2 minuti di lettura)

Un assaggio di Proxmox

Stefano Marinelli — Mon, 28 Aug 2017 12:22:14 GMT

Proxmox, la storia

Proxmox nasce nel 2008 come sistema completo di virtualizzazione (alternativo a prodotti come VMWare) "a pacchetto". Lo scopo è sempre stato, ed è ancora, quello di fornire un sistema semplice e pratico di preparazione di hardware fisico allo scopo di ospitare macchine virtuali, il tutto gestito attraverso una comoda interfaccia web.

Fino alla versione 3.0, Proxmox ha sofferto di serie problematiche di gioventù. Pur essendo, infatti, già sufficientemente maturo, c'erano alcuni problemi (bug o mancanza di feature) che non lo rendevano estremamente adatto ad ambienti di produzione importanti. Dalla 3.0 in poi, invece, si è assistito al lancio verso l'olimpo in quanto le funzionalità di base erano ormai mature e affidabili e le nuove opzioni erano tutte incentrate sul renderlo sempre più un prodotto enterprise.

Sviluppato e diretto dall'Austriaca Proxmox Server Solutions GmbH, è un progetto in rapido progresso e con interessantissime funzionalità che si aggiungono versione dopo versione.

Il sistema è interamente Open Source, prevede la possibilità di acquistare un abbonamento (a prezzi molto vantaggiosi) per accedere al repository di aggiornamento enterprise, più collaudato e sicuro di quello standard, e tutto il supporto e l'assistenza necessari al sistemista che ne possa avere necessità.

Continua la lettura... … (ulteriori 7 minuti di lettura)

Un assaggio di Docker

Stefano Marinelli — Sat, 05 Aug 2017 19:30:12 GMT

Preambolo

Ho fatto i primi passi nella virtualizzazione nel lontano 1998. Mi affascinava l'idea di inscatolare un intero computer all'interno del mio PC e non dover più essere schiavo di installare, cancellare, reinstallare, avere due sistemi operativi diversi per scopi diversi contemporaneamente nella stessa macchina e avere eventuali problemi di boot all'aggiornamento di uno ei due.

Sperimentai dunque VMWare e capii subito che la virtualizzazione sarebbe stata il futuro. Nel corso degli anni la penalizzazione sulle prestazioni si è via via assottigliata e nella mia tesi di laurea, nel 2003, mi occupai proprio degli internal di vari virtualizzatori tra cui il neonato i QEMU. Il bello di qemu era proprio la possibilità di emulare piattaforme hardware diverse per lo sviluppo o l'emulazione, e in maniera sufficientemente (per l'epoca) rapida grazie alla traslazione dinamica delle chiamate di sistema, un metodo per l'epoca rivoluzionario. C'erano anche i primordi di Xen, che dava risultati assolutamente interessanti ma richiedeva modifiche al sistema operativo guest. Venne poi fuori un modulo kernel per qemu (divenuto poi KVM, la base dei principali virtualizzatori moderni) che gestiva la virtualizzazione passando direttamente le chiamate all'hardware sottostante, abbattendo l'overhead prestazionale a livelli bassissimi e consentendo di avere un buon numero di VM su un server fisico.

Da allora mi occupo di virtualizzazione ma ho sempre cercato anche altre possibilità proprio perché nell'informatica bisogna sempre avere fame di novità.

Ho lavorato (con estremo successo, ne racconterò prima o poi l'esperienza) già dal 2005 con OpenVZ, che mi ha permesso (per anni) di far girare il mio server principale sia sul VIA EPIA che su un server esterno a cui migravo il tutto in base alle necessità. I container, insomma, mi sono sempre piaciuti.

Nel 2010, ho iniziato a implementare soluzioni basate su FreeBSD proprio per avere le sue jail, ovvero degli ambienti non emulati ma separati dal sistema operativo principale. In pratica, stesso kernel ma userland completamente diversa. Nessun overhead di virtualizzazione ma semplice separazione degli ambienti. Non era un concetto nuovo, infatti Solaris utilizza i container (o zone) già dal 2004, ma di sicuro un concetto vincente: se il mio scopo non è avere sistemi operativi diversi ma solo tenere separati i servizi, perché dover lanciare n macchine virtuali con n sistemi operativi uguali in esecuzione?

Poco dopo è arrivato anche GNU/Linux, e già nel 2011 sperimentavo con lxc, pur sapendo che non c'erano ancora i requisiti di sicurezza necessari, ma avevo già degli strumenti per tenere separati vari ambienti basati su GNU/Linux.

Proprio su lxc si basa Docker, una soluzione di inscatolamento di ambienti, che ne consente la creazione e l'utilizzo su qualsiasi piattaforma compatibile e crea un ambiente standard in un solo comando.

I miei primi passi con Docker

...sono stati disastrosi, come credo quelli di tutti quelli che hanno iniziato ai suoi albori. Docker è un progetto relativamente recente e, come tale, in forte sviluppo. Uno dei problemi, infatti, è che lo sviluppo è rapido e, a volte, distruttivo. Basta un aggiornamento e cambia qualcosa nella riga di comando, nel setup della rete, nella funzionalità e ci si può trovare con un sistema malfunzionante. Il primo passo che feci non fu diverso. Installai Docker, lo misi in funzione per alcuni test, aggiornai alla nuova versione stabile e tutti i miei contenitori smisero di funzionare per variazioni di struttura. Decisi di buttare via tutto e aspettare tempi migliori.

D'altronde si sa come funziona: o una tecnologia diventa sufficientemente matura in poco tempo, oppure muore. Nel primo caso, l'attesa non è così lunga. Nel secondo, non conviene perdere tempo con qualcosa che non avrà futuro.

Alcuni mesi fa ho deciso di rimettere in piedi il discorso. Di solito imparo qualcosa per necessità, poi lo espando e lo riutilizzo. A volte la necessità è puro vezzo privato, magari per fare qualcosa di non strettamente lavorativo ma si sa, l'animo nerd non lo si tiene a freno e, anzi, guai se ciò avvenisse!

Docker su strada

Rimettere in strada Docker non è stato difficile. A oggi, infatti, le cose sono state rese più facili (sia per architetture tradizionali che per le ARM come Raspberry PI o similari) da un rapido & semplice comando:

curl -sSL get.docker.com | sh

ovviamente a patto di avere curl installato, cosa non del tutto scontata in tutte le installazioni (Debian base non ce l'ha).

In un lampo, sono stato pronto col mio eseguibile pronto da usare e libero di fare dei test.

Ho iniziato. Immediatamente mi sono trovato a mio agio sia con la sintassi (anche se, a mio avviso, va ancora un po' uniformata tra un container normale e uno Swarm sia col funzionamento generale. Il vantaggio dell'inscatolamento delle risorse è indubbiamente evidente. Ogni cosa resta nel suo mondo, con le sue dipendenze, senza andare a intaccare o modificare alcunché sul resto del sistema.

Ho subito iniziato ad aver bisogno di alcune funzionalità non ancora presenti nei container presenti nell'hub ufficiale (specialmente per quanto riguarda le architetture ARM in mio possesso) per cui ho esplorato la creazione di una immagine personalizzata. Anche qui semplicità assoluta, un Dockerfile con tutte le istruzioni necessarie e una bella procedura. In un lampo ho avuto tutto il necessario.

Gli Swarm

Uno Swarm è un gruppo di sistemi su cui Docker è installato che si uniscono in un cluster. In uno swarm, ogni worker può far partire uno dei container e metterlo a disposizione. In uno swarm, un container può essere definito come servizio singolo (farne girare sempre uno su uno dei nodi), oppure come servizio multiplo (far girare n copie, che verranno distribuite nei nodi dello swarm) e milioni di sfumature di configurazione.

In uno Swarm, per scelta progettuale, una porta esposta da un container sarà raggiungibile connettendosi all'IP di uno qualunque dei nodi. Se, ad esempio, abbiamo due nodi (nodo1 e nodo2) e un container che espone la porta 80 (un server http), una volta configurato il servizio come parte dello Swarm sarà possibile connettersi al container stesso sia sull'IP del nodo1 che su quello del nodo2.

Conclusioni

Questo articolo voleva essere solo una rapida carrellata su quella che è stata la mia recente esperienza con Docker e sul perché ho deciso non solo di utilizzarlo ma di approfondirne sempre di più le potenzialità.

Seguiranno altri articoli in merito, quando il tempo me lo consentirà, che spiegheranno come ho risolto alcune delle problematiche principali che possono occorrere nell'utilizzo quotidiano e in produzione di un sistema del genere (es: storage condiviso tra nodi, ecc.)

Suggerisco a tutti di cominciare a prendere in considerazione questo tipo di tecnologia, sia per ragioni di sicurezza che di scalabilità e praticità. Volenti o nolenti, sarà il futuro. O il presente.

Analisi delle principali piattaforme di Virtualizzazione: VMware, Proxmox, Hyper-V, oVirt - Bologna, 19 Novembre 2015

Stefano Marinelli — Sat, 17 Oct 2015 18:10:56 GMT

BOLOGNA, 19 NOVEMBRE 2015, ore 9,30 -15,30 - Hotel Mercure (di fronte alla Stazione FF.SS. Bologna Centrale)

Posti limitati: iscrizioni entro il 12 novembre 2015 in ordine di arrivo:

A CHI SI RIVOLGE: Ai direttori degli enti e gli amministratori pubblici e privati. Ai responsabili dei sistemi informativi e ai responsabili degli acquisti informatici (hardware e software). Ai responsabili dei servizi (in particolare Comunicazione, Urp, Servizi anagrafici, Suap) di EE.LL. e aziende gestrici di pubblici servizi.

OBIETTIVI: Il mondo della Virtualizzazione, sia in ambito server che desktop, è cresciuto e riveste un'importanza sempre maggiore. Grandi novità e nuovi contendenti si presentano di anno in anno. Moltissime sono le soluzioni disponibili, ma le principali possono essere elencate sulle dita di una mano. Il corso prende in esame i principali prodotti, mettendone in luce pregi e difetti, e fornisce strumenti di analisi per identificare meglio la corrispondenza degli stessi alle proprie esigenze.

PROGRAMMA CORSO: Introduzione, identificazione del concetto di “Virtualizzazione”, analisi delle principali componenti dei virtualizzatori e dei sistemi operativi virtualizzati. Introduzione a VMware, Proxmox, Hyper-V, oVirt, analisi dei prodotti e delle principali caratteristiche. Comparazione tra alcune delle funzionalità e degli stessi, delle prestazioni e delle procedure. Gestione dello storage (locale, via SAN, georeplicato, distribuito), gestione dei backup, procedure di disaster recovery. La conversione tra i sistemi e compatibilità. Presentazione di alcuni casi di conversione. Cenni su altri Virtualizzatori. Dimostrazioni pratiche. Quesiti dei partecipanti.

QUOTA D’ISCRIZIONE a giornata e a persona (oltre IVA 22 per cento e se IVA esente per le pubbliche amministrazioni ex art. 14, L. n. 537/1993, oltre BOLLO DI EURO 2,00 SULLA FATTURA; dà diritto a partecipare al corso, a ricevere il materiale didattico e al coffee-break delle 11.30 circa): euro 180,00 per pagamenti in contanti o assegni non trasferibili direttamente alla segreteria del corso il giorno stesso; euro 200 se con modalità diverse. SCADENZA ISCRIZIONI: entro il 12.11.2015 e dopo solo nel limite di eventuali posti disponibili. Inviare il modulo d’iscrizione a 3F FORMER srl. fax 0516504570 o pec 3f-former@pec.it o 3f@3f-former.it (modulo scaricabile anche dal sito www.3f-former.it) Fatti salvi i casi derivanti dagli obblighi di fatturazione elettronica, VENGONO CONSEGNATI IL GIORNO DEL CORSO AL PARTECIPANTE L’ATTESTATO DI PARTECIPAZIONE E LA FATTURA. NO CIG perché trattasi di quota di partecipazione e no di appalto.

DOCENTE: Dott. Stefano Marinelli, Esperto e consulente in materia di imprese pubbliche e private, titolare della Dragas IT, azienda specializzata in soluzioni informatiche avanzate e hosting

ISCRIZIONI (impegnativa per l’Ente) ENTRO IL GIORNO 12.11.2015. Specificare il numero degli iscritti e la modalità di pagamento prescelta. Le iscrizioni possono essere effettuate dopo la scadenza nei limiti dei posti disponibili. Le iscrizioni possono essere effettuate anche telefonicamente e perfezionate successivamente entro la scadenza mediante invio modulo di iscrizione (se ritenuto opportuno, potrà essere utilizzato il modulo seguente). Verrà data comunicazione dell’effettivo svolgimento del corso al fax/email indicati nella scheda d’iscrizione, ma l’iscritto è tenuto a informarsi della disponibilità dei posti e dell’effettivo svolgimento del corso (tel. 051731984, 3391307697 3384621905 3738353525). Le rinunce d’iscrizione, dovute a qualsiasi causa, anche di forza maggiore, devono essere effettuate esclusivamente per fax o pec precedute da telefonata, entro la data di scadenza delle iscrizioni e non verranno accettate se perverranno successivamente alla predetta scadenza e la quota dovrà essere comunque versata per intero, senza compensazione o recupero. L’iscritto avrà comunque diritto a ricevere il materiale didattico distribuito. E’ comunque possibile sostituire l’iscritto anche il giorno stesso del corso. Il corso potrà essere annullato o rinviato in qualsiasi momento. Il pagamento se avvenuto verrà restituito, salvo diversi accordi. Ringrazio per l’attenzione e saluto cordialmente.

3F FORMER s.r.l.- Dott.ssa Franca Berti cell. 3391307697

Goodbye dragas, Wilkommen dragas!

Stefano Marinelli — Tue, 17 Jun 2008 19:49:26 GMT

Stanco dei continui riavvii e crash del VPS inglese, ho deciso dis spostare il server.

Ho preso un server dedicato in Germania e ripartirlo in macchine virtuali Xen. Una di esse ospita dragas, le altre le fornirò a eventuali clienti che ne faranno richiesta.

La prima è già stata prenotata da un mio vecchio cliente, prendendo il pacchetto macchina+gestione. Gli ho fatto un prezzo fenomenale ma... voglio premiarli per la fiducia!

Dragas spicca il volo

Stefano Marinelli — Wed, 19 Mar 2008 16:00:35 GMT

Alcuni di voi mi hanno spesso chiesto come facevo a gestire tutta la baracca usando un "semplice" Via Epia. Ho raccontato qualcosina, in passato, relativamente all'architettura che c'e' dietro, in occasione del passaggio da server fisico a macchina OpenVZ. In un'altra occasione ho raccontato di come si potevano migliorare le prestazioni procedendo a fare del caching selvaggio delle istruzioni PHP. Il tutto ha funzionato perfettamente.

Negli ultimi giorni ho dovuto procedere ad una migrazione serale (e rimigrazione mattutina) del server in quanto i nostri due cricetini passano la notte in sala e tollerano poco il rumore del server. Le loro ruotine sono due tamburi rispetto alle ventole dei Via Epia, ma cosi' sono sicuro che non stanno male.

La scusa mi ha dato l'occasione di fare un test. Grazie ad alcune promozioni cumulative, ho preso un VPS esterno presso CheapVPS.

Esso ha:

768 MB di Ram (1536 di burst)
30 GB di disco
due ip fissi
in teoria 600 GB di banda al mese, in pratica ce l'ho illimitata. Connessione "best effort" a 100 MBit condivisi
una macchina a 8 CPU che fa da container (il carico devo ancora capirlo)

Dopo una bella chiacchierata con Rus, che e' tra i fondatori del progetto, ho deciso di provare per un mese e spostarci tutto Dragas, senza ovviamente cancellare le altre macchine su cui si appoggia. Pronto, comunque, a tornare "all'ovile" in qualunque momento, in caso di necessita'. In teoria il balzo in avanti dovrebbe essere notevole, gia' solo per il fatto di averlo online fuori, su IP fisso e sempre connesso.

Tra ieri e oggi ho migrato tutti i file usando rsync. La procedura e' stata semplice poiche' Dragas era gia' all'interno di un VPS OpenVZ, quindi ha trovato un ambiente "amichevole". Ho poi spento la macchina virtuale dell'Epia, ho rimigrato gli ultimi file e acceso il nuovo server.

Primo problema: l'orologio di sistema della macchina di CheapVPS era sballato di quasi 24 ore. Ho aperto un ticket e la loro assistenza aveva risolto il problema gia' 9 minuti dopo. Ottimo.

Secondo problema: non posso accedere al tun/tap. Io uso moltissimo i dispositivi tun/tap, ci gestisco la mia VPN personale e la VPN dei clienti ai quali faccio assistenza. Apro un nuovo ticket e, di nuovo, tutto e' stato sistemato in meno di 10 minuti.

Davvero notevole. Ora Dragas e' su un IP inglese e per ora sembra funzionare egregiamente. Continuo a testare e tenerlo d'occhio, tra qualche giorno faccio un aggiornamento e vediamo come va. Da quello che si legge su Internet, direi che non dovrebbero esserci grossi problemi.

Piccola nota: sul Via Epia, Dragas utilizzava circa 350 MB di ram e 100 di swap. Qui mi avvicino al giga. Secondo me i loro HN (hardware node) sono su macchine a 64 bit e, di rimando, viene usata piu' ram a parita' di processi attivi. Sono, comunque, all'interno dei miei limiti.

Dragas goes OpenVZ!

Stefano Marinelli — Wed, 01 Aug 2007 12:55:14 GMT

Bene... dragas e' sempre stato un server di sperimentazione che, pero', ho anche utilizzato in "produzione". Dal 2002 mi gestisce tutto e, a parte problemi di fornitura ADSL e un guasto, non ci sono state particolari e prolungate interruzioni.

Recentemente ho cominciato anche a tenere regolari backup con rsync ma restava il forte problema della localizzazione geografica: risolta, in parte, rendendolo un VIA EPIA e, quindi, portabile. Restava pero' lo stretto legame geografico/fisico. La Epia, poi, non sembrava essere in grado di reggere il carico in momenti di maggior lavoro (problema in parte risolto) per cui si e' resa necessaria una soluzione veloce, drastica e...il piu' possibile indolore.

Gia' da tempo avevo pensato di virtualizzare il server ma non avevo idea di come fare il tutto avendo un basso impatto prestazionale e la possibilita' di poterlo migrare il piu' facilmente possibile.

Non ricordo come ma ho buttato l'occhio sul progetto OpenVZ . Esso e' la base del sistema di virtualizzazione chiamato Virtuozzo, in produzione gia' da anni e, quindi, discretamente maturo. I principali vantaggi di OpenVZ rispetto ad altri sistemi di virtualizzazione sono:

non emulare (tipo Qemu o VMWare) l'hardware
non virtualizzare il ferro, permettendo di mantenere un unico kernel (Xen, invece, ha bisogno di un kernel per ogni VM)
bassissimo overhead, gli ambienti sono separati ma non c'e' alcun tipo di emulazione
migrazione remota senza aver bisogno di storage condiviso, usando rsync.
migrazione online, anche se ancora non utilizzabile perche' non vengono migrate al volo le periferiche tun/tap

Il server riesce a passare tra computer remoti in pochi minuti e quasi senza downtime (che tendera' a zero appena implementeranno la migrazione live delle periferiche virtuali tun/tap). Dragas si mette, poi, in VPN con uno dei router a mia disposizione (e connessi via ip pubblico) rendendo del tutto trasparente la migrazione.

I risultati? Ottimi, sotto tutti gli aspetti. Il sistema funziona bene, i limiti sono stati tarati per l'uso della macchina, e' semplice fare dei backup e non vedo alcun impatto sulle prestazioni.

Benvenuti nell'era della virtualizzazione, dunque! :-)