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?
Alla domanda non esiste una risposta semplice. Dipende dalle risorse a disposizione, da come uno è abituato a gestire e, nel complesso, da quanto tempo si avrà poi per fare la manutenzione del tutto. Più semplice (e più rischioso) fare manutenzione o aggiornamenti ad un singolo server piuttosto che ad uno stuolo di macchine più piccole.
La mia filosofia, per quanto possibile, è sempre stata similare al concetto principale dei sistemi Unix: K.I.S.S. (ovvero Keep It Simple and Stupid), separazione massima per ottimizzare la resa e frammentare eventuali criticità future. Già nei primi anni 2000 utilizzavo OpenVZ e, successivamente, lxc anche su piccoli server Atom domestici per tenere tutto separato. Un container come file server, un altro come mail server, un altro come media server, un altro come backup server, ecc. Il vantaggio è sempre stato quello di separare il più possibile i servizi e ridurre le possibilità di guai in caso di aggiornamenti fasulli o, peggio, compromissione di una delle macchine.
Ho per questo osservato con interesse (e ne ho già scritto in passato) l'avvento di Docker, anche se inizialmente non ho avuto un grosso impatto emotivo. Non mi piaceva o, per lo meno, lo reputavo estremamente immaturo. Tutto è corso e il risultato è che oggi, finalmente, riesco ad avere la separazione che ho tanto sognato. Non più una macchina virtuale per servizio, ma un contenitore per servizio, con tutte le sue dipendenze all'interno. Un overhead inferiore, un risultato equivalente.
Questo approccio, apparentemente complesso, rende in realtà semplicissima la gestione successiva delle risorse. Non dovendomi preoccupare di non incrociare dipendenze, librerie, distribuzioni, servizi, ecc., sarà semplicemente necessario sapere quali sono le richieste di un contenitore ed, eventualmente, collegarlo ad un altro. Stop, il risultato è presto detto: servizio attivo, isolato, aggiornabile, sicuro. E, non da sottovalutare, migrabile da un server all'altro senza particolari problemi.
Mi è recentemente capitato di dover installare un sito che necessitasse di mysql 5.7 su un server con mysql 5.5. Aggiornare il secondo non l'ho neanche preso in considerazione (preferisco restare fedele ai repository ufficiali della distribuzione), far andare il primo su una versione più vecchia sarebbe stato un hack sporco e inaffidabile. Risultato: ho tirato su un bel container con mysql 5.7 e fatto puntare ad esso il CMS. Ho inoltre potuto installare un bel PhpMyAdmin solo per esso e il tutto è stabile e aggiornabile.
Uno dei vantaggi, inoltre, del setup docker-style è quello di non dover perdere più troppo tempo con la macchina da installare. Il sistema operativo del server che farà girare Docker, infatti, servirà ad interfacciarsi con l'hardware (fisico o virtuale) e a gestire gli eventuali backup. Il risultato è presto detto: semplicità di gestione in quanto il centro del tutto non è più il server, fisico o virtuale, ma il singolo servizio.
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à.
Pur essendosi evoluto in maniera esponenziale negli ultimi anni, Proxmox mantiene la stessa architettura delle origini. A oggi il sistema è strutturato in maniera molto semplice e allo stesso tempo logica. Si basa, infatti, sulla distribuzione Debian standard (wheezy per 3.x, jessie per 4.x, stretch per 5.x) su cui vengono installati i relativi pacchetti provenienti da uno dei repository di Proxmox stesso.
L'installazione può avvenire in due modi:
Direttamente dalla ISO di Proxmox stesso, fornita di un comodo, semplice e idiot proof installer grafico, che in pochissimi minuti vi fornirà un sistema completo e configurato.
Aggiungendo il repository di Proxmox ad una installazione Debian preesistente (es: installazione su Debian 9.0 Jessie, procedura utilissima nel caso si voglia procedere ad effettuare delle configurazioni non standard o non supportate dalla ISO ufficiale. Con l'installazione del metapacchetto, tutte le dipendenze verranno inserite e, dopo un reboot, si avrà un sistema con le stesse funzionalità di quello installato attraverso la ISO ufficiale.
In entrambi i casi, si discosteranno da Debian standard alcune cose come il kernel (che, normalmente, è in versione più recente e ottimizzata) e pochi altri pacchetti.
Personalmente non ho avuto alcun problema, anche nelle configurazioni più strane, ad installare Proxmox su Debian altamente personalizzata. Ho avuto più noie, invece, ad installare tramite la ISO ufficiale su alcuni hardware parzialmente supportati o obsoleti.
Una delle feature più interessanti di Proxmox è l'attivazione del KSM, ovvero il Kernel Samepage Merging. Capita spesso, infatti, di avere in esecuzione più VM con la stessa versione di sistema operativo, applicativi, ecc. Ebbene, KSM è in grado di fare una scansione di memoria, rilevare queste uguaglianze e deduplicare la memoria. Il risparmio di RAM è consistente e, spesso, può consentire un miglior utilizzo delle risorse della macchina. Di contro, KSM si attiva solo quando la RAM comincia ad avere un utilizzo importante (computazionalmente non è economicissimo) ed è comunque da considerarsi, a mio avviso, qualcosa di "emergenza". Si pensi ad un aggiornamento di una delle macchine virtuali: tutti i software che si aggiornano saranno diversi dagli altri e il KSM non si applicherà ad essi, andando ad aumentare di colpo e drasticamente le risorse richieste rispetto all'equilibrio precedente.
Dopo essersi installato in maniera semplice, sarà semplice anche metterlo in funziona. Al primo avvio ci si troverà di fronte ad una schermata di login con scritto l'indirizzo IP della macchina e l'url di accesso all'interfaccia web. Infatti Proxmox si gestisce quasi integralmente da una comoda interfaccia web, che si è evoluta nel corso della versione 4.x, e consente di fare tutte le operazioni di gestione e buona parte delle operazioni di configurazione e messa in funzione.
Sarà dunque necessario accedere alla stessa per iniziare ad esplorare tutto ciò che questo ottimo sistema ci mette a disposizione.
Come detto già in precedenza, Proxmox mette insieme strumenti preesistenti Open Source e crea una comodissima interfaccia di gestione e monitorizzazione. Nello specifico, ci fornisce due strade principali:
L'opzione container: era OpenVZ fino alla 4.0, ora invece rimpiazzato da lxc. Il tipo di isolamento fornito da lxc è la base anche di Docker, di cui ho già brevemente parlato, ed è adatta a soluzioni che non richiedono l'installazione di un diverso sistema operativo (alias: lxc permette di usare Linux su Linux)
L'opzione virtualizzatore, la cui scelta è ovviamente caduta su KVM, principe dei virtualizzatori su GNU/Linux e con ampio supporto di sistemi operativi Guest e relativi driver virtualizzati Virtio.
OpenVZ era un bel progetto ma, oggi, meno interessante di qualche anno fa. Ne ho fatto largo uso circa 10 anni fa, ma poi l'obsolescenza del kernel in uso e varie altre ragioni mi spinsero verso altri lidi. lxc, invece, l'ho utilizzato con successo fino al 2015 in alcune realtà. Non ho smesso per motivi specifici, semplicemente non mi è più servito e ho optato sempre di più per virtualizzazione completa o, più recentemente, container (Docker) puri.
Tutta la gestione delle VM (o dei container lxc) avviene via web. Sarà dunque possibile creare macchine, lanciarle, agganciare e sganciare dispositivi e lettori virtuali, modificarne le risorse, gestire lo storage, aprire delle console virtuali sia dentro la schermata principali che in un tab separato, ecc.
Proxmox supporta in maniera nativa la possibilità di creare dei cluster. Per cluster si intende una serie di server fisici che verranno raggruppati, all'interno dell'interfaccia web, in un "Datacenter" e che possono interagire tra di loro. Si potrà, ad esempio, creare uno storage condiviso (NFS, Gluster, Ceph, ecc.) per migrare a caldo le singole VM da un server fisico all'altro, creare una infrastruttura in Alta Affidabilità (HA) con rilancio automatico delle VM in caso di guasto o down di uno dei nodi fisici.
Si potrà inoltre, da interfaccia, gestire la creazione di uno storage replicato e ridondato Ceph (di cui faccio larghissimo uso in molte delle infrastrutture che gestisco, anche inter-datacenter), controllarne lo stato, aggiungere e rimuovere dischi, ecc.
Un cluster Proxmox andrebbe gestito sempre con numeri di macchine dispari (numero minimo: 3) per assicurare una consistenza ed evitare lo split brain, ovvero che si creino due cluster paralleli e indipendenti che si ignorano.
Una delle operazioni possibili per garantire continuità in caso di blocco della VM è l'attivazione di un watchdog. Descrizione dell'operazione in questo articolo (in inglese).
Poche soluzioni di virtualizzazione integrate offrono un sistema di backup interno. Proxmox, invece, ha un sistema completo e affidabile già pronto all'uso.
Selezionando quali VM salvare, la frequenza, quanti backup tenere e lo storage di riferimento, sarà possibile configurare un sistema automatico di salvataggio a orari prestabiliti e ricevere una e-mail in caso di problemi (oppure, a scelta, sempre).
Il vantaggio di questa soluzione è la totale integrazione con Proxmox stesso. Ripristinare da un backup sarà un gioco da ragazzi, questione di due click (scegliendo se si vuole sovrascrivere la macchina attualmente in produzione o crearne una nuova, parallela). L'unico svantaggio, non da poco, è che tutti i backup sono sempre completi. Sarà dunque necessaria una importante quantità di spazio (e di tempo) per i salvataggi, oppure l'implementazione di sistemi diversi, tra cui l'ottimo Urbackup (di cui non ho ancora parlato).
Utilizziamo Proxmox in produzione da anni, in setup diversificati (da semplici setup un server locale/molte VM a cluster di server ridondati georeplicati su file system condivisi come Gluster o Ceph, in HA), e non siamo mai rimasti delusi. Se ben implementato e configurato, è in grado di fornire ottime prestazioni, una stabilità invidiabile, un giusto utilizzo di risorse e una perfetta gestibilità sia per l'Amministratore con esperienza, sia per l'utente medio che dovrà appunto occuparsi solo delle funzioni base.
Abbiamo oltre 50 nodi fisici proxmox e centinaia di macchine virtuali. Non abbiamo mai avuto un down, un crash o un problema derivato da esso e le funzioni di snapshot, backup integrato, clonazione a caldo di vm (es: per testare un aggiornamento senza toccare la macchina di produzione), ecc. hanno aiutato nella gestione di un parco macchine abbastanza importante come quello che gestiamo quotidianamente.
Usiamo Proxmox, gli storage ridondati e i sistemi di HA per gestire le infrastrutture di alcune tra le più importanti web agency presenti nel nostro Paese e i clienti sono sempre rimasti soddisfatti dei risultati.
Nel complesso, dopo aver provato varie soluzioni diverse in passato e testato varie soluzioni in evoluzioni del presente, Proxmox è ad oggi probabilmente ciò che coniuga meglio la stabilità, la semplicità di utilizzo e di aggiornamento e la versatilità.
Poco meno di due anni fa ho raccontato di come mi sia trovato con la Nuova Panda a Metano e riportato la mia (ottima) esperienza in merito. Percorrendo molti km ogni anno, c'era però necessità di una vettura più "concreta", sia come spazio che come comfort.
La scelta è dunque caduta sulla vettura che aveva mio padre, ovvero una Alfa Romeo Giulietta. La vettura è stata immatricolata nel Dicembre del 2010 (dunque aveva circa sei anni a Marzo, quando l'ho presa in carico) ma aveva solo 30.000 km.
Ecco le caratteristiche:
Modello:
Alfa Romeo Giulietta 1.4 Distinctive
Colore:
Nero
Motorizzazione:
1.4 MultiAir Turbo 170 Cavalli (Benzina)
Km quando l'ho presa:
30.000 circa
Km al momento della stesura di questo articolo:
50.500 esatti
Optional:
vari, tra cui cruise control, interno in pelle, ecc.
La vettura era in ottimo stato, condizioni pari al nuovo. E' dotata di sensori posteriori (non originali) che funzionano decisamente male per cui sono praticamente inutili. Per il resto, nulla da segnalare.
La prima volta che l'ho guidata sono rimasto decisamente senza parole. La Giulietta, sin dal suo debutto, mi è sempre esteticamente piaciuta ma l'ho sempre considerata poco in quanto ho sempre avuto un certo pregiudizio (a causa delle esperienze precedenti) sulle vetture nostrane. Ne parlerò, prima o poi, in un articolo.
La posizione di guida mi ha subito colpito, così come il sedile. Comodo, avvolgente, decisamente ben fatto. Appena acceso il motore, poi, ho subito apprezzato la sonorità e la silenziosità del benzina. Siamo ormai abituati ai trattoretti Diesel (o ai camion, come chiamo io i Diesel di cilindrata maggiore) e sentire la rotondità e il silenzio del motore a benzina è quasi una sorpresa.
La prima guida è stata interessante: ho apprezzato immediatamente lo sterzo, molto preciso e diretto (ma con pessimo diametro di sterzata) e il telaio. Metterla in difficoltà, pur essendo una vettura a trazione anteriore, è abbastanza difficile (in condizioni di guida in strada), i freni sono pronti ed efficaci. Frizione leggera, cambio preciso.
Ho però notato un fastidioso turbo-lag, simile a quello che avevo notato sulla Panda ma con una differenza: appena il turbo partiva, la vettura sembrava perdere un minimo prima di andare. Dopo una breve ricerca in Rete, ho considerato la cosa come normale e mi sono abituato alla cosa.
Ho provveduto a cambiare batteria e gomme (ancora originali ma sfaldate, come spesso accade sulle gomme moderne dopo qualche anno) e ho iniziato a macinare chilometri.
La prima sorpresa (positiva) è stata nei consumi: su strade extraurbane, senza spingere molto, sono riuscito a stare sui 16/17 km/litro mentre in autostrada sui 13/14 km/l, in base all'andatura. Per una vettura a benzina con quei cavalli, un dato decisamente interessante. Non ho valutato, inizialmente, i consumi in città in quanto ne faccio raramente o comunque in scarse percentuali.
Dopo circa 1000 km, però, ho riscontrato un problema: in accelerazione la vettura strappava, sembrava una specie di sfiato della turbina. Ho dunque optato per una visita in officina e il meccanico ha sostituito le candele (che andrebbero cambiate ogni 30.000 km, ma non costano molto) e un tubetto di sfiato della turbina che s'era rotto. Oltre a ciò, ha provveduto ad effettuare un aggiornamento alle centraline dell'auto e me l'ha riconsegnata.
Vettura trasformata: turbo-lag ridotto enormemente e anche la spinta ne ha beneficiato in maniera esponenziale. Probabilmente il tubino dava già noie e comprometteva le prestazioni. Ah, per chi sta già pensando "ecco, solita auto italiana che si perde nei dettagli": nel 2004 la mia Audi A4 con 40.000 km (e due anni e mezzo di vita) iniziò a ridurre drasticamente la frenata in autostrada. In Audi volevano cambiarmi tutti i dischi, il mio meccanico di fiducia, invece, cambiò solo un tubo di sfiato del servofreno con 10 euro. La vettura andò perfettamente.
I consumi a benzina sono buoni ma mal si sposano con le mie percorrenze. Dopo una ricerca accurata, dunque, ho pensato di trasformare la vettura a GPL. Mi sono consultato con alcuni installatori di fiducia e ho fatto montare un impianto della BRC, con polmone sovradimensionato visto il rapporto cilindrata/cavalli. Ho effettuato circa 12.000 km a GPL e non ho riscontrato alcun problema. La differenza di prestazioni è impercettibile e, a parte un leggero strattone quando varia da benzina a GPL, la vettura si comporta egregiamente. La bombola è stata installata al posto della ruota di scorta (che comunque entra bene, nella sua sacca, nel bagagliaio) e il pianale s'è leggermente alzato, non in maniera scomoda. L'autonomia varia dai 450 km (in autostrada, a 130, con climatizzatore acceso) a 570/580 km su strade extraurbane. Decisamente buona, considerata la potenza del motore.
Assetto: tenuta di strada degna di nota, comportamento stradale eccelso.
Motore: un pelo vuoto sotto i 2000 giri (prima che entri in gioco la turbina), poderoso e pieno poi
Consumi: ottimi, per un benzina. A GPL poi...
DIFETTI:
Qualità percepita: non eccelsa, si sente qualche scricchiolio in giro. Gli assemblaggi sembrano buoni, ma sulla qualità delle plastiche interne avrei qualcosa da ridire.
Visibilità: ormai su vetture così i sensori sono d'obbligo.
Diametro di sterzata: scarso, decisamente scarso. La BMW Serie 1 (grazie alla trazione posteriore) era decisamente più gestibile, così come qualsiasi Mercedes, anche di quasi 5 metri.
La Giulietta è una vettura che mi sta davvero dando delle grandi soddisfazioni. A oggi la consiglierei senza riserve a chi è cosciente di star acquistando una vettura dalle ottime doti stradali, un motore eccelso ed esteticamente molto valida, pur essendo un progetto ormai datato. A chi invece è alla ricerca solo di un marchio tedesco "perché va di moda", senza soffermarsi sulla qualità stradale del singolo progetto, probabilmente la Giulietta non piacerà poi tanto. Ma ognuno è libero di scegliere ciò che vuole.
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.
...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!
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.
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.
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.
SSH è sempre stata una pura delizia per i sistemisti. Facile da configurare, di scarso impatto sulle prestazioni, estremamente versatile, sufficientemente sicuro, è la chiave di volta per l'accesso e la gestione di server Unix-Like.
Mettendosi in condizioni di non farsi bucare facilmente (password banali, meglio una bella autenticazione a chiave pubblica), la mia filosofia è sempre datemi una shell ssh e vi farò qualsiasi cosa.
In varie occasioni, però, sbucano delle problematiche, specialmente nel mondo odierno:
In caso di alta latenza, diventa davvero difficile gestire la situazione vedendo ciò che si digita solo dopo qualche secondo
In caso di cambio di connettività (es: failover tra due differenti canali o passaggio da wifi a rete mobile), la sessione si interrompe
L'utilizzo del TCP, di ssh, può non essere sempre la scelta più adatta.
Mosh, un'ottima alternativa
Mosh si prefigge l'obiettivo di gestire e risolvere alcune tra queste problematiche e in maniera trasparente al normale utente.
Si pone infatti come applicazione di terminale remoto che supporta, in maniera efficace, connessione intermittente e mostra una copia locale di ciò che viene digitato. In caso di latenza della connessione, dunque, noi vedremo in tempo reale ciò che viene digitato anche se questo non è ancora stato recepito dal server di destinazione.
Vantaggi
Il vantaggio principale è che una sessione, una volta aperta, sarà snella (grazie al buffer locale) e costante (grazie all'utilizzo di UDP). Sarà dunque possibile, come sto facendo io in questo momento, scrivere del testo su un server remoto da una connessione con alta latenza e parzialmente intermittente senza minimamente avere alcun disagio, mentre con ssh ci sarebbe un palpabile disagio a causa delle situazioni che ho elencato.
Uno dei casi in cui Mosh mi ha soddisfatto di più è stato quello in cui si ha una connessione che viene chiusa, dal router o dal gestore, dopo qualche minuto di inattività. Ok, il problema è parzialmente aggirabile tenendo aperta, sul terminale remoto, una sessione di screen o tmux, ma non sempre ciò è fattibile o pratico. Inoltre, in certi casi, si ha un cambiamento di indirizzo IP e in quel caso non c'è nulla che si possa fare.
Mosh è inoltre parte di alcune applicazioni di terze parti (come Juicessh per Android) ed è ormai ben collaudato e testato.
Svantaggi
Non è tutt'oro ciò che luccica. Mosh ha degli svantaggi e non banali.
Uno di essi è la mancanza del port forwarding nativo. D'altronde non nasce per fare da tunnel di connessioni ma per essere un ottimo sistema di terminale remoto.
Un altro svantaggio è l'impossibilità di fare da tunnel per server X. Oggettivamente, nel mio caso, questo non è un gran problema (ho sempre usato poco questo tipo di soluzioni), ma per alcuni può esserlo.
Mosh necessita, inoltre, del suo server in esecuzione (non si appoggia solo a ssh) e, di default, utilizza una porta nel range 60000-61000, per cui almeno alcune di esse andrebbero aperte sul server (una porta per sessione).
Nel complesso, consiglio Mosh? Assolutamente si, prendendo però atto del fatto che non potremo, almeno in tutti i casi, fare a meno dell'ottimo e completo ssh.
