Contêineres são úteis porque carregam o que a aplicação precisa para funcionar sem depender das instalações existentes na máquina hospedeira. Esse isolamento reduz conflitos entre projetos e torna o ambiente mais previsível. O mesmo isolamento, porém, impede que um contêiner enxergue automaticamente os arquivos do computador. Em desenvolvimento, isso pode ser um problema: o código está na pasta local, mas o serviço que precisa executá-lo está dentro do contêiner.
A documentação oficial do Docker apresenta duas opções principais para aproximar o host e o contêiner: volumes e bind mounts. A escolha depende do tipo de dado e de quem deve controlar o caminho. Volumes são administrados pelo Docker e fazem sentido quando o objetivo é persistir dados produzidos pela aplicação. Bind mounts ligam diretamente um arquivo ou diretório do host a um caminho dentro do contêiner, sendo especialmente úteis quando o código local precisa ser refletido imediatamente no ambiente de desenvolvimento.
O que o compartilhamento resolve
O primeiro ganho é evitar a reconstrução da imagem a cada alteração no código. Uma equipe pode manter os arquivos-fonte na máquina, iniciar o serviço dentro do contêiner e observar as mudanças montadas no caminho esperado pela aplicação. Esse fluxo aproxima a experiência de editar localmente da execução em um ambiente isolado.
Há também um caso comum com arquivos de configuração. A aplicação pode precisar ler um arquivo que está no host, mas colocar credenciais, chaves de API ou outros dados sensíveis dentro da imagem cria riscos durante o compartilhamento dessa imagem. A montagem permite separar o artefato distribuível dos arquivos que devem permanecer sob controle local. Isso não transforma automaticamente o arquivo em seguro: permissões, conteúdo e exposição continuam sendo responsabilidade de quem configura o ambiente.
Antes de montar qualquer caminho, vale definir se o contêiner precisa apenas ler ou também escrever. Uma montagem com leitura e escrita permite que o processo altere ou exclua arquivos no host, e essas alterações aparecem nos dois lados. Para configurações, exemplos e arquivos que não devem ser modificados pelo processo, a opção somente leitura reduz o risco de mudanças acidentais.
Como funcionam os bind mounts
Um bind mount cria uma ligação explícita entre um caminho do computador e um caminho dentro do contêiner. A forma curta com -v é conveniente para operações básicas. Um exemplo da documentação usa a estrutura docker run -v /HOST/PATH:/CONTAINER/PATH -it nginx. O primeiro caminho pertence ao host; o segundo é o local em que os arquivos aparecerão no contêiner.
O parâmetro --mount oferece uma descrição mais detalhada e controle granular. Essa diferença é importante quando o cenário deixa de ser um teste rápido e passa a exigir que cada opção fique clara no comando. A documentação também destaca um comportamento relevante: com --mount, se o caminho do host ainda não existir, o comando apresenta erro em vez de criá-lo automaticamente. Isso ajuda a descobrir um caminho digitado incorretamente antes de iniciar o serviço.
Em ambos os casos, o caminho precisa ser conferido com cuidado. Um diretório amplo demais pode expor mais arquivos que o necessário. O caminho do host deve conter apenas o material que o processo precisa, e o destino dentro do contêiner deve coincidir com o que a aplicação realmente lê. No Windows, caminhos relativos podem se comportar de maneira diferente conforme o shell usado; a documentação recomenda fornecer o caminho absoluto no PowerShell.
Um teste prático com uma página web
O tutorial oficial propõe iniciar um contêiner Apache chamado my_site, publicar a porta 8080 e depois montar uma pasta local no diretório servido pelo Apache. A ideia é simples: o arquivo HTML fica no host e o processo dentro do contêiner o entrega. Depois de iniciar o serviço, a página pode ser aberta no endereço local publicado ou verificada com uma ferramenta como curl.
O fluxo de teste deve ser feito em pequenas etapas. Primeiro, crie ou escolha uma pasta dedicada e confirme que o arquivo que será compartilhado está nela. Depois, inicie o contêiner com a porta e o bind mount apontando para o diretório esperado. Em seguida, acesse a página e confirme que o conteúdo montado é o conteúdo que você editou no host. Evite reutilizar o mesmo nome de contêiner se já houver uma instância ativa: os exemplos da documentação produzem o mesmo resultado e não devem ser executados simultaneamente sem remover a instância anterior.
O teste mais útil é observar a sincronização nos dois sentidos. Altere o arquivo no host e verifique a nova resposta do Apache. Em seguida, remova o arquivo local e confirme que ele também deixou de existir no caminho montado dentro do contêiner. Depois, recrie o HTML e observe o arquivo reaparecer. Essa demonstração deixa claro que um bind mount não é uma cópia pontual: ele apresenta ao contêiner o estado atual do caminho compartilhado.
O Docker Desktop também permite inspecionar os arquivos montados a partir da área do contêiner. Essa visualização ajuda a conferir o destino efetivo e a separar um problema de montagem de um problema da aplicação. O contêiner continua em execução até ser parado, então a limpeza do teste também faz parte do procedimento.
Permissões, desempenho e escolha do armazenamento
O Docker precisa ter permissão para acessar o diretório do host. Para explicitar que o processo pode ler e escrever, o exemplo usa uma montagem com a opção :rw, como em docker run -v HOST-DIRECTORY:/CONTAINER-DIRECTORY:rw nginx. Essa autorização deve ser proporcional ao objetivo. Se o serviço só precisa consultar arquivos, uma montagem somente leitura é uma opção mais prudente e evita que um processo altere ou apague o conteúdo original.
Bind mounts são práticos, mas não servem para todo dado. Se a prioridade é manter dados gerados mesmo quando o contêiner é removido, um volume costuma ser a opção mais apropriada. Volumes são gerenciados pelo Docker e não exigem que a equipe escolha diretamente um caminho do host. Já o bind mount é a ferramenta certa quando a localização local precisa ser compartilhada de forma direta, como acontece com código em desenvolvimento.
O desempenho também merece atenção. Conforme o código cresce, o acesso frequente entre o host, a máquina virtual e o contêiner pode ficar mais lento. A documentação menciona caches de sistema de arquivos sincronizados como uma forma de melhorar esse cenário. O recurso não elimina a necessidade de medir o ambiente: frequência de leitura, quantidade de arquivos e sistema operacional influenciam o resultado.
Como checklist, confirme o caminho absoluto, limite o diretório montado, escolha leitura ou escrita conscientemente, teste a sincronização e remova o contêiner ao terminar. Para dados persistentes, avalie volume; para código e arquivos locais que precisam aparecer em tempo real, avalie bind mount. O ponto central é manter explícita a fronteira entre o host e o contêiner, em vez de abrir acesso amplo por conveniência.
Fonte e limites deste guia
Este tutorial foi elaborado a partir da documentação oficial do Docker sobre compartilhamento de arquivos locais com contêineres. Os comandos, comportamentos de -v e --mount, permissões, montagem somente leitura, exemplo com Apache e observações sobre Windows e desempenho devem ser conferidos na fonte antes de serem adaptados a um ambiente de produção.
