Docker, Docker Compose e Kubernetes

Do zero

Antes dos contêineres de navio, cada carga tinha um formato: sacos, caixas, barris. Carregar um navio era lento e cada porto fazia de um jeito. O contêiner padronizou tudo: não importa o que vai dentro, ele encaixa em qualquer navio, trem ou caminhão.

Em software, o container faz o mesmo: empacota a aplicação com tudo de que ela precisa (bibliotecas, configurações, ambiente de execução) e roda igual no notebook do desenvolvedor, no servidor de homologação e na nuvem. Acaba o “na minha máquina funciona”.

• O Docker é a ferramenta mais conhecida para criar e rodar containers. A receita do container é o Dockerfile; o resultado da receita é a imagem (o molde); cada cópia em execução da imagem é um container.
• O Docker Compose sobe vários containers que trabalham juntos (o portal, o banco, o cache) com um único arquivo.
• O Kubernetes é o gerente do porto: com centenas de containers em dezenas de servidores, ele decide onde cada um roda, reinicia os que caem, aumenta as cópias no pico e troca as versões sem tirar o sistema do ar.

Frase para guardar: Dockerfile é a receita, imagem é o molde, container é o bolo; o Compose junta vários; o Kubernetes orquestra muitos.

Em 1 minuto

• Container × máquina virtual: o container compartilha o kernel do sistema hospedeiro e isola processos, sistema de arquivos e rede com recursos desse kernel, os namespaces e os cgroups (por isso é leve e sobe em segundos); a máquina virtual tem um sistema operacional completo sobre um hipervisor.
• Dockerfile: FROM (imagem base), WORKDIR, COPY, RUN (executa durante o build), ENV, EXPOSE (documenta a porta), USER e CMD ou ENTRYPOINT (o que roda quando o container inicia).
• Imagens são feitas de camadas imutáveis e ficam num registro (como o Docker Hub). Dados que precisam durar vão em volumes.
• Docker Compose: arquivo compose.yaml com serviços, redes e volumes; docker compose up sobe tudo.
• Kubernetes: Pod (menor unidade, com um ou mais containers), Deployment (mantém N réplicas e faz atualizações graduais), Service (endereço estável e balanceamento), Ingress (entrada HTTP), ConfigMap e Secret (configuração e segredos).

Exemplo concreto: o portal em containers

Dockerfile do portal:

# Imagem base pequena
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
# RUN roda durante o build da imagem
RUN npm ci --omit=dev
COPY . .
# Não roda como root
USER node
# Documenta a porta; não a publica
EXPOSE 3000
# CMD roda quando o container inicia
CMD ["node", "servidor.js"]

(No Dockerfile, comentário só vale em linha própria, começando com #.)

Para rodar: docker build -t portal:1.4 . cria a imagem; docker run -p 8080:3000 portal:1.4 cria um container e publica a porta 3000 do container na porta 8080 da máquina.

compose.yaml, com o portal e o banco:

services:
  portal:
    image: portal:1.4
    ports: ["8080:3000"]
    depends_on: [banco]
  banco:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/senha_banco
    secrets: [senha_banco]
    volumes: ["dados:/var/lib/postgresql/data"]
volumes:
  dados:
secrets:
  senha_banco:
    file: ./senha_banco.txt   # fora do Git

Kubernetes, com três réplicas do portal:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal
spec:
  replicas: 3
  selector:
    matchLabels: { app: portal }
  template:
    metadata:
      labels: { app: portal }
    spec:
      containers:
        - name: portal
          image: registro.tce.local/portal:1.4
          ports: [{ containerPort: 3000 }]

Aplicado com kubectl apply -f portal.yaml, o Kubernetes cria os Pods e, se um cair, cria outro para manter as três réplicas. Um Service dá um endereço único para os três Pods e distribui as requisições entre eles.

Comparação: VM, container, Compose e Kubernetes

O plano de controle do cluster (API server, etcd, scheduler e controladores) decide e guarda o estado; nos nós, o kubelet roda os containers.

Como a FCC cobra

• Container × VM (kernel compartilhado).
• Instruções do Dockerfile e o que cada uma faz.
• Para que serve o Docker Compose.
• Pod, Deployment, Service, Ingress, ConfigMap e Secret.
• Autorreparo e escalonamento no Kubernetes.

Pegadinhas

Explique com suas palavras

Explique a um colega a diferença entre imagem, container, Docker Compose e Kubernetes, usando uma analogia sua.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

A imagem é como a fôrma e a receita de um bolo: define tudo o que vai dentro e não muda. O container é cada bolo feito com aquela fôrma, rodando de verdade. Dá para fazer vários bolos iguais com a mesma fôrma.

O Docker Compose é a lista do jantar: diz quais pratos sobem juntos (o portal, o banco, o cache) e como se ligam, numa mesma cozinha. O Kubernetes é o gerente de um restaurante com várias cozinhas: decide em qual cozinha cada prato é feito, refaz o prato que caiu no chão e aumenta a produção quando o restaurante enche.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso de API em containers na nuvem, proponha: imagem mínima, sem rodar como root e sem segredos dentro dela; varredura da imagem no pipeline; Kubernetes com várias réplicas, atualização gradual e escalonamento automático; segredos em Secret (com cifragem em repouso) ou num cofre; e banco com volume persistente e backup.

Fontes da lição

• Edital nº 01/2026, Anexo II, DevOps, Plataforma de Desenvolvimento e Engenharia de Entrega (fontes/edital-01-2026.txt).
• Referência do Dockerfile
• Documentação do Docker Compose
• Conceitos do Kubernetes