DevOpsQuest
0 XP
Módulo 4 · Docker e Compose

Imagens, containers e o modelo mental correto

Iniciante 40 min+25 XPDocker

Objetivos desta aula

  • Distinguir imagem, container e registry
  • Operar o ciclo de vida do container
  • Inspecionar o que está rodando

Imagem é um modelo somente-leitura, formado por layers empilhados; container é uma instância em execução desse modelo, com uma camada de escrita própria e efêmera. Registry é onde as imagens ficam guardadas (Docker Hub, GHCR, ECR). Entender isso explica por que dado gravado dentro do container desaparece ao recriá-lo — e por que volumes existem.

Container não é máquina virtual: ele compartilha o kernel do host e isola processos por namespaces e cgroups. Isso o torna leve e rápido, mas também significa que ele não é fronteira de segurança perfeita — daí a importância de não rodar como root e de limitar recursos.

O container vive enquanto seu processo principal (PID 1) vive. Se o processo termina, o container para. Esse é o motivo de tantos containers que 'não sobem': o comando terminou, com sucesso ou com erro, e o Docker apenas obedeceu.

1. Container não é máquina virtual

Uma VM emula hardware e roda um kernel inteiro. Um container é só um processo Linux isolado que compartilha o kernel do host. O isolamento vem de dois recursos do kernel: namespaces (o que o processo enxerga: PIDs, rede, filesystem, hostname) e cgroups (quanto ele pode usar: CPU, memória, I/O). Por isso um container sobe em milissegundos.

2. Imagem vs container

A imagem é um modelo somente leitura, feito de camadas empilhadas. O container é uma instância em execução dessa imagem, com uma camada gravável por cima. Apagou o container? A camada gravável some junto. Por isso dados importantes vão para volumes.

3. Um processo principal por container

O container vive enquanto o processo PID 1 vive. Se o comando principal termina, o container para. Rodar vários serviços num container só (API + banco + cron) quebra esse modelo, dificulta logs e escalonamento.

4. Ciclo de vida na prática

docker run cria e inicia; docker ps lista; docker logs -f acompanha a saída; docker exec -it abre um shell dentro; docker stop envia SIGTERM e, após 10s, SIGKILL; docker rm remove. Sua aplicação deve tratar SIGTERM para encerrar sem perder requisições.

5. Tags e digests

node:20 é uma tag móvel: amanhã pode apontar para outra imagem. O digest (node@sha256:...) é imutável. Em produção, fixe versões específicas e registre o digest do que foi publicado.

6. Checagem final

Você deve explicar namespaces e cgroups, dizer por que dados não ficam no container e mostrar como inspecionar um container em execução.

Na prática

Ciclo de vida e inspeção

bash

docker run -d --name api -p 3000:3000 node:22-alpine sleep 3600
docker ps
docker ps -a                       # inclui parados
docker logs -f api
docker exec -it api sh             # entrar no container
docker inspect api | jq '.[0].State, .[0].NetworkSettings.IPAddress'
docker stats --no-stream
docker stop api && docker rm api
docker image ls && docker system df
docker system prune -f             # limpar recursos nao usados

Nota de segurança: docker exec com --user root em produção deve ser exceção auditada; prefira depurar por logs e métricas.

Explorar um container por dentro

bash

docker run -d --name web -p 8080:80 --memory 256m nginx:1.27-alpine
docker ps                                # STATUS Up ...
docker logs -f web                       # saida do processo principal
docker exec -it web sh -c 'ps aux'       # PID 1 e o nginx master
docker inspect web --format '{{.State.Pid}} {{.HostConfig.Memory}}'
docker stats --no-stream web             # CPU e memoria usados (cgroups)
docker stop web && docker rm web

Por que isso importa

Todo o resto (CI/CD, Kubernetes, GitOps) assume que você entende container. Modelo mental errado aqui contamina tudo.

Erro comum

Guardar dados importantes na camada de escrita do container e perdê-los no próximo deploy.

Dica de produção

Trate containers como descartáveis: nada essencial dentro, tudo em volume ou serviço externo.

Pergunta de entrevista

Por que um container para imediatamente após iniciar?

Glossário

layer
Camada imutável da imagem, reaproveitada em cache e entre imagens.
cgroups
Mecanismo do kernel que limita CPU, memória e I/O de um grupo de processos.
namespace
Recurso do kernel que isola o que um processo enxerga (PIDs, rede, montagem).
cgroup
Recurso do kernel que limita e mede CPU, memória e I/O de processos.
digest
Hash sha256 que identifica uma imagem de forma imutável.
PID 1
Processo principal do container; quando termina, o container para.

Conexão com o CloudShop

Rodar a API do CloudShop em container pela primeira vez.

Quiz da aula

  1. 1. O que acontece com os dados escritos dentro do container ao removê-lo?

  2. 2. O que um container compartilha com o host?

  3. 3. Por que usar digest em produção?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima