Newsgroup: it.comp.os.linux.sys
Titolo: Virtualizzare Docker

Secondo voi, avere alcuni server (5-6) che avranno come unico scopo erogare container tramite Docker (in pratica su tali server installo solo Docker), può avere senso virtualizzare? Ovvero anzichè installare Docker sul server, installo prima un hypervisor qualunque e poi creo X VPS Docker su ciascun server.
 
Il vantaggio di avere Docker virtualizzato c'è: posso migrare una intera VPS docker o migrarla tra più server, ma considerato che i servizi erogati dai container sono già ridondati di loro (ad esempio degli MX o dei server DNS), posso benissimo spegnere l'intero nodo senza arrecare disservizi, pertanto il vantaggio primario della virtualizzazione, in questo caso, non ci sarebbe.
 
Che dite?

 Il vantaggio di avere Docker virtualizzato c'è: posso migrare una intera VPS docker o migrarla tra più server, ma considerato che i servizi erogati dai container sono già ridondati di loro (ad esempio degli MX o dei server DNS), posso benissimo spegnere l'intero nodo senza arrecare disservizi, pertanto il vantaggio primario della virtualizzazione, in questo caso, non ci sarebbe.
 
Un'immagine docker dovrebbe essere effimera, quindi non dipendere da 
quale server o VPS la sta ospitando, e non dovrebbe dipendere da 
filesystem o altre risorse locali.
 
In questo caso, spostare la VPS non ha senso. È molto più economico 
lanciare una nuova immagine dello stesso container su un server diverso 
e ucciderla nel vecchio.
 
Questo implica che i tuoi storage (DB SQL e non, memcached, queues non 
effimere, ecc.) non vanno in docker, ma sui loro server.
 
Se invece i tuoi utenti usano immagini docker come fossero immagini 
virtualbox/vmware, dovresti cambiare gli utenti. :D
 
Bye.
 

 e ucciderla nel vecchio.
 
Vero
 
Mi sono espresso male, malissimo.
 
Intendevo dire: se ho bisogno di fare manutenzione al nodo docker (aggiornamenti di docker o simili) posso far avviare una nuova VPS (anche sullo stesso server) dal mio orchestrator, far migrare gli applicativi che girano sul vecchio Docker nel nuovo docker della nuova VPS e uccidere la vecchia, ormai dismessa.
 
In questo modo non aggiorno mai niente, semplicemente attivo nuove VPS che mi nascono già con software e sistema aggiornato e faccio gestire il tutto all'orchestrator che mi coordina l'esecuzione delle applicazioni.
 
Senza virtualizzare, questa operazione la potrei fare solo attivando interi nuovi server fisici. Non proprio economico, per fare un banale aggiornamento di infrastruttura. Se, ad esempio, hai 30 istanze docker su 3 server (10 per server) e vuoi aggiornarle, devi attivare un quarto server fisico, migrarne 10, aggiornare il server dismesso dal quale hai migrato le 10 istanze, e così via....
 
Virtualizzando, sullo stesso server fisico attivo l'undicesima istanza, dismetto al prima, attivo la dodicesima, dismesso al seconda etc etc. Mi ritrovo con la stessa situazione ma facendo uso di 1 singola VPS extra per tutta l'operazione, finchè non le ho aggiornate tutte.
 

 Intendevo dire: se ho bisogno di fare manutenzione al nodo docker (aggiornamenti di docker o simili) posso far avviare una nuova VPS (anche sullo stesso server) dal mio orchestrator, far migrare gli applicativi che girano sul vecchio Docker nel nuovo docker della nuova VPS e uccidere la vecchia, ormai dismessa.
 
OK, in questo caso ha senso. :)
 
Dipende da come organizzi le VPS.
 
Se sono "omogenee" e non al limite di carico, potresti anche 
semplicement emigrare tutti i docker sulle 2 VPS (o sui 2 server) che 
non stai aggiornando, quindi aggiornare quel server, e riportare 
indietro i docker. Poi in loop aggiorni anche le altre due.
 
Col tuo sistema avresti il vantaggio di avere sia la versione non 
aggiornata che quella aggiornata della VPS, e quindi puoi ri-migrare i 
docker in caso di aggiornamento fallito.
 
Bye.
 

 Che dite?
 
Che a fare si può fare, ma poi diventi pazzo in cristo. Personalmente ho
cominciato a dare un senso a Docker nel momento in cui l'ho usato per macchine
usa e getta (più che altro per fare building di pacchetti rpm di progetti
python tramite fpm)
 
Enrico

 rpm di progetti python tramite fpm)
 
vero, ma credo sia proprio questo lo scopo dei container Docker.
Infatti non dico migrare l'intera VM con docker, ma bensì poter attivare nuove VM con docker aggiornato e far migrare le app che girano al suo interno direttamente al software di gestione. Senza poter compartimentare il nodo in più VM, fare una cosa del genere obbligherebbe attivare nuovi server fisici e procedere con gli upgrade.
 
Altro vantaggio: potrei usare lo stesso nodo fisico per far girare anche le VM del software di gestione, riutilizzando le macchine. Dedicare un intero nodo a docker mi obbligherebbe ad avere hardware separato per le VM di management.
 
Boh, ripensandoci, non mi sembra tanto anomala come idea, virtualizzare docker.

 docker.
 
Come ho detto, si può fare, solo che io personalmente non lo farei :)
 
Enrico

 la VM, mentre una VM difficilmente può girare dentro una VM)
 
Si, ma l'hypervisor che gestisce il tutto non ne sarebbe a conoscenza, pertanto allocherebbe RAM per nuove VM senza sapere che in realtà quella RAM è stata usata da Docker.
 
Due galli nello stesso pollaio non è bello.
 
Ti faccio un esempio: il nodo è gestito da $SoftwareCloudDiManagement ($SC)
$SC sa che quel nodo ha 64GB di ram
$SC crea 2 VM da 8GB, pertanto sa che restano liberi 48GB
$AltroSoftware mi avvia 10 app tramite docker, ciascuna app consuma 2GB, quindi 20GB occupati.
$SC deve creare 2 VM da 16GB perchè un nodo si è guastato e quindi le riattiva su questo rimasto attivo. E' convinto di avere 48GB a disposizione, quindi 2 VM da 16GB ci stanno e resta anche spazio. In realtà i giga sono solo 28GB, non 48, dato che ci sono le 10 app Docker che occupano 20GB complessivi.
 
La botta che farà la potrai sentire fin li. E la botta la farà proprio quando non la deve fare: in caso di emergenza o ridondanza compromessa.

 è stata usata da Docker.
 
Mi aspetto che vengano utilizzati degli strumenti che permettano di gestire la
convivenza. Per intenderci, Proxmox e oVirt permettono di gestire sia macchine
virtuali che container LXC, permettendo quindi di avere un dettaglio delle
risorse globali usate sul sistema. Alzare nuove macchine o nuovi container lo
si farà tenendo conto di quelle risorse
 
Enrico

 si farà tenendo conto di quelle risorse
 
Ok, però, se fosse così come dici te, non avrebbe senso di esistere docker-machine con il supporto a varie IaaS (e le IaaS, per loro natura, generano sempre delle VM)
https://docs.docker.com/machine/drivers/
 
 
nessuno dei provider elencati ti da accesso al bare-metal. Tutto quello che fai, lo fai dentro una tua VPS (digitalocean ad esempio, vende solo VPS)