Manual do Docker: imagem, container e volume — diferenças práticas

18 min de leitura  ·  Guia técnico

Imagem Docker é um modelo somente leitura que empacota sistema de arquivos, dependências e metadados para criar containers. Container é a instância em execução dessa imagem — isolada, efêmera e descartável. Volume é o mecanismo de armazenamento persistente gerenciado pelo Docker, que sobrevive à remoção de containers. Entender as diferenças práticas entre os três conceitos é fundamental para evitar perda de dados e construir ambientes confiáveis em produção.

Pré-requisitos

• Docker Engine instalado (versão 24.x ou superior recomendada) — veja o artigo Como Instalar e Configurar o Docker no VPS Linux para Hospedar Aplicações se ainda não instalou
• Acesso ao terminal com usuário root ou membro do grupo docker
• Distribuição Linux compatível: Ubuntu 24.04 LTS, Debian 12 ou Rocky Linux 9
• Conexão com a internet para baixar imagens do Docker Hub
• Conhecimento básico de linha de comando Linux

Imagem Docker: o que é e como funciona na prática

Uma imagem Docker é construída em camadas sobrepostas e imutáveis, definidas por um Dockerfile. Cada instrução (FROM, RUN, COPY) gera uma nova camada que é cacheada individualmente. Isso significa que ao reconstruir uma imagem após alterar apenas o código da aplicação, o Docker reutiliza as camadas de dependências já baixadas, acelerando o processo.

Para listar imagens disponíveis localmente, execute:

docker images

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
nginx        1.26      a72860cb95fd   2 weeks ago    192MB
postgres     16        8e2b2f8e6f1a   3 weeks ago    432MB
ubuntu       24.04     bf3dc08bfed0   4 weeks ago    78.1MB

Para baixar uma imagem sem criar um container:

docker pull nginx:1.26

Para inspecionar as camadas de uma imagem e entender sua composição:

docker history nginx:1.26

IMAGE          CREATED        CREATED BY                                      SIZE
a72860cb95fd   2 weeks ago    CMD ["nginx" "-g" "daemon off;"]                0B
<missing>      2 weeks ago    EXPOSE map[80/tcp:{}]                           0B
<missing>      2 weeks ago    COPY /etc/nginx /etc/nginx                      4.61kB

Para construir sua própria imagem a partir de um Dockerfile:

docker build -t minha-app:1.0 .

O ponto final indica que o contexto de build é o diretório atual. A tag minha-app:1.0 facilita o versionamento e o rollback em caso de problemas em produção.

Para remover uma imagem que não está mais em uso:

docker rmi nginx:1.26

Atenção: não é possível remover uma imagem enquanto houver containers (mesmo parados) que a utilizam. Use docker ps -a para listar todos os containers antes de tentar remover a imagem.

Container Docker: ciclo de vida e diferenças em relação à imagem

O container Docker é a camada de escrita sobre a imagem — tudo que acontece dentro do container (arquivos criados, processos em execução, variáveis de ambiente) existe apenas enquanto o container existir. Ao remover o container com docker rm, essa camada de escrita é descartada permanentemente.

Para criar e iniciar um container a partir da imagem Nginx:

docker run -d --name meu-nginx -p 8080:80 nginx:1.26

7f3a2b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a

O parâmetro -d executa em background (detached). O -p 8080:80 mapeia a porta 8080 do host para a porta 80 do container. Ao acessar http://localhost:8080, você verá a página padrão do Nginx.

Para listar containers em execução:

docker ps

CONTAINER ID   IMAGE        COMMAND                  CREATED         STATUS         PORTS                  NAMES
7f3a2b1c4d5e   nginx:1.26   "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   0.0.0.0:8080->80/tcp   meu-nginx

Para listar todos os containers, incluindo os parados:

docker ps -a

Para parar, iniciar e remover um container:

docker stop meu-nginx
docker start meu-nginx
docker rm meu-nginx

Para executar um comando dentro de um container em execução — útil para diagnóstico:

docker exec -it meu-nginx bash

Dentro do container, você pode inspecionar arquivos de configuração, verificar logs internos e testar conectividade. Ao sair com exit, o container continua rodando normalmente.

A diferença fundamental entre imagem e container pode ser resumida assim: a imagem é o molde, o container é o produto. Você pode criar dezenas de containers a partir de uma única imagem, cada um com configurações e estados independentes.

Volume Docker: persistência de dados além do ciclo do container

O volume Docker resolve o problema central de dados efêmeros: quando um container é removido, tudo que foi gravado no seu sistema de arquivos interno desaparece. Volumes são gerenciados pelo Docker em /var/lib/docker/volumes/ e permanecem intactos mesmo após docker rm.

Para criar um volume nomeado:

docker volume create dados-postgres

dados-postgres

Para listar volumes existentes:

docker volume ls

DRIVER    VOLUME NAME
local     dados-postgres

Para usar o volume ao criar um container PostgreSQL 16:

docker run -d \
  --name meu-postgres \
  -e POSTGRES_PASSWORD=senhaSegura123 \
  -v dados-postgres:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

Neste exemplo, o diretório /var/lib/postgresql/data dentro do container é mapeado para o volume dados-postgres. Se você remover o container e recriar com o mesmo volume, todos os bancos de dados estarão intactos.

Para inspecionar detalhes de um volume, incluindo o caminho real no host:

docker volume inspect dados-postgres

[
    {
        "CreatedAt": "2025-01-15T10:30:00Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/dados-postgres/_data",
        "Name": "dados-postgres",
        "Scope": "local"
    }
]

Para remover um volume que não está mais em uso:

docker volume rm dados-postgres

Atenção: remover um volume apaga permanentemente todos os dados armazenados nele. Faça backup antes de executar este comando em produção.

Para remover todos os volumes não utilizados de uma vez (limpeza de ambiente de desenvolvimento):

docker volume prune

Bind Mount vs Volume Nomeado: quando usar cada um

Além dos volumes nomeados, o Docker oferece os bind mounts — um mecanismo diferente de persistência que mapeia um diretório específico do host diretamente para dentro do container. A escolha entre os dois impacta portabilidade, segurança e facilidade de backup.

Exemplo de bind mount em desenvolvimento:

docker run -d \
  --name minha-app \
  -v /home/usuario/projeto:/var/www/html \
  -p 8080:80 \
  nginx:1.26

Neste caso, qualquer alteração feita em /home/usuario/projeto no host é refletida imediatamente dentro do container — ideal para desenvolvimento local onde você edita código e quer ver o resultado sem reconstruir a imagem.

Comparação prática entre as duas abordagens:

• Volume nomeado: gerenciado pelo Docker, armazenado em /var/lib/docker/volumes/, portável entre hosts com docker volume, recomendado para produção (bancos de dados, uploads, configurações críticas)
• Bind mount: caminho explícito no host, controle total sobre localização, dependente da estrutura de diretórios do servidor, preferido em desenvolvimento e CI/CD
• tmpfs mount: armazenamento em memória RAM, dados não persistem nem no host nem no volume, útil para dados sensíveis temporários como tokens e senhas em memória

Em ambientes de produção em VPS Linux, a recomendação é sempre usar volumes nomeados para dados críticos. Bind mounts em produção podem causar problemas de permissão quando o UID do processo dentro do container não corresponde ao proprietário do diretório no host.

Exemplo completo: aplicação com imagem, container e volume integrados

Para consolidar os três conceitos, veja um exemplo real de uma aplicação WordPress com banco de dados MySQL 8.0, usando volumes nomeados para persistência e uma rede Docker dedicada para isolamento:

Primeiro, crie a rede e os volumes:

docker network create rede-wordpress
docker volume create dados-mysql
docker volume create dados-wordpress

Inicie o container MySQL 8.0:

docker run -d \
  --name mysql-wp \
  --network rede-wordpress \
  -e MYSQL_ROOT_PASSWORD=rootSeguro456 \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=wpuser \
  -e MYSQL_PASSWORD=wpSeguro789 \
  -v dados-mysql:/var/lib/mysql \
  mysql:8.0

Inicie o container WordPress:

docker run -d \
  --name wordpress-app \
  --network rede-wordpress \
  -e WORDPRESS_DB_HOST=mysql-wp \
  -e WORDPRESS_DB_USER=wpuser \
  -e WORDPRESS_DB_PASSWORD=wpSeguro789 \
  -e WORDPRESS_DB_NAME=wordpress \
  -v dados-wordpress:/var/www/html \
  -p 8080:80 \
  wordpress:latest

Ao acessar http://ip-do-servidor:8080, você verá o instalador do WordPress. Os dados do banco ficam em dados-mysql e os arquivos do WordPress em dados-wordpress. Se precisar atualizar a imagem do WordPress, basta remover o container e recriar — os dados permanecem intactos nos volumes.

Para verificar que tudo está funcionando:

docker ps
docker volume ls
docker network ls

Se você usa Docker Compose para orquestrar múltiplos serviços, o conceito é o mesmo — imagens definem os serviços, containers são as instâncias em execução e volumes garantem a persistência. Consulte também o artigo Configurando um Servidor Linux para Hospedagem de Sites para entender como integrar Docker em um ambiente de hospedagem completo.

Gerenciamento e limpeza: comandos essenciais do dia a dia

O gerenciamento eficiente de recursos Docker evita que imagens antigas, containers parados e volumes órfãos consumam espaço em disco desnecessariamente. Em servidores VPS com armazenamento limitado, isso é especialmente crítico.

Para ver o espaço consumido por imagens, containers e volumes:

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          8         3         2.1GB     1.4GB (66%)
Containers      5         2         45MB      30MB (66%)
Local Volumes   4         2         890MB     200MB (22%)
Build Cache     12        0         340MB     340MB

Para limpeza completa de recursos não utilizados (imagens sem tag, containers parados, volumes órfãos e cache de build):

Atenção: o comando abaixo remove permanentemente todos os recursos Docker não associados a containers em execução. Execute apenas em ambientes onde você tem certeza do que está rodando.

docker system prune -a --volumes

Para remover apenas imagens sem tag (dangling images) que se acumulam após builds:

docker image prune

Para exportar um volume como backup antes de qualquer operação destrutiva:

docker run --rm \
  -v dados-mysql:/dados \
  -v $(pwd):/backup \
  ubuntu:24.04 \
  tar czf /backup/backup-mysql-$(date +%Y%m%d).tar.gz -C /dados .

Este comando cria um container temporário Ubuntu 24.04, monta o volume e o diretório atual do host, e gera um arquivo .tar.gz com timestamp. É uma prática recomendada antes de qualquer atualização de imagem em produção.

Problemas comuns e como resolver

Sintoma: dados perdidos após recriar o container

Causa: o container foi criado sem mapear um volume para o diretório de dados. Tudo que foi gravado ficou na camada de escrita do container, que foi descartada com docker rm.
Solução: sempre use -v nome-do-volume:/caminho/no/container ao criar containers que precisam persistir dados. Para recuperar dados de um container parado (não removido), use docker cp container-parado:/caminho/arquivo ./destino antes de removê-lo.

Sintoma: erro "permission denied" ao acessar bind mount

Causa: o processo dentro do container roda com um UID diferente do proprietário do diretório no host. Por exemplo, o Nginx roda como UID 101 dentro do container, mas o diretório no host pertence ao root (UID 0).
Solução: ajuste as permissões do diretório no host com chown -R 101:101 /caminho/no/host, ou use volumes nomeados em vez de bind mounts para evitar conflitos de UID em produção.

Sintoma: imagem não encontrada ao tentar criar container

Causa: a imagem não existe localmente e o Docker não conseguiu baixá-la do registry (Docker Hub ou registry privado). Pode ser erro de digitação na tag, imagem removida do registry ou falta de autenticação.
Solução: execute docker pull nome-da-imagem:tag explicitamente para ver a mensagem de erro completa. Verifique a ortografia da tag em hub.docker.com. Para registries privados, autentique com docker login registry.exemplo.com antes de fazer o pull.

Sintoma: volume não aparece após docker volume ls

Causa: o volume foi criado com um nome diferente do esperado, ou foi criado em um contexto de Docker Compose com prefixo automático (geralmente o nome do diretório do projeto).
Solução: use docker volume ls para listar todos os volumes e identificar o nome real. Em Docker Compose, o nome do volume segue o padrão nome-do-projeto_nome-do-volume. Inspecione com docker volume inspect nome-completo para confirmar o mountpoint.

Sintoma: espaço em disco esgotado por imagens e volumes acumulados

Causa: builds frequentes geram imagens intermediárias sem tag (dangling images) e o cache de build cresce indefinidamente. Volumes órfãos de containers removidos também ocupam espaço.
Solução: execute docker system df para identificar o que está consumindo espaço. Use docker image prune para remover imagens sem tag e docker volume prune para volumes não associados a nenhum container. Automatize a limpeza com um cron job semanal.

Perguntas frequentes sobre imagem, container e volume no Docker

Qual a diferença entre imagem e container no Docker?

Uma imagem Docker é um modelo somente leitura que contém o sistema de arquivos, dependências e instruções para criar um container. O container é a instância em execução dessa imagem — você pode criar múltiplos containers a partir de uma mesma imagem, cada um com seu próprio estado isolado. A imagem nunca muda; o container tem uma camada de escrita temporária que existe apenas durante seu ciclo de vida.

O que é um volume Docker e por que ele é necessário?

Um volume Docker é um mecanismo de armazenamento persistente gerenciado pelo próprio Docker, separado do sistema de arquivos do container. Ele é necessário porque dados gravados dentro de um container são perdidos quando o container é removido; volumes garantem que bancos de dados, uploads e configurações sobrevivam a reinicializações e recriações de containers. Sem volumes, qualquer operação de docker rm resulta em perda irreversível de dados.

Posso usar o mesmo volume em múltiplos containers simultaneamente?

Sim, um volume Docker pode ser montado em múltiplos containers ao mesmo tempo. Isso é útil para compartilhar arquivos entre serviços, como um container de aplicação e um container de backup. Porém, gravações simultâneas sem controle de concorrência podem causar corrupção de dados — use com cautela em cenários de escrita paralela e prefira soluções com lock de arquivo ou bancos de dados para coordenar acessos concorrentes.

Como faço para não perder dados ao recriar um container?

Sempre mapeie os diretórios críticos (banco de dados, uploads, configurações) para volumes nomeados ou bind mounts antes de criar o container. Com volumes nomeados, ao executar docker rm e recriar o container com o mesmo volume, os dados permanecem intactos. Nunca armazene dados persistentes dentro do sistema de arquivos do container — trate containers como efêmeros e descartáveis por design.

Qual a diferença entre bind mount e volume nomeado no Docker?

Um bind mount mapeia um diretório específico do host para dentro do container, dando controle total sobre o caminho no sistema de arquivos do servidor. Um volume nomeado é gerenciado pelo Docker em /var/lib/docker/volumes/ e é mais portável e seguro para produção. Bind mounts são preferidos em desenvolvimento pela facilidade de editar arquivos diretamente no host; volumes nomeados são recomendados em produção pela melhor integração com ferramentas de backup e menor risco de conflitos de permissão.

Conclusão

• Use imagens versionadas com tags explícitas (ex: nginx:1.26, postgres:16) em vez de latest em produção — isso garante reprodutibilidade e facilita rollback
• Sempre crie volumes nomeados para dados críticos antes de subir containers em produção — bancos de dados, uploads e configurações nunca devem depender da camada de escrita do container
• Automatize a limpeza de recursos Docker com docker system prune em cron jobs semanais e faça backup de volumes com docker run --rm antes de qualquer atualização de imagem

Leia também

• Entenda o Checklist de Segurança do Docker antes de ir ao ar
• configurar rede Docker para isolar serviços no VPS
• Comparativo: Docker vs Podman para servidores Linux em 2026

Precisa de ajuda com Docker no seu servidor?

Rodar containers Docker em produção exige um servidor com recursos adequados de CPU, memória e armazenamento. Um VPS Linux bem configurado oferece o ambiente ideal para hospedar aplicações containerizadas com isolamento, controle total e escalabilidade conforme a demanda cresce.

Conheça os planos de VPS Linux da AviraHost e comece a usar Docker em produção