Nell'agosto 2013 Jérôme Petazzoni ha creato Docker in Docker, dindin breve, ciò ha permesso di creare container Docker all'interno di Docker Containers, questa funzionalità si è rivelata molto popolare con il risultato che il repository GitHub di Jérôme ha ricevuto oltre mille stelle e trecento forchette.

A partire da Docker 1.8, rilasciato due anni dopo nell'agosto 2015, Docker in Docker è supportato direttamente da Docker immediatamente. Tuttavia, l'uso di Docker in Docker viene fornito con un avviso, apparentemente correlato al post di Jérôme: utilizzare Docker-in-Docker per il tuo CI o l'ambiente di test? Pensa due volte. che si concentra sui motivi per cui Docker in Docker non è un'ottima scelta per l'integrazione continua.

Perché è considerato male usare Docker in Docker? È semplicemente un caso per evitare le tartarughe fino in fondo? o considerazioni sulle prestazioni?

Preoccupazioni per l'integrazione continua

In breve: Docker in Docker (dind) non gestisce bene la concorrenza.

Il motivo per cui non dovresti usare dind per CI è perché Docker è stato progettato per avere accesso esclusivo alla directory che usa per l'archiviazione (normalmente /var/lib/docker). Dind non lo rispetta poiché tutti i processi figlio utilizzano questa directory contemporaneamente. Ogni volta che esegui la ricostruzione (ad esempio da CI), qualsiasi cosa correlata alla tua app in questa directory potrebbe essere cancellata e forzata a partire da zero. Come piacerebbe ai tuoi utenti se inserissero i loro dettagli di pagamento, facessero clic su "Acquista" e si ritrovassero improvvisamente nella schermata di accesso come se non avessero mai fatto nulla? Non è proprio una buona UX. Si verificano due ricostruzioni contemporaneamente? Questo finirà davvero male per tutti i soggetti coinvolti (inclusa l'integrità dei dati).

Altre preoccupazioni

Dal collegamento pubblicato dall'OP, sorgono problemi di sicurezza poiché il sistema proverà ad applicare le politiche di sicurezza in modo molto "simile a CSS" in cui un contenitore inferiore potrebbe avere accesso alle risorse di un contenitore esterno se non esplicitamente vietato. Ricordi quando potresti accedere alle risorse del web server facendo qualcosa del tipo "mywebsite.com/../another_folder/private_resource.txt"? Inoltre, a volte i filesystem non giocano bene l'uno con l'altro quando sono nidificati in questo modo.

La correzione

Per fortuna, il post sul blog nell'OP ha una buona soluzione al problema. A meno che le vostre esigenze non siano soddisfatte da "build / run / push container Docker dal sistema stesso CI in esecuzione su Docker", è possibile utilizzare la -vmodalità (aggiungere un volume di dati al contenitore) sul socket Docker (in genere /var/run/docker.sock:/var/run/docker.sock) per consentire il tipo di l'accesso è necessario al volume di dati "condiviso". Questi contenitori verranno avviati insieme al genitore, anziché al di sotto, forzando l'IO sincrono. Ora hai la stessa cosa (quasi) di dind ma senza i lati negativi che derivano dal fatto che Docker non è stato creato per la concorrenza.

Riferimento (dall'OP): utilizzo di Docker-in-Docker per il CI o l'ambiente di test? Pensa due volte.