Contêineres

O serviço inventory funciona no notebook da Ana com Java 21.0.4 e falha no do Bruno com Java 17; o servidor de staging está em outro fuso horário; a produção tem uma libc mais antiga. Cada ambiente é uma máquina ligeiramente diferente, e cada diferença é um bug esperando um deploy. Um container empacota a aplicação junto com tudo de que ela precisa para rodar — runtime, bibliotecas, configurações padrão — em um único artefato imutável que se comporta da mesma forma em um notebook, na CI e em um cluster Kubernetes.

Containers são processos, não VMs pequenas

Uma máquina virtual (VM) emula hardware: cada VM inicializa o próprio kernel sobre um hipervisor. Um container é um processo Linux comum que o kernel isola e limita. Todos os containers de um host compartilham o kernel do host.

flowchart TB
    subgraph VMs["Máquinas virtuais"]
        direction TB
        hw1["Hardware"] --> hv["Hipervisor"]
        hv --> g1["Kernel do SO convidado"] --> a1["catalog"]
        hv --> g2["Kernel do SO convidado"] --> a2["inventory"]
    end
    subgraph CT["Containers"]
        direction TB
        hw2["Hardware"] --> k["Kernel do SO hospedeiro<br/>namespaces + cgroups"]
        k --> c1["catalog<br/>(processo)"]
        k --> c2["inventory<br/>(processo)"]
    end

Dois recursos do kernel fazem o trabalho⁴:

Como o isolamento é mais fraco, provedores de nuvem que executam containers de outros clientes em hosts compartilhados os envolvem em VMs leves (AWS Firecracker sob o Lambda e o Fargate, gVisor sob o Google Cloud Run). Para os seus serviços nos seus nós, containers comuns são a norma.

O que é uma imagem

Uma imagem é um modelo somente leitura a partir do qual containers são iniciados. A Open Container Initiative (OCI) padroniza seu formato, de modo que uma imagem construída com Docker roda em containerd, CRI-O ou Podman¹. Uma imagem OCI é:

• uma lista de camadas (layers) — arquivos tar comprimidos, cada um com as mudanças no sistema de arquivos de um passo do build;
• uma config — variáveis de ambiente, o comando padrão, o usuário, as portas expostas;
• um manifest que lista a config e as camadas por seus digests (hashes SHA-256 do conteúdo).

flowchart LR
    m["Manifest<br/>sha256:9f2c…"] --> cfg["Config<br/>ENTRYPOINT, USER, ENV"]
    m --> l1["Camada 1: arquivos do SO base<br/>(distroless / Alpine)"]
    m --> l2["Camada 2: runtime Java"]
    m --> l3["Camada 3: dependências (jars)"]
    m --> l4["Camada 4: classes da aplicação"]

As camadas são endereçadas por conteúdo e compartilhadas: dez serviços do BoxOffice construídos sobre a mesma imagem base armazenam e baixam as camadas base uma única vez. Quando um container inicia, o runtime empilha as camadas somente leitura com um sistema de arquivos overlay e adiciona por cima uma fina camada gravável — que desaparece com o container. Por isso o estado precisa viver em volumes ou em serviços de apoio.

Tags se movem, digests não

boxoffice/inventory:1.8.3 é uma tag: um ponteiro amigável que qualquer pessoa com permissão de push pode mover para outra imagem. boxoffice/inventory@sha256:9f2c… é um digest: identifica exatamente um conteúdo. Deploys de produção devem referenciar digests (ou tags imutáveis garantidas pelo registry), para que "a imagem que testamos" seja comprovadamente "a imagem que executamos".

Um Dockerfile de produção para um serviço do BoxOffice

O serviço catalog é uma aplicação Spring Boot 4 em Java 21. Um Dockerfile ingênuo copia o código-fonte e executa o Maven dentro da imagem final — produzindo uma imagem grande que contém o compilador, o cache do Maven e o código-fonte. Um build multi-stage compila em um estágio e copia apenas o resultado para um estágio de execução mínimo²:

# ---- build stage: JDK + Maven, discarded at the end ----
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
# 1. dependencies first: this layer is cached until pom.xml changes
COPY pom.xml .
RUN mvn -q dependency:go-offline
# 2. then the source code, which changes on every commit
COPY src ./src
RUN mvn -q package -DskipTests \
 && java -Djarmode=tools -jar target/catalog.jar extract --layers --launcher --destination target/extracted

# ---- runtime stage: only a JRE, no shell, non-root ----
FROM gcr.io/distroless/java21-debian12:nonroot
WORKDIR /app
# Spring Boot layers: rarely-changing first, application classes last
COPY --from=build /src/target/extracted/dependencies/ ./
COPY --from=build /src/target/extracted/spring-boot-loader/ ./
COPY --from=build /src/target/extracted/snapshot-dependencies/ ./
COPY --from=build /src/target/extracted/application/ ./
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
EXPOSE 8080
USER nonroot
ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Cada linha tem um motivo:

Adicione um .dockerignore (com target/, .git/, *.log, .env) para que o contexto de build enviado ao builder fique pequeno e segredos não vazem para as camadas.

docker build -t boxoffice/catalog:1.4.0 catalog/
docker image ls boxoffice/catalog            # check the size
docker run --rm -p 8080:8080 --memory=512m --cpus=1 \
  -e SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/catalog boxoffice/catalog:1.4.0

# syntax=docker/dockerfile:1

# ---- build stage: compile with Maven inside a JDK image -------------------
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom.xml .
COPY src ./src
# the cache mount keeps ~/.m2 between builds: dependencies are downloaded once
RUN --mount=type=cache,target=/root/.m2 mvn -B -q package -DskipTests

# ---- runtime stage: only a JRE and the jar --------------------------------
FROM eclipse-temurin:21-jre
WORKDIR /app
RUN useradd --system --uid 10001 app
COPY --from=build /src/target/app.jar app.jar
USER app
EXPOSE 8082
# use up to 75% of the container's memory limit for the heap
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]

Encerramento gracioso: a outra metade da descartabilidade

Quando o Kubernetes substitui um pod, ele envia SIGTERM, espera terminationGracePeriodSeconds (30 s por padrão) e então envia SIGKILL. Um serviço que morre instantaneamente derruba todas as requisições em andamento — inclusive o pagamento de alguém. O Spring Boot resolve isso com duas propriedades:

server:
  shutdown: graceful            # stop accepting, finish in-flight requests
spring:
  lifecycle:
    timeout-per-shutdown-phase: 20s

Registries e a cadeia de suprimentos

As imagens ficam guardadas em um registry (Docker Hub, GitHub Container Registry, Amazon ECR, Google Artifact Registry, Harbor). Como uma imagem é tudo o que vai rodar em produção, o caminho do código-fonte até o registry — a cadeia de suprimentos de software — é um alvo de ataque. A higiene mínima do pipeline do BoxOffice⁵:

A aula de Rede e segurança discute a segurança da cadeia de suprimentos em profundidade; a página de Entrega conecta esses passos ao pipeline de CI.

Docker Compose: o sistema inteiro em uma máquina

O Compose descreve uma aplicação com vários containers em um único arquivo YAML. Para o BoxOffice, ele é o ambiente local de desenvolvimento e testes, não a plataforma de produção:

services:
  catalog:
    build: ./catalog
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/boxoffice
      SPRING_DATA_REDIS_HOST: redis
    depends_on:
      db: { condition: service_healthy }
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 512M }
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: boxoffice
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10
    volumes: [ "pgdata:/var/lib/postgresql/data" ]
  redis:
    image: redis:8-alpine
volumes:
  pgdata: {}

Os serviços se encontram pelo nome do serviço (db, redis) por meio do DNS interno do Compose — nunca por localhost, que dentro de um container significa o próprio container. O Compose não tem escalonamento entre vários hosts, nem autorrecuperação entre máquinas, nem rolling updates; quando você precisa disso, precisa de um orquestrador — o assunto da próxima página.

Trade-offs

Como se conecta

flowchart LR
    NS["namespaces + cgroups"] --> CT["container =<br/>processo isolado"]
    IMG["imagem OCI: camadas,<br/>config, manifest"] --> CT
    IMG --> DIG["digest, não tag:<br/>build uma vez, promova"]
    DIG --> DEL["CI e GitOps<br/>→ Entrega"]
    IMG --> SC["scan, SBOM, assinatura<br/>→ Redes e segurança"]
    CT --> MEM["limite de memória → OOMKilled<br/>JVM MaxRAMPercentage"]
    CT --> SIG["SIGTERM, desligamento gracioso<br/>→ rolling updates seguros"]
    MEM --> K8S["pods, probes, limits<br/>→ Kubernetes"]
    SIG --> K8S
    CMP["Docker Compose:<br/>ambiente local"] --> CT
    CT --> VM["Firecracker, gVisor<br/>sob FaaS → Compute"]

Componentes da paleta: app (todo serviço do BoxOffice é uma imagem) · worker · serverless (containers dentro de micro-VMs). Cenários: scale-out (imagens pequenas sobem réplicas rápido), serverless-burst (cold starts). Continua em: Kubernetes, Entrega, Redes e segurança — segurança da cadeia de suprimentos, Compute — serverless e autoscaling, Hands-on 1 — container.