Como (e por que) executar o Docker dentro do Docker

Executar o Docker dentro do Docker permite construir imagens e iniciar contêineres em um ambiente já contêinerizado. Existem duas abordagens possíveis para conseguir isso, dependendo se você deseja iniciar contêineres filhos ou irmãos.

O acesso ao Docker de dentro de um contêiner do Docker é mais frequentemente desejável no contexto de sistemas CI e CD. É comum hospedar os agentes que executam o pipeline dentro de um contêiner do Docker. Você acabará usando uma estratégia Docker-in-Docker se um dos estágios do pipeline criar uma imagem ou interagir com contêineres.

A imagem Docker-in-Docker

O Docker é fornecido como uma imagem independente por meio da tag docker: dind no Docker Hub. Iniciar esta imagem fornecerá uma instalação funcional do daemon do Docker dentro de seu novo contêiner. Ele operará independentemente do daemon do seu host que está executando o contêiner dind, portanto, o docker ps dentro do contêiner fornecerá resultados diferentes para o docker ps no seu host.

 docker run -d --privileged --name docker \ -e DOCKER_TLS_CERTDIR = / certs \ -v docker-certs-ca: / certs / ca \ -v docker-certs-client: / certs / client \ docker: dind 

Usar o Docker-in-Docker dessa maneira traz uma grande ressalva: você precisa usar o modo privilegiado. Essa restrição se aplica mesmo se você estiver usando contêineres sem raiz. O modo privilegiado é ativado pelo sinalizador --privileged no comando mostrado acima.

Usar o modo privilegiado dá ao contêiner acesso completo ao seu sistema host. Isso é necessário em um cenário Docker-in-Docker para que seu Docker interno seja capaz de criar novos contêineres. No entanto, pode ser um risco de segurança inaceitável em alguns ambientes.

Publicidade

Existem outros problemas com o dind também. Certos sistemas podem ter conflitos com os Módulos de Segurança do Linux (LSM), como AppArmor e SELinux. Isso ocorre quando o Docker interno aplica políticas LSM que o daemon externo não consegue prever.

Outro desafio diz respeito aos sistemas de arquivos de contêiner. O daemon externo será executado no sistema de arquivos regular do seu host, como o ext4. Todos os seus contêineres, incluindo o daemon interno do Docker, permanecerão em um sistema de arquivos copy-on-write (CoW). Isso pode criar incompatibilidades se o daemon interno estiver configurado para usar um driver de armazenamento que não pode ser usado em cima de um sistema de arquivos CoW existente.

Como montar o soquete Docker do seu host

Os desafios associados ao dind são melhor enfrentados evitando-se por completo seu uso. Em muitos cenários, você pode obter o efeito desejado montando o soquete Docker do seu host em um contêiner docker regular:

 docker run -d --name docker -v /var/run/docker. sock:/var/run/docker. sock \ docker: mais recente 

O Docker CLI dentro da imagem do docker interage com o socket daemon do Docker que encontra em /var/run/docker. sock. Montar o soquete do seu host neste caminho significa que os comandos do docker executados dentro do contêiner serão executados em seu daemon existente do Docker.

Isso significa que os contêineres criados pelo Docker interno residirão em seu sistema host, ao lado do próprio contêiner do Docker. Todos os contêineres existirão como irmãos, mesmo que pareça que o Docker aninhado é filho do pai. Executar docker ps produzirá os mesmos resultados, quer seja executado no host ou dentro do seu contêiner.

Esta técnica atenua os desafios de implementação do dind. Ele também elimina a necessidade de usar o modo privilegiado, embora a montagem do soquete Docker seja uma preocupação potencial de segurança. Qualquer coisa com acesso ao soquete pode enviar instruções ao daemon do Docker, fornecendo a capacidade de iniciar contêineres em seu host, extrair imagens ou excluir dados.

Quando usar cada abordagem

O Docker-in-Docker via dind tem sido historicamente amplamente usado em ambientes de CI. Significa o “ interno ” os contêineres têm uma camada de isolamento do host. Um único contêiner de execução de CI oferece suporte a todos os contêineres de pipeline sem poluir o daemon do Docker do host.

Publicidade

Embora muitas vezes funcione, está repleto de efeitos colaterais e não é o caso de uso pretendido para o dind. Ele foi adicionado para facilitar o desenvolvimento do próprio Docker, não fornecer suporte ao usuário final para instalações do Docker aninhadas.

De acordo com Jérôme Petazzoni, o criador da implementação dind, adotar a abordagem baseada em soquete deve ser sua solução preferida. A montagem do Bind no soquete daemon do seu host é mais segura, mais flexível e tão completa quanto iniciar um contêiner dind.

Se o seu caso de uso significa que você absolutamente precisa do dind, há uma maneira mais segura de implantá-lo. O projeto Sysbox moderno é um tempo de execução de contêiner dedicado que pode aninhar outros tempos de execução sem usar o modo privilegiado. Os contêineres do Sysbox tornam-se semelhantes à VM, de modo que são capazes de oferecer suporte a software que geralmente é executado bare-metal em uma máquina física ou virtual. Isso inclui Docker e Kubernetes sem nenhuma configuração especial.

Conclusão

Executar o Docker dentro do Docker é um requisito relativamente comum. É mais provável que você veja isso ao configurar servidores de CI que precisam oferecer suporte à criação de imagens de contêiner de dentro de pipelines criados pelo usuário.

Usar docker: dind oferece um daemon Docker independente rodando dentro de seu próprio contêiner. Ele efetivamente cria contêineres filho que não são diretamente visíveis do host. Embora pareça oferecer um forte isolamento, o dind realmente abriga muitos problemas de casos extremos e preocupações de segurança. Isso se deve às interações do sistema operacional do Docker.

Publicidade

Montar o soquete Docker do seu host em um contêiner que inclui o binário do docker é uma alternativa mais simples e previsível. Isso permite que o processo do Docker aninhado inicie contêineres que se tornam seus próprios irmãos. Nenhuma configuração adicional é necessária quando você usa a abordagem baseada em soquete.