Em agosto de 2013, Jérôme Petazzoni criou o Docker no Docker, dindpara abreviar, isso permitiu a criação de contêineres do Docker dentro do Docker Containers; essa funcionalidade se mostrou muito popular, resultando no GitHub Repository da Jérôme recebendo mais de mil estrelas e trezentos garfos.

A partir do Docker 1.8, lançado dois anos depois em agosto de 2015, o Docker no Docker é diretamente suportado pelo Docker imediatamente. No entanto, o uso do Docker no Docker vem com um aviso, aparentemente relacionado à publicação de Jérôme: Usando o Docker no Docker para o seu IC ou ambiente de teste? Pense duas vezes. que se concentra nos motivos pelos quais o Docker no Docker não é uma ótima opção para integração contínua.

Por que é considerado ruim usar o Docker no Docker? É simplesmente um caso para evitar tartarugas até o fim? ou considerações de desempenho?

Preocupações de integração contínua

Em resumo: o Docker no Docker (dind) não lida bem com a simultaneidade.

O motivo pelo qual você não deve usar dind para CI é porque o Docker foi projetado para ter acesso exclusivo ao diretório que ele usa para armazenamento (normalmente /var/lib/docker). Dind não respeita isso, pois todos os processos filhos usam esse diretório simultaneamente. Toda vez que você reconstrói (do CI, por exemplo), qualquer coisa relacionada ao seu aplicativo neste diretório pode ser apagada e forçada a começar do zero. Como seus usuários gostariam se inserissem seus detalhes de pagamento, clicassem em "Comprar" e de repente voltassem à tela de login como se nunca tivessem feito algo? Isso não é bom UX. Duas reconstruções ocorrem ao mesmo tempo? Isso realmente vai acabar mal para todos os envolvidos (incluindo a integridade dos dados).

Outras preocupações

No link publicado pelo OP, surgem preocupações de segurança, pois o sistema tentará aplicar políticas de segurança de maneira muito "semelhante ao CSS", em que um contêiner inferior poderia ter acesso aos recursos de um contêiner externo, a menos que explicitamente proibido. Lembra quando você pode acessar os recursos do servidor da Web fazendo algo como "mywebsite.com/../another_folder/private_resource.txt"? Além disso, às vezes os sistemas de arquivos simplesmente não funcionam bem quando estão aninhados dessa maneira.

O conserto

Felizmente, a postagem do blog no OP tem uma boa solução para o problema. A menos que suas necessidades não sejam atendidas por "criar / executar / enviar contêineres do Docker a partir do seu próprio sistema de CI executando no Docker", você pode usar o -vmodo (adicionar um volume de dados ao seu contêiner) no soquete do Docker (geralmente /var/run/docker.sock:/var/run/docker.sock) para permitir o tipo de acesso necessário ao volume de dados "compartilhado". Esses contêineres serão iniciados ao lado do pai, em vez de embaixo, forçando E / S síncronas. Agora você tem a mesma coisa (quase) que o dind, mas sem as desvantagens que acompanham o Docker não sendo construídas para simultaneidade.

Referência (do OP): usando o Docker-in-Docker para seu IC ou ambiente de teste? Pense duas vezes.