Vai al contenuto

Soluzioni · Container

Quanto server serve a Docker?

I container sono processi che condividono un unico kernel, non piccole macchine virtuali: il daemon occupa circa 100 MB e tutto il resto sono solo i vostri processi. La risposta è quindi più piccola di quanto la domanda faccia pensare: un proxy, un'app, un database e una cache insieme arrivano a circa 515 MB, che stanno comodamente su BD-8 a $12.90.

Cosa occupa davvero un container

Intervalli, non benchmark

La vostra immagine, la configurazione e il traffico incidono su questi valori più di qualsiasi tabella. Eseguite docker stats sul vostro stack: è l'unico numero che vale per voi.

Memoria residente tipica per i carichi di lavoro container più comuni
ContainerMemoria tipicaCi sta su BD-8 (8 GB)
Un reverse proxynginx, Caddy, Traefik15–60 MB129 nella fascia alta
Una piccola web appNode, Python, Go: un solo processo60–200 MB38 nella fascia alta
PostgreSQL o MySQLdataset piccolo, pool predefinito200–500 MB15 nella fascia alta
Rediscome cache, limitato da maxmemory20–200 MB38 nella fascia alta
Un servizio JVMJava, Kotlin, Elasticsearch500–2000 MB3 nella fascia alta

Il calcolo

Cosa contiene ogni piano

La memoria, meno 300 MB per il sistema operativo e 100 MB per il daemon, divisa per quanto occupano i vostri container. La colonna centrale è uno stack completo (proxy, app, database, cache) di circa 515 MB.

Capacità di container e stack per piano, con disco e prezzi in tempo reale
PianoRAMStack completiApp piccoleDiscoPrezzoAttiva
VPS-11 GB1325 GB$9.90Attiva
BD-88 GB1538100 GB$12.90Attiva
BD-1212 GB2359200 GB$17.90Attiva
BD-2424 GB46120300 GB$31.90Attiva

Il disco è la seconda sorpresa, quella che si incontra più tardi: immagini, volumi e log si accumulano silenziosamente. Mettete docker system prune in un cron settimanale prima che diventi urgente, non dopo.

Contro noi stessi

Quando non dovreste acquistarlo

Una piattaforma container gestita costa di più perché si occupa della gestione. È un servizio reale che vale la pena acquistare.

Un VPS vi dà root e vi affida aggiornamenti, riavvii, certificati e reperibilità. È decisamente più economico ed è davvero più lavoro. Se non volete quel lavoro, una piattaforma gestita è la risposta onesta, e preferiamo indicarvela piuttosto che vendere una macchina che finisce abbandonata con un daemon non aggiornato esposto a internet. Due consigli minori nello stesso spirito: impostate un limite di memoria su ogni container, così muore quello che si comporta male e non il database, e non ricorrete a Kubernetes su una sola macchina: un orchestratore senza nulla da pianificare è solo complessità.

Domande

Le domande che si pongono prima dell'acquisto.

Quanta RAM usa Docker stesso?
Molto poca, ed è la parte che sorprende. Il daemon Docker occupa circa 100 MB e ogni container successivo è solo un processo: non c'è un secondo sistema operativo, né un secondo kernel, né un costo fisso per container come con una macchina virtuale. Il calcolo è quindi semplice: la memoria della macchina, meno circa 300 MB per il sistema operativo e 100 MB per il daemon, divisa tra i processi che eseguite davvero.
Quanti container può eseguire un piccolo VPS?
Più di quanto la domanda lasci intendere, perché "un container" non è un'unità di misura. Dieci reverse proxy e un Elasticsearch richiedono macchine completamente diverse. Su BD-8 (8 GB a $12.90) un proxy, una web app, un database e una cache insieme arrivano a circa 515 MB, lasciando libera gran parte della macchina. La tabella sopra fa la divisione; eseguite `docker stats` sul vostro stack per il numero che vale davvero per voi.
Un VPS costa meno di una piattaforma container gestita?
Quasi sempre sul prezzo, ma il confronto non finisce qui. Una piattaforma costa di più perché si occupa della gestione: aggiornamenti, riavvii, certificati, la reperibilità alle 3 di notte. Un VPS vi dà root e vi restituisce tutto questo. Se volete eseguire container e siete disposti a farvi carico di quel lavoro, un VPS è decisamente più economico. Se preferite di no, pagate la piattaforma: preferiamo dirvelo piuttosto che vendervi una macchina che finisce abbandonata con un daemon non aggiornato.
Mi servono Docker Swarm o Kubernetes?
Su una sola macchina, no. Compose basta per uno stack che vive su un unico server, ed è la risposta giusta per la stragrande maggioranza delle configurazioni self-hosted: il compito di un orchestratore è pianificare su più macchine, e con una sola macchina non c'è nulla da pianificare. Ricorrete a Kubernetes quando avete davvero più macchine e un motivo per la complessità, non prima.
Cosa cede per primo: memoria, CPU o disco?
Di solito la memoria, e il problema si manifesta in modo evidente: l'out-of-memory killer del kernel sceglie un processo e lo termina, e sembra che un container si riavvii misteriosamente. Impostate limiti di memoria per container, così muore quello che si comporta male e non il database. Il disco è la seconda sorpresa: immagini, volumi e log si accumulano silenziosamente, quindi `docker system prune` va messo in un cron settimanale ben prima che diventi urgente.
Quale immagine dovrebbe usare l'host?
Una qualsiasi delle nostre: ogni piano esegue ogni immagine e Docker gira su tutte. Ubuntu LTS è la scelta predefinita consigliata se non avete preferenze, semplicemente perché gran parte della documentazione sui container la presuppone. La distribuzione conta molto meno di quanto sembri: i container portano il proprio userland, quindi l'host è poco più di un kernel e un daemon.