Esecuzione di più applicazioni in un contenitore finestra mobile

Question

Questa domanda è parte della mia continua esplorazione di Docker e in qualche modo segue uno dei miei earlier questions. Ora ho capito come si possa ottenere uno stack completo di applicazioni (in pratica un mini VPS) lavorando collegando tra loro una serie di container Docker. Ad esempio, è possibile creare uno stack che fornisce Apache + PHP5 con un fascio di estensioni + Redis + MemCached + MySQL tutti in esecuzione su Ubuntu con o senza un contenitore dati aggiuntivo per semplificare la serializzazione dei dati utente.

Tutto molto bello ed elegante. Tuttavia, non posso fare a meno di chiedermi ... 5 contenitori per eseguire quel piccolo VPS (ne conto 5 non 6 poiché Apache + PHP5 va in un contenitore). Quindi supponiamo di avere 100 VPS di questo tipo in esecuzione? Ciò significa che ho 500 contenitori in esecuzione! Capisco gli argomenti qui - è facile comporre nuovi stack di app, aggiornare un componente dello stack ecc. Ma non ci sono inutili spese generali per operare in questo modo?

Supponiamo che ho fatto questo

• Mettere tutte le mie applicazioni all'interno di un contenitore

• Scrivi un piccolo script di shell

  !/Bin/bash servizio memcached iniziare Redis-server del servizio di avvio .... servizio apache2 start mentre: do : terminato

Nel mio Dockerfile devo

ADD start.sh /usr/local/bin/start.sh 
RUN chmod +x /usr/local/bin/start.sh 

.... 
ENTRYPOINT ["/bin/bash"] 
CMD ["/usr/local/bin/start.sh"] 

Allora ottengo quel contenitore fino & esecuzione

docker run -d -p 8080:80 -v /var/droidos/site:/var/www/html -v /var/droidos/logs:/var/log/apache2 droidos/minivps 

e io sono nel mondo degli affari. Ora, quando voglio chiudere il contenitore a livello di codice, posso farlo eseguendo un singolo comando di finestra mobile.

Ci sono molte domande di natura simile da trovare quando un Google è per loro. Oltre agli argomenti che ho riprodotto sopra, uno dei motivi più comuni indicati per l'approccio one-app-per-container è "questo è il modo in cui Docker è progettato per funzionare". Cosa mi piacerebbe sapere

• Quali sono gli svantaggi di eseguire istanze x100 di N contenitori collegati - compromessi a titolo di velocità, utilizzo della memoria ecc sull'host?
• Cosa c'è di sbagliato in ciò che ho fatto qui?

Answer 1

Un contenitore è fondamentalmente un processo. Non vi è alcun problema tecnico con l'esecuzione di 500 processi su un sistema Linux di dimensioni decenti, anche se dovranno condividere la (e) CPU (e) e memoria.

Il costo di un contenitore nel corso di un processo è alcune risorse del kernel in più per gestire spazi dei nomi, file system e gruppi di controllo, e alcune strutture di gestione all'interno del demone di Docker, in particolare per gestire stdout e stderr.

Gli spazi dei nomi vengono introdotti per fornire l'isolamento, in modo che un contenitore non interferisca con gli altri.Se i gruppi di 5 contenitori formano un'unità che non ha bisogno di questo isolamento, è possibile condividere lo spazio dei nomi di rete utilizzando --net=container. Al momento non ci sono funzionalità per condividere i cgroup, AFAIK.

Cosa c'è di sbagliato con quello che suggeriscono:

• non è "il modo in cui Docker". Quale potrebbe non essere importante per te.
• devi mantenere lo scripting per farlo funzionare, preoccuparti del riavvio del processo, ecc., Invece di usare un orchestratore progettato per l'attività
• dovrai gestire i conflitti nel filesystem, ad es. due processi hanno bisogno di diverse versioni di una biblioteca, o di entrambi scrivono allo stesso file di output
• stdout e stderr saranno mescolati per i cinque processi

Answer 2

@ risposta di Bryan è solido, in particolare in relazione alle spese di un contenitore che esegue solo un processo in corso.

Detto questo, dovresti almeno leggere gli argomenti allo https://phusion.github.io/baseimage-docker/, che costituisce un caso per avere contenitori con più processi. Senza di loro, finestra mobile è luce sul fondo:

• supervisione processo
• cron jobs
• syslog

baseimage-finestra mobile gestisce un processo init che spara un paio di processi oltre a quella principale nel contenitore.

Per alcuni scopi questa è una buona idea, ma è anche importante sapere che ad esempio avere un demone cron e un demone syslog per contenitore aggiunge un po 'più di overhead. Mi aspetto che con la maturazione dell'ecosistema docker vedremo soluzioni migliori che non richiedono questo.