Come avviare il contenitore docker come server

Question

Vorrei eseguire un contenitore finestra mobile che ospita una semplice applicazione Web, tuttavia non capisco come progettare/eseguire l'immagine come server. Ad esempio:

docker run -d -p 80:80 ubuntu:14.04 /bin/bash 

Ciò avvierà e interromperà immediatamente il contenitore. Invece possiamo avviarlo in modo interattivo:

docker run -i -p 80:80 ubuntu:14.04 /bin/bash 

Questo funziona, ma ora devo tenere aperta la shell interattiva per ogni contenitore che è in esecuzione? Preferirei solo avviarlo e farlo funzionare in background. Un hack sarebbe utilizzando un comando che non restituisce mai:

docker run -d -p 80:80 {image} tail -F /var/log/kern.log 

Ma ora io non può collegarsi al guscio più, per ispezionare cosa sta succedendo se l'applicazione si comporta in su.

C'è un modo per avviare il contenitore in background (come faremmo per un vm), in un modo che consenta di allegare/scollegare una shell dall'host? O mi manca completamente il punto?

Answer 1

L'argomento finale su docker run è il comando da eseguire all'interno del contenitore. Quando esegui docker run -d -p 80:80 ubuntu:14.04 /bin/bash, stai eseguendo bash nel contenitore e niente di più. In realtà, vuoi eseguire la tua applicazione web in un contenitore e mantenerlo attivo, quindi dovresti farlo docker run -d -p 80:80 ubuntu:14.04 /path/to/yourapp.

Ma l'applicazione probabilmente dipende da alcune configurazioni per l'esecuzione. Se legge la sua configurazione dalle variabili di ambiente, è possibile utilizzare gli argomenti -e key=value con docker run. Se la tua applicazione necessita di un file di configurazione, probabilmente dovresti usare uno Dockerfile per configurare prima la configurazione.

This article fornisce un bell'esempio completo di esecuzione di un'applicazione nodo in un contenitore.

Answer 2

Gli utenti di finestra mobile tendono ad assumere un contenitore per essere una VM completa, mentre il concetto di progettazione di finestra mobile è più focalizzato sulla containerizzazione ottimale piuttosto che imitare la VM all'interno di un contenitore.

Entrambi sono corretti, tuttavia alcuni dettagli di implementazione non sono facili da acquisire all'inizio. Sto cercando di riassumere alcune delle differenze implementative in un modo che è più facile da capire.

1. SSH

SSH sarebbe il modo più straight-forward di andare all'interno di una macchina virtuale Linux (o container), tuttavia molti modelli dockerized non hanno server ssh installato. Credo che questo sia dovuto all'ottimizzazione dei motivi di sicurezza & per il container.

2. finestra mobile allegare

finestra mobile allegare può essere utile se si lavora come out-of-the-box. Tuttavia al momento della scrittura non è stabile - https://github.com/docker/docker/issues/8521. Potrebbe essere associato con l'impostazione SSH, ma non è sicuro quando è completamente risolto.

3. docker pratiche raccomandate (nsenter ed ecc)

Alcune alternative (o le migliori pratiche in un certo senso) raccomandato da Docker al https://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/

Questa pratica separa fondamentalmente estrae elementi mutabili da un contenitore e li mappa in alcuni punti di un host di docker in modo che possano essere manipolati dall'esterno del contenitore e/o mantenuti. Potrebbe essere una buona pratica nell'ambiente di produzione, ma non ora quando più progetti relativi alla docker si trovano in ambiente di sviluppo e di staging.

4. bash riga di comando

"finestra mobile exec -è {contenitore id} bash" nuvola essere molto utile e pratico strumento per entrare in macchina.

5. Alcuni principi fondamentali

   • "run finestra mobile" crea un nuovo contenitore non verranno salvate le modifiche in modo precedenti.
   • "docker start" avvierà un contenitore esistente in modo che le modifiche precedenti rimangano nel contenitore, tuttavia è necessario trovare l'ID contenitore corretto tra molti con lo stesso ID immagine. Bisogno di "docker commit" per sopprimere le versioni se lo si desidera.
   • Ctrl-C interromperà il contenitore all'uscita. Sarà necessario aggiungere "&" alla fine in modo che il contenitore possa eseguire lo sfondo e fornire il prompt quando si preme il tasto Invio.

Answer 3

alla domanda iniziale, è possibile coda qualche file, come lei ha ricordato, per mantenere il processo in esecuzione.

Per raggiungere il guscio, invece di "allegare", si hanno due opzioni:

1. docker exec -it <container_id> /bin/bash

O

2. run demone SSH nel contenitore, la porta mappa ssh e quindi ssh nel contenitore.