Deseja-se executar um container Docker no qual um diretório específico dentro do container seja mapeado em um diretório específico da máquina host. Esse diretório do host deve ser especificado pelo usuário do Docker por meio de seu caminho absoluto no comando de execução do container.
A solução para esse problema consiste em utilizar
Auma imagem.
Bum volume.
Cum bind mount.
Dum tmpfs mount.
Euma rede virtual.
Revelar gabarito e comentário▾
GabaritoC — um bind mount.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Contêineres Docker: bind mount, volume e tmpfs
Gabarito: letra C. O problema descreve exatamente um bind mount: mapear um diretório específico do host (informado por caminho absoluto no comando docker run -v /caminho/host:/caminho/container) para um diretório dentro do container. Essa é a definição canônica de bind mount na documentação do Docker — diferentemente de volumes (gerenciados pelo Docker) e tmpfs (memória RAM).
O Docker oferece três formas principais de persistir ou compartilhar dados entre o host e o container: bind mounts, volumes e tmpfs mounts. A diferença central está em quem controla o diretório e onde ele vive:
Bind mount: você, usuário, escolhe um diretório existente no host (ex.: /home/joao/dados) e o monta dentro do container. O Docker não gerencia esse diretório — ele apenas "liga" o caminho do host ao caminho do container. É exatamente o que o enunciado pede: "um diretório específico dentro do container seja mapeado em um diretório específico da máquina host" e "esse diretório do host deve ser especificado pelo usuário do Docker por meio de seu caminho absoluto".
Volume: o Docker cria e gerencia um diretório dentro da área de armazenamento do próprio Docker (em /var/lib/docker/volumes/). Você não especifica um caminho do host — apenas um nome de volume. É a forma recomendada para persistência de dados, mas não atende ao requisito de "caminho absoluto do host especificado pelo usuário".
tmpfs mount: monta um diretório na memória RAM do host, não em disco. Os dados são voláteis (somem quando o container para). Não há mapeamento para um diretório persistente do host.
Na prática, o comando seria algo como:
docker run -v /home/joao/dados:/app/dados minha-imagem
Aqui, /home/joao/dados é o caminho absoluto no host, e /app/dados é o diretório dentro do container. O Docker "amarra" os dois: qualquer arquivo criado em um aparece no outro.
A pegadinha da banca está em confundir bind mount com volume. Ambos permitem compartilhar dados, mas a diferença é o controle do diretório: no bind mount, o usuário especifica o caminho absoluto do host; no volume, o Docker gerencia o local (você só dá um nome). Como o enunciado exige explicitamente o caminho absoluto do host, a resposta só pode ser bind mount.
Guarde essa distinção: bind mount = você escolhe o caminho do host; volume = o Docker escolhe; tmpfs = memória RAM. É exatamente nessa fronteira que as alternativas se dividem.
Mecanismo
Quem controla o diretório
Local do armazenamento
Especificação pelo usuário
Persistência
Bind mount
Usuário
Diretório existente no host (caminho absoluto)
Caminho absoluto do host (ex.: -v /home/joao/dados:/app)
Sim (disco do host)
Volume
Docker
Área gerenciada pelo Docker (/var/lib/docker/volumes/)
Nome do volume (ex.: -v meu-volume:/app)
Sim (disco do host)
tmpfs mount
Docker
Memória RAM do host
Nenhum (apenas ponto de montagem no container)
Não (volátil)
Persistência de dados no Docker: Bind mount (usuário escolhe caminho absoluto do host, Docker apenas "liga" host ao container); Volume (Docker gerencia o diretório, usuário dá apenas um nome); tmpfs mount (memória RAM, dados voláteis)
Alternativa A — ❌ Incorreta
Uma imagem é um pacote imutável com o sistema de arquivos, bibliotecas e configurações da aplicação. Ela serve de modelo para criar containers, mas não realiza mapeamento de diretórios entre host e container. O enunciado pede uma solução de montagem de dados, não um artefato de empacotamento.
Alternativa B — ❌ Incorreta
Um volume é um diretório gerenciado pelo Docker, criado em área própria (/var/lib/docker/volumes/). O usuário não especifica um caminho absoluto do host — apenas um nome (ex.: docker run -v meu-volume:/app). Como o enunciado exige que o diretório do host seja especificado por caminho absoluto, o volume não atende. É o distrator mais perigoso, pois também serve para persistir dados.
Alternativa C — ✅ Correta ⟵ GABARITO
O bind mount é exatamente o mecanismo que mapeia um diretório do host (especificado por caminho absoluto no comando docker run -v /caminho/host:/caminho/container) para um diretório dentro do container. O usuário tem controle total sobre o local no host, e os dados são compartilhados bidirecionalmente. É a solução descrita no enunciado.
Alternativa D — ❌ Incorreta
Um tmpfs mount monta um diretório na memória RAM do host, não em disco. Os dados são voláteis — desaparecem quando o container é encerrado. Não há mapeamento para um diretório persistente do host, portanto não atende ao requisito.
Alternativa E — ❌ Incorreta
Uma rede virtual (como as redes bridge ou overlay do Docker) conecta containers entre si e com o host em nível de rede (IP, portas). Não tem relação com mapeamento de diretórios ou persistência de dados. O enunciado trata de armazenamento, não de conectividade.