Imagem e contêiner Docker: diferença, ciclo e comandos

Uma imagem Docker é o pacote imutável com arquivos, configuração e runtime; um contêiner é um processo isolado iniciado a partir desse pacote. Nesta lição você vai baixar uma imagem, criar um contêiner, observar suas mudanças e resolver um conflito de nome reproduzido no Docker 29.5.3.

Antes de continuar, confirme a instalação com a lição instalar Docker. Aqui a gente parte do ponto em que docker version já mostra cliente e servidor.

O roteiro guardado e a apresentação acontecendo

Imagine uma peça de teatro. O roteiro, o cenário planejado e a lista de objetos formam um pacote que pode ser usado em várias apresentações. Esse pacote é a imagem. Cada apresentação com atores no palco é um contêiner: começa, executa e termina independentemente das outras.

O mapeamento ajuda a separar molde de execução, mas tem limite. Tecnicamente a imagem não guarda só instruções; ela contém um sistema de arquivos em camadas e metadados como comando padrão. O contêiner não é uma cópia de computador: é um processo isolado que enxerga as camadas da imagem e recebe uma camada gravável própria.

Por isso uma imagem pode originar cem contêineres sem virar cem imagens. E por isso editar um arquivo dentro de um contêiner não altera o pacote original nem os outros contêineres.

Baixar não é executar

docker pull busca a imagem no registro e a armazena localmente. Ele não cria um processo:

docker pull node:24-alpine

Leia node:24-alpine em duas partes. node é o repositório; 24-alpine é a tag. A tag é um nome móvel. O digest sha256:... identifica o conteúdo obtido naquele teste com muito mais precisão.

Inspecione dois metadados do pacote:

docker image inspect node:24-alpine --format 'ID curto: {{printf "%.19s" .Id}} | arquitetura: {{.Architecture}}'

Nesta máquina o Docker escolheu a variante ARM64. Num computador Intel, a mesma tag normalmente baixa a variante AMD64. Um manifesto multi-plataforma permite usar o mesmo nome, mas o binário de cada arquitetura continua diferente.

Camadas são partes reutilizáveis da imagem

Imagens são formadas por camadas somente leitura. Cada mudança feita durante o build acrescenta outra camada; imagens podem reutilizar partes iguais. Veja as quatro entradas superiores de node:24-alpine:

docker image history node:24-alpine --format '{{.CreatedBy}} | {{.Size}}' | head -4

history não reconstrói toda a receita original, mas mostra a ordem e o custo das camadas. Essa ordem vai importar quando a gente escrever um Dockerfile para Node.

docker run cria e inicia um contêiner

Agora há execução. Tudo depois do nome da imagem é o comando dentro do contêiner:

docker run --rm node:24-alpine node -e "console.log('Node do pacote:', process.version)"

docker run reúne duas ações: docker create e docker start. --rm pede a remoção automática quando o processo termina. Sem --rm, o contêiner parado continua no inventário.

Para observar um contêiner em execução, inicie um processo que mantém a fila da cantina aberta:

docker run -d --name dc-aula-processo node:24-alpine node -e "console.log('fila aberta'); setInterval(()=>{}, 1000)"

-d significa detached, ou segundo plano. O texto devolvido é o ID do novo contêiner. --name adiciona um identificador humano sem substituir esse ID.

Confira o estado com colunas escolhidas por você:

docker ps --filter name=dc-aula-processo --format 'Nome={{.Names}} | Imagem={{.Image}} | Estado={{.State}}'

docker ps mostra apenas os que estão rodando. O filtro evita confundir a aula com outros projetos da máquina.

Logs e exec observam coisas diferentes

docker logs lê o que o processo principal escreveu em saída padrão e saída de erro:

docker logs dc-aula-processo

docker exec inicia outro processo dentro do contêiner que já está rodando:

docker exec dc-aula-processo node -e "console.log('processo extra:', process.pid)"

O PID diferente comprova que exec não entra magicamente no processo principal; ele cria um processo adicional com o mesmo sistema de arquivos e a mesma rede. Use logs primeiro para diagnosticar. Use exec quando você precisar fazer uma inspeção que os logs não respondem.

A camada gravável pertence ao contêiner

Crie um segundo contêiner que grava um recibo e permanece ativo:

docker run -d --name dc-aula-camada node:24-alpine node -e "require('node:fs').writeFileSync('/tmp/recibo.txt','pedido 42'); setInterval(()=>{},1000)"
docker diff dc-aula-camada

A indica arquivo adicionado e C, diretório alterado. Essas mudanças estão na camada gravável de dc-aula-camada, não em node:24-alpine. Remover o contêiner remove essa camada. Dados que precisam sobreviver pertencem a um volume Docker, assunto da quarta lição.

Parar não significa remover

Pare o processo principal e procure também entre os contêineres encerrados:

docker stop dc-aula-processo
docker ps -a --filter name=dc-aula-processo --format 'Nome={{.Names}} | Estado={{.State}} | Status={{.Status}}'

O tempo no seu terminal será outro. A regra observável é Estado=exited: o processo acabou, mas o objeto contêiner ainda existe com nome, configuração e camada gravável.

Erro real: o nome continua ocupado

Tente criar outro contêiner com o mesmo nome antes de remover o anterior:

docker run --name dc-aula-processo node:24-alpine node --version

O termo é name conflict. Em palavras simples, a etiqueta continua colada ao contêiner parado. docker stop não libera nome; docker rm libera:

docker rm dc-aula-processo
docker rm -f dc-aula-camada

-f encerra e remove, por isso exige atenção. Em scripts descartáveis, prefira --rm no docker run. Em serviços que você pretende reiniciar, mantenha o contêiner e use docker start.

Missão: duas execuções, uma imagem

Inicie dois contêineres de node:24-alpine com nomes turno-manha e turno-tarde. Em cada um, imprima um texto diferente e mantenha o processo ativo. O critério de sucesso tem três partes: docker ps mostra dois nomes e a mesma imagem; docker logs mostra a mensagem correta de cada turno; remover um não encerra o outro.

Finalize removendo apenas os dois contêineres da missão. A imagem deve continuar visível em docker image ls node. Quando você consegue prever qual objeto cada comando afeta, imagem e contêiner deixam de parecer dois nomes para a mesma coisa. O próximo passo é transformar código seu em imagem, seguindo a sequência da trilha Docker.