Va bene eseguire la finestra mobile dall'interno della finestra mobile?


185

Sto facendo funzionare Jenkins in un container Docker. Mi chiedo se per il contenitore Jenkins sia ok essere anche un host Docker? Quello a cui sto pensando è di avviare un nuovo contenitore docker per ogni test di integrazione creato da Jenkins (per avviare database, broker di messaggi, ecc.). I contenitori dovrebbero quindi essere chiusi dopo il completamento dei test di integrazione. C'è un motivo per evitare di eseguire i contenitori della finestra mobile all'interno di un altro contenitore finestra mobile in questo modo?


11
Un'altra possibilità è montare il socket docker dall'host come volume nel contenitore. Ciò consente di creare contenitori "fratelli" e ha il vantaggio di poter riutilizzare la cache.
Adrian Mouat,

4
Ho scoperto che quando si utilizza il socket docker dall'host che nei casi in cui si desidera montare volumi esterni è necessario impostare il percorso del volume relativo all'host in quanto è in esecuzione il daemon docker. L'impostazione relativa al contenitore che avvia i contenitori non funzionerà necessariamente a meno che i percorsi non coincidano.
Jakob Runge

Risposte:


224

Eseguire Docker all'interno di Docker (aka dind ), per quanto possibile, dovrebbe essere evitato, se possibile. (Fonte fornito di seguito.) Invece, si vuole impostare un modo per il vostro contenitore principale di produrre e comunicare con fratelli contenitori.

Jérôme Petazzoni - l'autore della funzione che ha permesso a Docker di funzionare all'interno di un container Docker - ha effettivamente scritto un post sul blog dicendo di non farlo . Il caso d'uso che descrive corrisponde al caso d'uso esatto dell'OP di un contenitore Docker CI che deve eseguire lavori all'interno di altri contenitori Docker.

Petazzoni elenca due motivi per cui Dind è problematico:

  1. Non collabora bene con Linux Security Modules (LSM).
  2. Crea una discrepanza nei file system che crea problemi per i contenitori creati all'interno dei contenitori padre.

Da quel post sul blog, descrive la seguente alternativa,

[Il] modo più semplice è semplicemente esporre lo zoccolo Docker al tuo contenitore CI, montandolo con il -vflag.

In poche parole, quando avvii il tuo contenitore CI (Jenkins o altro), invece di hackerare qualcosa insieme a Docker-in-Docker, avviarlo con:

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

Ora questo contenitore avrà accesso al socket Docker e sarà quindi in grado di avviare i contenitori. Tranne il fatto che invece di avviare contenitori "figli", verranno avviati contenitori "fratelli".


1
Come eseguire i comandi docker senza sudofarlo in questo modo? Grazie
c4k,

3
È necessario aggiungere l'utente al dockergruppo: sudo usermod -aG docker $USER. Dopo dovrai riconnetterti.
predmijat,

2
Come accedere nuovamente da un cointainer?
thiagowfx,

1
@AlexanderMills È lo stesso perché la presa della finestra mobile si trova anche /var/run/docker.sockquando si esegue la finestra mobile per mac sulla macchina macos.
Bruce Sun,

1
che dire di windows? non ho/var/run/docker.sock
Abdelhafid l'

54

Ho già risposto a una domanda simile su come eseguire un contenitore Docker all'interno di Docker .

Eseguire la finestra mobile all'interno della finestra mobile è sicuramente possibile. La cosa principale è che tu sia runil container esterno con privilegi extra (a partire da --privileged=true) e quindi installa la finestra mobile in quel container.

Controlla questo post per ulteriori informazioni: Docker-in-Docker .

Un possibile caso d'uso per questo è descritto in questa voce . Il blog descrive come costruire container docker all'interno di un container docker Jenkins.

Tuttavia, Docker all'interno di Docker non è l'approccio consigliato per risolvere questo tipo di problemi. Invece, l'approccio raccomandato è quello di creare contenitori "fratelli" come descritto in questo post

Pertanto, eseguire Docker all'interno di Docker è stato da molti considerato un buon tipo di soluzione per questo tipo di problemi. Ora, la tendenza è quella di utilizzare invece contenitori "fratelli". Vedi la risposta di @predmijat in questa pagina per maggiori informazioni.


Vedere il commento qui sotto sull'evitare la finestra mobile nella finestra mobile.
Dan Poltawski,

6

Va bene eseguire Docker-in-Docker (DinD) e infatti Docker (la società) ha un'immagine DinD ufficiale per questo.

L'avvertenza tuttavia è che richiede un contenitore privilegiato, che a seconda delle esigenze di sicurezza potrebbe non essere un'alternativa praticabile.

La soluzione alternativa di eseguire Docker utilizzando container di pari livello (aka Docker-out-of-Docker o DooD) non richiede un container privilegiato, ma presenta alcuni svantaggi derivanti dal fatto che si sta avviando il container da un contesto che è diverso da quello in cui è in esecuzione (ovvero, si avvia il contenitore all'interno di un contenitore, ma è in esecuzione a livello dell'host, non all'interno del contenitore).

Ho scritto un blog descrivendo i pro / contro di DinD vs DooD qui .

Detto questo, Nestybox (una startup che ho appena fondato) sta lavorando a una soluzione che esegue il vero Docker-in-Docker in modo sicuro (senza utilizzare contenitori privilegiati). Puoi verificarlo su www.nestybox.com .


0

Sì, possiamo eseguire la finestra mobile nella finestra mobile, avremo bisogno di collegare il sockeet unix "/var/run/docker.sock" su cui il daemon docker ascolta di default come volume sulla finestra mobile principale usando "-v / var / run /docker.sock:/var/run/docker.sock". A volte, possono sorgere problemi di autorizzazioni per il socket daemon docker per il quale è possibile scrivere "sudo chmod 757 /var/run/docker.sock".

E inoltre richiederebbe di eseguire la finestra mobile in modalità privilegiata, quindi i comandi sarebbero:

sudo chmod 757 /var/run/docker.sock

docker run --privileged = true -v /var/run/docker.sock:/var/run/docker.sock -it ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.