Docker: diferença entre imagem, container e engine

A diferença em três frases

A imagem do Docker é o pacote pronto e imutável que você baixa de um registry, identificado por nome mais tag. O container é um processo em execução iniciado a partir dessa imagem, com uma camada de arquivos só dele. O Docker Engine é o serviço que roda no servidor e cria as duas coisas.

Quem está começando ouve as três palavras usadas como sinônimos e trava aí. O teste rápido é este: imagem é arquivo no disco, container é processo em execução, Engine é o serviço que cria e destrói containers. Quem programa pode pensar em classe e objeto: a imagem é a classe, o container é uma instância dela.

O resto deste guia mostra o mesmo ciclo duas vezes, com comandos que você pode rodar agora no seu servidor, para que a diferença apareça na saída do terminal em vez de ficar só na definição.

A imagem: o artefato que você versiona

Uma imagem é um sistema de arquivos empacotado em camadas, mais um pouco de metadado que diz qual comando executar quando ela virar container. Ela é somente leitura. Nada do que acontece dentro de um container modifica a imagem que o originou, e é por isso que dois containers podem sair da mesma imagem sem interferir um no outro.

Uma imagem é endereçada por nome e tag, no formato repositório:tag. Baixe uma e veja o que ficou no disco:

docker pull nginx:alpine
docker images

docker images lista as imagens que estão na máquina. Olhe as colunas REPOSITORY e TAG: juntas, elas formam o nome pelo qual você vai pedir essa imagem depois. A coluna IMAGE ID é o identificador real da imagem, e a coluna SIZE mostra o espaço que ela ocupa, sem descontar as camadas que ela compartilha com outras imagens da mesma base.

A tag não é um número de versão congelado. Ela é um apontador que o mantenedor pode mover no registry. nginx:alpine hoje e nginx:alpine daqui a três meses podem ser imagens diferentes, porque a tag foi republicada apontando para um conteúdo novo. Isso importa na prática, porque atualizar um serviço em container quase sempre é um docker pull da mesma tag seguido da recriação do container. Se você precisa travar exatamente o mesmo conteúdo, use uma tag de versão específica, ou o digest, que é o hash do conteúdo e nunca muda:

docker image inspect nginx:alpine

Na saída desse comando, procure o campo RepoDigests. É ele que identifica a imagem de forma permanente, e é ele que você anota quando quer poder voltar para a mesma imagem daqui a um ano.

O container: um processo com sistema de arquivos próprio

Um container é um processo, ou uma árvore de processos, iniciado a partir de uma imagem. O Engine cria esse processo dentro de namespaces, que são o mecanismo do kernel Linux que dá ao processo uma visão isolada de processos, rede e pontos de montagem, e aplica cgroups (control groups), que limitam quanta CPU e memória ele pode consumir.

docker run -d --name web1 nginx:alpine
docker ps

docker ps deve listar web1 com a coluna STATUS indicando que ele está de pé, e a coluna IMAGE mostrando de qual imagem ele saiu. Se a linha não aparecer, rode docker ps -a, que mostra também os containers parados, e em seguida docker logs web1 para ler por que o processo terminou.

Além do processo, o container ganha uma camada de escrita própria, empilhada sobre as camadas somente leitura da imagem. Tudo que ele grava vai para essa camada. Entre nele e crie um arquivo qualquer:

docker exec -it web1 sh
echo teste > /tmp/teste.txt
exit

Esse arquivo existe apenas naquele container. Ele não entra na imagem, e desaparece junto com o container quando você o remove. É por isso que dados que precisam sobreviver, como banco de dados, uploads e configuração gerada, moram em volumes e não na camada de escrita: a diferença entre bind mounts e volumes nomeados é o passo natural depois deste guia.

O mesmo ciclo, duas vezes

Suba um segundo container a partir da mesma imagem. Ele precisa de outro nome, porque nomes de container são únicos dentro da máquina:

docker run -d --name web2 nginx:alpine
docker ps
docker images

Agora docker ps lista dois containers, e docker images continua listando uma única linha para nginx:alpine. Os dois containers compartilham as mesmas camadas de imagem no disco, então subir o segundo custou pouco mais que a camada de escrita dele. Essa é a razão prática de containers serem baratos de criar.

Remova um deles e confira o que sobrou:

docker rm -f web2
docker ps -a
docker images

O container web2 sumiu da lista, inclusive da lista com -a, que mostra os parados. A imagem nginx:alpine continua exatamente onde estava. Esse é o ponto central deste guia: o container é descartável e a imagem é o artefato. Você pode apagar e recriar containers o dia inteiro sem perder nada, desde que os dados estejam em volumes.

Agora feche o ciclo. Tente apagar a imagem com o primeiro container ainda existindo:

docker rmi nginx:alpine

O Docker recusa a remoção e avisa que a imagem ainda está em uso por um container. Isso vale mesmo se o container estiver parado, porque um container guarda uma referência à imagem que o criou durante toda a sua existência, e não apenas enquanto roda. Remova o container primeiro e a remoção da imagem passa:

docker rm -f web1
docker rmi nginx:alpine
docker images

Depois disso docker images não lista mais nginx:alpine, e o próximo docker run nginx:alpine baixa a imagem de novo antes de subir o container. Você nunca é obrigado a rodar docker pull antes: docker run busca a imagem sozinho quando ela não está no disco local. O pull separado serve para baixar com antecedência, escolher o momento em que a rede é usada, e acompanhar o download.

Docker Engine: o daemon que faz o trabalho

O comando docker que você digita é apenas um cliente. Ele não cria container nenhum. Ele envia uma requisição para o Docker Engine, um daemon (processo que fica rodando em segundo plano) chamado dockerd, por um socket local em /var/run/docker.sock. O dockerd conversa com o containerd, que conversa com o runc, e é o runc que finalmente pede ao kernel os namespaces e cgroups do novo processo.

systemctl status docker
docker info

docker info deve responder com dados do servidor, como a versão do Engine e o driver de armazenamento em uso. Se em vez disso o comando reclamar que não conseguiu se conectar ao daemon, a causa é uma destas duas: o serviço docker está parado, ou o seu usuário não tem permissão no socket. Esse é o erro mais comum logo depois da instalação, e ele existe justamente porque o cliente e o Engine são programas separados. A instalação e o ajuste dessa permissão estão em como instalar e configurar o Docker num VPS.

O Engine também é a resposta para a dúvida sobre licença. O Docker Engine é software livre e roda sem conta e sem pagamento. O Docker Desktop e algumas funções do Docker Hub seguem regras próprias, e o que é gratuito no Docker e o que não é separa os dois casos. Se ter um daemon rodando como root te incomoda, o Podman executa os mesmos containers sem daemon e aceita quase a mesma linha de comando.

Por que um container não é uma máquina virtual

Uma máquina virtual carrega um kernel próprio. O hypervisor apresenta hardware virtual, o sistema convidado inicializa esse kernel, e você passa a ter um segundo sistema operacional completo, com memória reservada desde o boot.

Um container não tem kernel próprio. Ele usa o kernel do seu VPS, e o que o isola são recursos desse mesmo kernel: namespaces para separar a visão do sistema, cgroups para limitar recursos. A imagem carrega apenas a parte de cima, ou seja, as bibliotecas e os binários que o programa precisa.

A consequência prática é direta. Um container inicia na velocidade de um processo, não na de um boot, e ocupa memória conforme trabalha. Um VPS pequeno segura uma dúzia de containers ociosos com folga, enquanto a mesma máquina não aguentaria três máquinas virtuais. Quando um container específico começa a consumir memória demais, o limite é declarado na configuração dele, e definir limites de memória por container mostra como.

A outra consequência é o limite do modelo. Como o kernel é compartilhado, um container Linux precisa de um host Linux, e nada dentro dele carrega módulo de kernel ou roda um kernel diferente do que a máquina já tem. Isolamento de container é isolamento de processo com regras fortes, e essa fronteira é mais fina que a de uma máquina virtual. Para rodar código de terceiros em que você não confia, no mesmo servidor, essa diferença pesa.

Docker Hub é um registry, não o Docker

Registry é o serviço que guarda e entrega imagens. O Docker Hub é um registry, e é o padrão do cliente: quando você escreve docker pull nginx:alpine sem mais nada, o Docker completa o endereço com docker.io/library/ na frente. O Hub guarda imagens. Ele não executa nada, e não é o programa instalado no seu servidor.

Existem outros registries, e você usa qualquer um deles escrevendo o endereço completo, no formato registry/organização/repositório:tag:

docker pull ghcr.io/<organização>/<imagem>:<tag>

ghcr.io é o registry do GitHub e quay.io é o da Red Hat. Você também pode hospedar um registry privado no seu próprio VPS. Vale saber que o Docker Hub aplica limite de taxa para downloads anônimos (situação de setembro de 2026), e que autenticar com docker login, mesmo em conta gratuita, eleva esse limite. Um servidor de build que puxa imagens o tempo todo esbarra nisso mais cedo do que se espera.

O que essa distinção muda no seu VPS

Uma imagem serve vários containers. Rodar três instâncias do mesmo serviço em portas diferentes custa três camadas de escrita, e não três cópias do software no disco. Em um servidor alugado, onde o disco é a parte mais cara do plano, isso muda o que cabe na máquina.

A imagem é a unidade que você versiona. Atualizar um serviço não é entrar no container e rodar apt upgrade, porque essa mudança fica na camada de escrita e desaparece na primeira recriação. Atualizar é puxar a imagem nova e recriar o container a partir dela, o que também explica por que reiniciar um container não é o mesmo que recriá-lo.

Imagens antigas não somem sozinhas. Depois de alguns meses de docker pull, o disco acumula camadas que nenhum container usa, e o espaço desaparece sem explicação óbvia: limpar imagens e camadas órfãs com docker system prune resolve isso em um comando.

Quando as linhas de docker run ficarem longas demais para digitar de memória, o passo seguinte é escrever tudo em um arquivo. descrever seus containers em um docker-compose.yml guarda imagem, portas, volumes e variáveis de ambiente de cada serviço em texto que você versiona junto com o resto do projeto.

FAQ

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

A imagem é um pacote somente leitura guardado no disco, formado por camadas de sistema de arquivos mais o metadado que diz qual comando rodar. O container é um processo em execução criado a partir dessa imagem, com uma camada de escrita própria por cima. Uma imagem pode gerar quantos containers você quiser, e todos compartilham as mesmas camadas de leitura. Rode docker images para ver as imagens e docker ps -a para ver os containers: são duas listas diferentes, com comandos diferentes para apagar cada uma.

Se eu apagar o container, perco a imagem?

Não. docker rm remove o container e a camada de escrita dele, e a imagem continua listada em docker images. Para remover a imagem é preciso outro comando, docker rmi, e ele falha enquanto existir qualquer container criado a partir dessa imagem, mesmo um container parado. O que você perde ao apagar um container são os arquivos gravados dentro dele que não estavam em um volume.

Container é a mesma coisa que máquina virtual?

Não. Uma máquina virtual roda um kernel próprio sobre hardware emulado, então cada VM é um sistema operacional completo com memória reservada. Um container compartilha o kernel do servidor e é isolado por namespaces e cgroups, recursos do próprio kernel. Por isso ele inicia em fração de segundo e um VPS pequeno consegue segurar vários. O outro lado é que um container Linux exige um host Linux e não pode carregar módulos de kernel.

Docker Hub, Docker Engine e Docker Desktop são a mesma coisa?

Não. O Docker Engine é o daemon que constrói e executa containers no servidor, e é o que você instala em um VPS. O Docker Hub é um registry, ou seja, o serviço na internet que guarda e entrega imagens, usado como padrão quando você escreve um nome de imagem sem endereço. O Docker Desktop é um aplicativo de desktop para Windows e macOS que roda o Engine dentro de uma máquina virtual, e não é usado em servidor Linux.