Montagem do Docker: Explicação sobre volumes, montagens vinculadas e tmpfs

Então, você acabou de parar o contêiner Docker para atualizar um arquivo de configuração, mas quando você o reiniciou, todos os dados tinham sumido. Já passei por isso.

Isso acontece porque os contêineres são efêmeros por padrão – quando são removidos, todos os dados armazenados em sua camada gravável desaparecem. As aplicações reais não podem funcionar assim. Você precisa de bancos de dados que continuem funcionando, arquivos de configuração que sobrevivam às reinicializações e registros que você possa realmente acessar.

O Docker mount resolve esse problema conectando o armazenamento do contêiner a locais externos. Existem três tipos: volumes para dados de produção, montagens vinculadas para fluxos de trabalho de desenvolvimento e tmpfs para arquivos temporários armazenados na memória.

Neste artigo, vou te mostrar como escolher o tipo de montagem certo para o seu caso de uso e implementá-lo corretamente. Pra entender tudo o que tá neste artigo, você precisa saber um pouco sobre Docker e contêinerização. Faça nosso curso intermediário sobre Docker,, para se atualizar rapidamente.

Como o Docker lida com o armazenamento

Os contêineres Docker usam um sistema de arquivos em camadas que trata tudo como temporário por padrão.

Quando você cria uma imagem Docker, cada instrução no seu Dockerfile cria uma nova camada somente leitura. Essas camadas ficam empilhadas umas em cima das outras, tipo um baralho de cartas. Se você baixar uma imagem do Ubuntu com o Python instalado, vai ter uma camada para o sistema operacional base e outra para o Python.

O problema é que todas essas camadas são somente de leitura. Não dá pra mexer neles.

O sistema de arquivos do contêiner e a camada gravável

Quando você inicia um contêiner, o Docker adiciona mais uma camada por cima - a camada de contêiner gravável. camada de contêiner gravável.

É aqui que todas as mudanças acontecem. Cada arquivo que você cria, configuração que modifica e registro de tabela que adiciona fica aqui.

Parece ótimo, mas o problema é que essa camada está ligada ao ciclo de vida do contêiner.

Quando você para e remove o contêiner com o comando ` docker rm`, a camada gravável desaparece. Tudo em que você trabalhou se foi. O Docker não vai pedir confirmação. Ele simplesmente apaga tudo.

Esse design faz sentido para aplicativos sem estado que não precisam lembrar nada entre as execuções. Mas as aplicações reais não são stateless.

Por que as montagens são necessárias

A camada gravável tem dois grandes problemas para ambientes de produção.

Primeiro, você perde dados quando os contêineres param. Qual é a utilidade de um contêiner de banco de dados que esquece todas as linhas depois de reiniciar? Não consigo pensar em nada além de fazer testes de integração para o seu aplicativo.

Segundo, não dá para compartilhar dados entre contêineres. Digamos que você esteja executando um aplicativo web e um trabalhador em segundo plano que precisam acessar os mesmos arquivos. Se esses arquivos estiverem na camada gravável de um contêiner, o outro contêiner não vai conseguir vê-los.

As montagens do Docker resolvem os dois problemas conectando os contêineres a um armazenamento que existe fora do ciclo de vida do contêiner. Você pode montar um diretório da sua máquina host ou um volume gerenciado pelo Docker. Seus dados continuam mesmo quando os contêineres são removidos. Vários contêineres podem montar o mesmo local e compartilhar arquivos em tempo real.

É por isso que você precisa usar suportes. Vamos ver os tipos de montagem e, em seguida, vou mostrar como eles funcionam.

Tipos de montagem do Docker em resumo

O Docker oferece três maneiras de lidar com dados persistentes, e cada uma resolve problemas diferentes. Aqui tá o que cada tipo faz e quando você deve usá-lo.

Volumes

Os volumes são a resposta padrão do Docker para armazenamento persistente.

O Docker cria e gerencia volumes para você em um diretório dedicado na sua máquina host. Você não precisa saber onde fica esse diretório, tudo isso é feito automaticamente para você. Isso torna os volumes portáteis entre diferentes sistemas e seguros para uso na produção.

Quando você tira um recipiente, o volume continua o mesmo. Se você iniciar um novo contêiner e anexar o mesmo volume, todos os seus dados estarão exatamente onde você os deixou.

Os volumes funcionam melhor para bancos de dados de produção, estado de aplicativos e quaisquer dados que você não pode perder.

Montagens de encadernação

As montagens vinculadas conectam um diretório específico na sua máquina host diretamente a um contêiner.

Você escolhe o caminho exato no seu host - tipo /home/user/project - e o Docker mapeia isso no contêiner. Quando você altera um arquivo no seu host, o contêiner vai ver a alteração na hora. Altere um arquivo no contêiner e ele aparecerá no seu host.

Essa sincronização em tempo real torna as montagens bind perfeitas para desenvolvimento.

Mas as montagens vinculadas têm seus riscos. Eles expõem caminhos do host para contêineres e dependem de estruturas de diretórios específicas que podem não existir em outras máquinas.

montagens tmpfs

As montagens tmpfs guardam os dados na memória do seu host, em vez de no disco.

Nada é gravado no sistema de arquivos. Quando o contêiner para, os dados somem completamente. Isso faz com que as montagens tmpfs sejam úteis paradados temporários que você não quer que fiquem guardados - tipo tokens de autenticação, dados de sessão ou arquivos de cache que você vai reconstruir de qualquer maneira.

Dito isso, as montagens tmpfs são limitadas pela RAM disponível e só funcionam em hosts Linux.

Volumes do Docker para dados persistentes

Os volumes são a solução de armazenamento pronta para produção do Docker, e você deve usá-los por padrão, a menos que tenha um motivo específico para não fazê-lo.

Eles são totalmente gerenciados pelo Docker, funcionam de maneira consistente em diferentes plataformas e sobrevivem à remoção de contêineres por padrão. Se você estiver executando bancos de dados, armazenando o estado de aplicativos ou lidando com quaisquer dados que precisem sobreviver a um único contêiner, os volumes são a resposta.

Como funcionam os volumes do Docker

O Docker guarda os volumes num diretório específico na sua máquina host:

• Linux: /var/lib/docker/volumes/
• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/
• Windows: \\wsl$\docker-desktop-data\data\docker\volumes\, assumindo backend WSL2

Você não gerencia esse diretório diretamente. O Docker cuida da criação, das permissões e da limpeza por meio da sua própria API. Essa separação faz com que os volumes funcionem da mesma maneira, seja no Linux, Mac ou Windows, o que torna a configuração do seu contêiner portátil entre os ambientes de desenvolvimento e produção.

O importante aqui é lembrar que os volumes existem independentemente de qualquer contêiner. Quando você cria um volume, conecta-o a um contêiner, executa seu aplicativo e, em seguida, interrompe e exclui esse contêiner, o volume permanece exatamente onde está, com todos os seus dados intactos.

Se você iniciar um novo contêiner e anexar o mesmo volume, seus dados ainda estarão lá.

Criando e reutilizando volumes

Você pode criar um volume nomeado antes de iniciar qualquer contêiner:

docker volume create mydata

Depois, conecte-o quando você rodar um contêiner usando a flag ` --mount `:

docker run -d \
  --name postgres-db \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Isso monta o volume mydata em /var/lib/postgresql/data dentro do contêiner, onde o Postgres guarda seus arquivos de banco de dados.

Agora você pode parar e remover esse contêiner e, em seguida, iniciar um novo com o mesmo volume:

docker rm -f postgres-db

docker run -d \
  --name postgres-db-new \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Seu banco de dados está de volta com todas as tabelas e linhas intactas.

Esse é o objetivo dos volumes: manter os dados durante todo o ciclo de vida dos contêineres.

Gerenciando e mantendo dados de volume

Você pode usar esse comando pra ver quais volumes estão no seu sistema:

docker volume ls

Depois, você pode usar esse comando pra dar uma olhada em um volume específico e ver onde ele tá guardado e quais contêineres o usam:

docker volume inspect mydata

Isso mostra o ponto de montagem no seu host e metadados úteis. Mas você raramente precisa acessar esse diretório diretamente — isso é tarefa do Docker.

Se você já terminou com o volume e quer removê-lo, é só executar este comando:

docker volume rm mydata

O Docker não permite que você exclua um volume que está conectado a um contêiner em execução. Primeiro, pare o contêiner e, em seguida, remova o volume.

Por fim, se você quiser limpar recursos e recuperar espaço em disco, pode executar este comando para remover todos os volumes não utilizados de uma só vez:

docker volume prune

Para configurações de produção, o Docker suporta drivers de volume que se conectam a sistemas de armazenamento externos, como NFS, AWS EFS ou armazenamento em bloco na nuvem. Você escolhe o driver quando cria o volume, e o Docker cuida do resto. Isso permite que você armazene dados totalmente fora da sua máquina host, o que é importante para configurações de alta disponibilidade, nas quais os contêineres se movem entre servidores.

A seguir, vamos falar sobre montagens vinculadas.

Montagens vinculadas para desenvolvimento local

As montagens vinculadas permitem que você acesse diretamente o sistema de arquivos do host de dentro de um contêiner, e é por isso que os desenvolvedores adoram elas.

São ótimos para desenvolvimento local, mas têm algumas desvantagens que os tornam arriscados para produção. Você tem sincronização de arquivos em tempo real e nenhuma etapa de compilação, mas perde a portabilidade e pode abrir brechas de segurança.

Como funcionam as montagens bind

Uma montagem vinculada mapeia um diretório específico na sua máquina host diretamente para um contêiner.

Você coloca o caminho exato - tipo /home/user/myapp - e o Docker deixa isso disponível num caminho dentro do contêiner. Não tem cópia, nem armazenamento gerenciado pelo Docker, nem camada de abstração. O contêiner vê seus arquivos host reais.

Se você alterar um arquivo no seu host, o contêiner verá a alteração imediatamente. Da mesma forma, se você mexer num arquivo dentro do contêiner, ele vai ser atualizado no seu host. Os dois lados estão trabalhando com os mesmos arquivos em tempo real.

Aqui tá um bind mount em ação:

docker run -d \
  --name dev-app \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  python:3.14

Isso monta /Users/dradecic/Desktop/app do meu host para /app dentro do contêiner. Quando eu edito um arquivo Python no /Users/dradecic/Desktop/app usando seu editor de texto, o aplicativo em contêiner vê a mudança na hora.

Você também pode usar a sintaxe mais curta:

Fluxos de trabalho comuns de desenvolvimento

O caso de uso mais comum é montar seu código-fonte durante o desenvolvimento.

Digamos que você esteja criando um aplicativo FastAPI. Você pode montar o diretório do seu projeto no contêiner, ativar a recarga a quente e terá um ambiente de desenvolvimento completo:

docker run -d \
  --name fastapi-dev \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  -w /app \
  -p 8000:8000 \
  python:3.14 \
  sh -c "pip install fastapi uvicorn && uvicorn main:app --reload --host 0.0.0.0"

Só pra você ter uma ideia, esse é o meu arquivo main.py:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(
    title="FastAPI Docker Demo",
    description="A minimal FastAPI app running inside Docker",
    version="1.0.0",
)

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.get("/")
def read_root():
    return {
        "message": "FastAPI is running",
        "docs": "/docs",
        "redoc": "/redoc",
    }

@app.get("/health")
def health_check():
    return {"status": "ok"}

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "Item received",
        "item": item,
    }

Depois de rodar o comando Docker, o aplicativo fica disponível na minha máquina host na porta 8000:

Se você editar main.py no seu editor, salve o arquivo, o FastAPI vai recarregar automaticamente. Sem precisar reconstruir imagens, sem precisar reiniciar contêineres. Você escreve código como faria localmente, mas seu aplicativo é executado em um ambiente de contêiner consistente.

Riscos e limitações

As montagens vinculadas expõem o sistema de arquivos do seu host aos contêineres, e isso pode criar problemas de segurança.

Um contêiner com uma montagem vinculada pode ler e gravar arquivos no seu host. Execute um contêiner como root — que é o padrão — e ele terá acesso root aos arquivos montados. Um código malicioso ou um contêiner comprometido pode mexer ou apagar qualquer coisa no diretório montado.

A portabilidade é outra questão.

As montagens vinculadas dependem de caminhos específicos que existem no host. O arquivo /Users/dradecic/Desktop/app não está no seu computador nem em um servidor de produção. Isso acaba com a promessa de que os contêineres “funcionam em qualquer lugar”.

As diferenças entre plataformas também são um problema. O Windows e o Mac usam uma VM para rodar o Docker, então as montagens vinculadas passam por uma camada extra de tradução. Isso deixa as operações com arquivos mais lentas e pode causar pequenos bugs com a monitorização de arquivos e links simbólicos.

Os ambientes de produção nunca devem usar montagens bind.

Eles dependem demais de caminhos específicos do host, são muito arriscados do ponto de vista da segurança e impossíveis de controlar por versão. Os volumes resolvem todos esses problemas, e é por isso que são o padrão de produção.

Veja os bind mounts como uma ferramenta de desenvolvimento — rápida, prática e poderosa, mas nada que você queira usar perto da produção.

Montagens tmpfs para dados temporários

As montagens tmpfs guardam os dados na RAM do seu host, em vez de no disco. Isso faz com que sejam perfeitos para dados que você não quer guardar.

Como funciona o armazenamento na memória

Uma montagem tmpfs existe inteiramente na memória.

O Docker aloca RAM na sua máquina host e a disponibiliza como um sistema de arquivos dentro do contêiner. Um arquivo gravado em uma montagem tmpfs nunca toca no seu disco. Os dados ficam na memória até o contêiner parar.

Quando você para o contêiner, tudo o que está na montagem tmpfs é excluído. Não precisa limpar nada, não fica nenhum arquivo sobrando, nem vestígio do que estava lá. Toda vez que você reinicia o contêiner, você recebe uma montagem tmpfs nova e vazia.

Resumindo, as montagens tmpfs são para dados que você explicitamente não quer manter - cálculos temporários, tokens de sessão ou informações confidenciais que não devem persistir após o uso.

Casos de uso típicos

O caso de uso mais comum é guardar segredos ou dados confidenciais.

Digamos que você esteja executando um contêiner que precisa de uma chave API ou senha de banco de dados. Guarde-o em uma montagem tmpfs, e o segredo nunca vai ficar gravado no disco. Quando o contêiner para, o segredo some da memória. Não tem nenhum arquivo que possa ser enviado sem querer pro controle de versão ou ficar exposto no sistema de arquivos.

Os caches também são uma boa opção. Não precisa guardar artefatos de compilação, código compilado ou dependências baixadas que você vai regenerar de qualquer maneira. Coloque-os em tmpfs para um acesso mais rápido durante a vida útil do contêiner e, em seguida, deixe-os desaparecer quando terminar.

Os arquivos temporários também funcionam bem aqui — pense em dados de sessão, arquivos de bloqueio ou resultados de processamento intermediários que só importam enquanto o contêiner está rodando.

Configuração básica

Execute este comando para criar uma montagem tmpfs usando o sinalizador ` --tmpfs `:

docker run -d \
  --name temp-app \
  --tmpfs /tmp:rw,size=100m \
  python:3.14

Isso cria uma montagem tmpfs de 100 MB em /tmp dentro do contêiner. A opção ` size ` limita a quantidade de RAM que a montagem pode usar.

Você também pode usar a sintaxe --mount:

docker run -d \
  --name temp-app \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=104857600 \
  python:3.14

O valor tmpfs-size é em bytes - 104857600 bytes equivalem a 100 MB.

Se você não definir um limite de tamanho, o tmpfs vai usar até metade da RAM do seu sistema. Isso é perigoso — por motivos óbvios. Sempre defina limites de tamanho bem claros.

A única grande desvantagem é que as montagens tmpfs só funcionam no Linux.

O Docker Desktop para Mac e Windows não dá suporte a eles porque rodam o Docker dentro de uma VM Linux, e o tmpfs precisa de suporte direto do kernel.

Sintaxe e configuração do Docker Mount

O Docker oferece duas maneiras de definir montagens, e escolher a sintaxe certa torna seus comandos mais fáceis de ler e depurar.

As duas abordagens funcionam, mas uma delas é melhor quando você precisa de opções avançadas ou várias montagens em um único contêiner.

-mount vs --volume

A flag ` --mount ` usa pares chave-valor explícitos, enquanto ` -v ` ou ` --volume ` usa uma string separada por dois pontos.

Aqui está a mesma montagem de volume com as duas sintaxes:

# Using --mount
docker run -d \
  --mount type=volume,source=mydata,target=/app/data \
  python:3.14

# Using -v
docker run -d \
  -v mydata:/app/data \
  python:3.14

Ambos criam um volume chamado mydata e o montam em /app/data no contêiner.

Use --mount para qualquer coisa além das configurações básicas. É mais detalhado, mas as chaves explícitas deixam claro o que cada parte faz. Quando você adiciona opções como acesso somente leitura ou drivers de volume personalizados, ele continua legível, enquanto -v pode parecer uma sequência de caracteres enigmática.

A sintaxe -v é boa para fluxos de trabalho de desenvolvimento simples, onde você digita os comandos manualmente.

Opções comuns de montagem

A opção ` readonly ` impede que os contêineres modifiquem os dados montados:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,readonly \
  python:3.14

Isso é útil para arquivos de configuração ou dados de referência que os contêineres devem ler, mas nunca alterar. Um contêiner que tenta gravar em uma montagem somente leitura recebe um erro de permissão.

Para volumes, a opção ` volume-nocopy ` pula a cópia dos dados existentes da imagem do contêiner para o volume:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,volume-nocopy \
  python:3.14

Por padrão, o Docker copia tudo o que existe no ponto de montagem da imagem para um novo volume. Quando você define volume-nocopy, você obtém um volume vazio, independentemente do que está na imagem.

Para montagens tmpfs, a opção ` tmpfs-size ` define um limite de memória:

docker run -d \
  --mount type=tmpfs,target=/tmp,tmpfs-size=104857600 \
  python:3.14

Isso limita a montagem do tmpfs a 100 MB. Sem isso, uma montagem tmpfs pode usar toda a RAM disponível.

Montagem sobre dados existentes

Quando você monta um diretório que já existe na imagem do contêiner, a montagem esconde completamente tudo o que estava lá.

Digamos que sua imagem tenha um diretório /app/data com arquivos de configuração embutidos. Quando você monta um volume em /app/data, esses arquivos de configuração vão sumir. O contêiner só vê o que está no volume.

Isso rola com todos os tipos de montagem - volumes, montagens vinculadas e tmpfs. O conteúdo montado tem prioridade, e o diretório original fica inacessível enquanto a montagem estiver ativa.

Usando montagens com o Docker Compose

O Docker Compose facilita a definição e o compartilhamento de montagens entre vários contêineres na sua pilha de aplicativos.

Em vez de digitar comandos longos do docker run com sinalizadores de montagem, você declara tudo em um arquivo docker-compose.yml. Deixa eu te mostrar como.

Definindo volumes e montagens vinculadas no Compose

Aqui está um arquivo Compose com exemplos de volume e montagem vinculada:

services:
  service-1:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - ./code:/app          # Bind mount for development
      - shared:/data         # Named volume shared with worker

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - shared:/data         # Same volume as service-1

volumes:
  shared:

A chave volumes em cada serviço define o que é montado. Caminhos relativos como ./code criam montagens vinculadas, enquanto nomes como shared fazem referência a volumes nomeados.

A seção de nível superior volumes declara os volumes nomeados que o Compose cria e gerencia. Tanto service-1 quanto service-2 montam o mesmo volume shared, então eles veem os mesmos arquivos. Escreva um arquivo de um contêiner e o outro contêiner poderá lê-lo imediatamente.

O comando ` sleep infinity ` mantém os contêineres em execução para que você possa executá-los - só para fins de demonstração.

Persistência e verificação de dados

Comece sua pilha com docker compose up -d e, em seguida, verifique se as montagens funcionam:

# Write data to the shared volume from app
docker compose exec service-1 sh -c "echo 'test' > /data/file.txt"

# Read it from worker
docker compose exec service-2 cat /data/file.txt

Se os dois comandos funcionarem, seus volumes estão configurados corretamente.

Agora você pode executar este comando para parar e remover tudo:

docker compose down

Os volumes nomeados por você ainda estarão lá. Se você reiniciar a pilha com docker compose up -d, os dados que você escreveu antes ainda estarão lá. É assim que os bancos de dados continuam nas implantações — o volume dura mais que o contêiner.

Para excluir volumes quando você parar a pilha, adicione o -v :

docker compose down -v

Isso remove todos os volumes definidos no seu arquivo Compose. Use quando quiser começar do zero.

Preenchendo volumes com dados iniciais

O padrão mais comum é usar um contêiner init separado para inicializar o volume compartilhado:

services:
  init:
    image: ubuntu:latest
    command: sh -c "mkdir -p /source && echo 'initial data' > /source/seed.txt && cp /source/* /dest/"
    volumes:
      - shared:/dest

  service-1:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

volumes:
  shared:

O contêiner ` init ` cria dados iniciais e os copia para o volumecompartilhado ` `, depois sai. Tanto service-1 quanto service-2 começam depois e encontram os dados inicializados prontos para uso.

O Compose lida com a complexidade de coordenar vários contêineres e seu armazenamento compartilhado em um único arquivo controlado por versão.

Desempenho e segurança do Docker Mount

Escolher o tipo errado de montagem pode deixar seus contêineres mais lentos ou criar falhas de segurança que você nem sabia que existiam. Dá uma olhada nessa seção se você não quer que isso aconteça.

Compromissos de desempenho entre os tipos de montagem

Os volumes têm o melhor desempenho no Linux porque ficam guardados direto no sistema de arquivos do host, sem precisar de uma camada de tradução.

No Mac e no Windows, o Docker rola dentro de uma VM Linux. Os volumes continuam funcionando bem porque ficam dentro dessa VM. Por outro lado, as montagens vinculadas precisam sincronizar os arquivos entre o sistema operacional host e a VM Linux, o que aumenta a sobrecarga. As operações de arquivo em montagens vinculadas podem ser bem mais lentas no Mac e no Windows do que no Linux nativo.

O tmpfs é a opção mais rápida para operações de leitura e gravação, porque tudo rola na RAM. Sem E/S de disco, sem sobrecarga do sistema de arquivos. Mas você está limitado pela memória disponível, e os dados desaparecem quando o contêiner é desligado.

Se você estiver no Linux e precisar do máximo de desempenho, use volumes. Se você estiver usando Mac ou Windows e perceber lentidão nas operações de arquivo durante o desenvolvimento, provavelmente está enfrentando uma sobrecarga de montagem de ligação. Mude para volumes para cargas de trabalho de produção.

Implicações de segurança das montagens

Cada montagem dá aos contêineres acesso a algo fora do seu sistema de arquivos isolado, e isso cria riscos.

As montagens de ligação são a maior preocupação. Se você montar um /home/user em em um contêiner, um contêiner comprometido poderá ler suas chaves SSH, modificar a configuração do seu shell ou excluir arquivos em todo o seu diretório home. Execute esse contêiner como root — o padrão — e ele terá acesso de nível root a esses arquivos.

Os volumes diminuem esse risco porque ficam isolados no diretório de armazenamento do Docker. Um contêiner não pode montar caminhos de host arbitrários por meio de volumes. Mas os volumes ainda podem vazar dados entre contêineres se você compartilhá-los sem cuidado.

As montagens tmpfs minimizam o risco de persistência - os segredos guardados na memória somem quando os contêineres param. Mas eles não protegem contra ataques em tempo de execução, nos quais um contêiner comprometido lê segredos da memória.

A regra geral é que as montagens quebram o isolamento do contêiner, então use-as com cuidado.

Melhores práticas para montagens seguras

Monte só o que os contêineres precisam e nada mais.

Em vez de montar todo o diretório do seu projeto, monte só o subdiretório que o contêiner usa. Em vez de montar /var/log com acesso de gravação, monte-o como somente leitura se o contêiner precisar apenas ler os registros.

Use a opção “ readonly ” sempre que puder:

docker run -d \
  --mount type=bind,source=/app/config,target=/config,readonly \
  ubuntu:latest

Isso evita que os contêineres modifiquem os dados montados, limitando os danos caso eles sejam comprometidos.

Execute contêineres como usuários não root para diminuir o impacto das vulnerabilidades de montagem vinculada. Crie um usuário no seu Dockerfile e mude para ele antes de iniciar o contêiner:

RUN useradd -m appuser
USER appuser

Limpe regularmente os volumes não utilizados com o comando ` docker volume prune`. Os volumes antigos vão se acumulando com o tempo, ocupando espaço em disco e podendo conter dados confidenciais de contêineres excluídos.

Nunca monte diretórios sensíveis do host, como /, /etc ou /var, a menos que você tenha um motivo específico e entenda os riscos. Cada montagem deve ter um objetivo claro e um escopo mínimo.

Resolução de problemas de montagem do Docker

Problemas de montagem geralmente aparecem como erros de permissão, arquivos faltando ou contêineres que não iniciam — e quase sempre são causados pelo mesmo conjunto de problemas.

Veja como diagnosticar e resolver os problemas mais comuns que você vai encontrar.

Erros de permissão e propriedade

Erros de permissão acontecem quando o usuário dentro do contêiner não tem acesso aos arquivos montados.

Os contêineres Docker rodam como root por padrão. Quando o root cria um arquivo em uma montagem bind, esse arquivo é de propriedade do root no seu host. Se você tentar editar com sua conta de usuário normal, vai aparecer um erro de permissão negada.

O contrário também rola. Monte um diretório que você possui em um contêiner executado como usuário não root, e o contêiner poderá não conseguir gravar nele.

Você pode verificar a propriedade do arquivo com o comando ` ls -la ` no diretório montado:

ls -la /path/to/mounted/directory

Se os arquivos pertencem ao root, mas seu contêiner é executado como um usuário diferente, você tem uma incompatibilidade. Resolva isso rodando o contêiner com o mesmo usuário que é dono dos arquivos:

docker run -d \
  --user $(id -u):$(id -g) \
  -v ./data:/app/data \
  ubuntu:latest

Isso faz o contêiner rodar como seu usuário atual em vez de root, combinando com a propriedade dos arquivos na montagem de ligação.

Para volumes, o Docker lida com as permissões automaticamente quando os contêineres criam arquivos. Mas se você estiver vendo erros, veja com qual usuário o aplicativo em contêiner está rodando e se ele tem acesso de gravação ao ponto de montagem.

Erros de caminho e configuração

O erro mais comum é montar um caminho que não existe no host.

Tente montar /home/user/project quando esse diretório não existir, e o Docker criará um diretório vazio pertencente ao root. Seu contêiner inicia, mas está montando a coisa errada — um diretório vazio em vez do seu projeto real.

Sempre verifique se os caminhos existem antes de montá-los:

ls /home/user/project

Se o diretório não existir, crie-o primeiro ou corrija o caminho no seu comando de montagem.

No Docker Compose, os caminhos relativos são resolvidos a partir do diretório que tem o seu arquivo ` docker-compose.yml `. Se o seu arquivo estiver em /home/user/app/ e você usar ./data, o Docker vai procurar /home/user/app/data.

Mova o arquivo Compose e a montagem será interrompida.

Outro erro comum é montar no caminho de destino errado dentro do contêiner. Monte em /app/data quando seu aplicativo esperar /data, e o aplicativo não vai conseguir encontrar seus arquivos. Dá uma olhada na documentação do seu aplicativo ou no Dockerfile pra confirmar onde ele espera que os dados estejam.

Peculiaridades específicas da plataforma

No Linux, as montagens bind funcionam direto com o sistema de arquivos do host.

No Mac e no Windows, o Docker rola dentro de uma VM Linux. As montagens vinculadas sincronizam arquivos entre o sistema operacional host e a VM, o que cria problemas de sincronização. Os observadores de arquivos — ferramentas que recarregam seu aplicativo quando os arquivos mudam — às vezes perdem atualizações por causa de atrasos na sincronização.

O Mac e o Windows também lidam com as permissões de arquivos de maneiras diferentes. A VM traduz as permissões entre o sistema operacional host e o Linux, o que pode fazer com que os arquivos apareçam com propriedade incorreta dentro dos contêineres.

Os links simbólicos não funcionam bem em montagens bind no Mac e no Windows. A VM nem sempre consegue resolver links simbólicos que apontam para fora do diretório montado, então os arquivos parecem estar faltando ou corrompidos dentro dos contêineres.

As montagens tmpfs não funcionam no Mac e no Windows porque a VM não expõe o tmpfs ao host. Se você tentar usar uma montagem tmpfs, o Docker vai ignorá-la sem avisar ou mostrar um erro, dependendo da versão.

Se você estiver desenvolvendo no Mac ou Windows e tiver problemas estranhos de sincronização de arquivos, mude para volumes nomeados para obter melhor desempenho e confiabilidade. Guarde as montagens vinculadas para fluxos de trabalho de desenvolvimento em que a sincronização em tempo real é mais importante do que a consistência perfeita.

Conclusão

Para resumir, use volumes para dados de produção que precisam ser mantidos, como bancos de dados, arquivos enviados, estado do aplicativo — tudo o que você não pode perder. São gerenciados pelo Docker, portáteis entre plataformas e a escolha mais segura para dados importantes.

As montagens vinculadas são usadas em fluxos de trabalho de desenvolvimento onde você precisa de sincronização de arquivos em tempo real entre o host e os contêineres. Quando você editar o código no seu editor, vai ver as mudanças na hora no seu aplicativo em contêiner. Mas não os coloque em produção, pois eles dependem muito de caminhos específicos do host e criam riscos de segurança desnecessários.

Quando você estiver pronto para mergulhar mais fundo na conteinerização e virtualização, confira nosso curso: Containerização e virtualização com Docker e Kubernetes.