Docker: Arquitetura do Engine, Imagens OCI Imutáveis e Builds Multi-Stage

Antes da popularização do Docker, a entrega de software em ambientes de produção era marcada pelo atrito crônico entre desenvolvedores e administradores de sistemas. A frase célebre "na minha máquina funciona" resumia o desafio de lidar com disparidades de versões de bibliotecas, variáveis de ambiente configuradas manualmente e dependências de sistema operacional divergentes entre as estações de trabalho e os servidores corporativos.

Lançado como projeto de código aberto em 2013, o Docker solucionou esse impasse ao padronizar o empacotamento de aplicações em contêineres autocontidos. Um contêiner reúne o código da aplicação, o runtime, as ferramentas de sistema, as bibliotecas compartilhadas e as configurações em um artefato estático e imutável, garantindo que o comportamento do software seja rigorosamente idêntico em qualquer infraestrutura.

A Arquitetura Cliente-Servidor do Docker Engine

O ecossistema Docker opera sob um modelo cliente-servidor distribuído, composto por quatro elementos fundamentais:

graph TD
    CLI["<b>Docker CLI</b><br/>(Interface de Linha de Comando)"] -->|Chamadas REST via Unix Socket / TLS| API["<b>Docker Engine REST API</b>"]

    API --> Daemon

    subgraph Daemon["<b>Docker Daemon (dockerd)</b>"]
        direction TB
        subgraph Sub["Objetos Gerenciados"]
            direction LR
            IMG["Imagens OCI"]
            CONT["Contêineres"]
            NET["Redes Virtuais"]
            VOL["Volumes"]
        end
    end

    Daemon <-->|Pull / Push de Imagens| Reg["<b>Docker Registry</b><br/>(Docker Hub / ECR / ACR)"]

    classDef cli fill:#0f172a,stroke:#64748b,stroke-width:1px,color:#f8fafc;
    classDef daemon fill:#0d1526,stroke:#38bdf8,stroke-width:2px,color:#f8fafc;
    classDef item fill:#1e293b,stroke:#64748b,stroke-width:1px,color:#f8fafc;
    classDef reg fill:#0f2724,stroke:#34d399,stroke-width:2px,color:#f8fafc;

    class CLI,API cli;
    class Daemon daemon;
    class IMG,CONT,NET,VOL item;
    class Reg reg;

1. Docker Daemon (dockerd)

O serviço em segundo plano que executa no sistema hospedeiro. Ele é o verdadeiro motor de execução: recebe ordens via API REST, gerencia imagens no disco local, configura redes virtuais tipo bridge e invoca runtimes de baixo nível (como o containerd e o runc) para criar os namespaces e limites de cgroups dos contêineres.

2. Docker Client (docker)

A ferramenta de linha de comando operada pelo desenvolvedor. Comandos como docker build, docker run ou docker ps não executam o contêiner diretamente na janela do terminal: eles apenas serializam instruções e as enviam ao Daemon por meio de um socket Unix local (/var/run/docker.sock) ou conexão de rede protegida por TLS.

3. Dockerfile

O documento declarativo que especifica a receita de construção da imagem. Cada instrução (FROM, COPY, RUN) gera uma camada de sistema de arquivos imutável com suporte a cache inteligente, agilizando builds subsequentes onde apenas arquivos modificados precisam ser processados.

4. Docker Registry

O repositório centralizado onde as imagens são armazenadas e versionadas com tags (como Docker Hub, GitHub Container Registry ou registros privados na nuvem). Permite que esteiras de integração contínua (CI) publiquem novas versões prontas para serem baixadas (pull) pelos servidores de produção.

Eficiência Extrema com Builds Multi-Stage

Em ambientes corporativos, construir imagens incluindo compiladores, SDKs pesados e ferramentas de build resulta em pacotes gigantescos (frequentemente superiores a 1 GB), repletos de vulnerabilidades de segurança que não deveriam existir em produção.

O padrão Multi-Stage Build resolve essa ineficiência ao utilizar múltiplos estágios de compilação dentro do mesmo Dockerfile:

# Estágio 1: Ambiente de compilação com SDK completo
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS builder
WORKDIR /app

# Copia arquivos de projeto e restaura dependências com cache
COPY *.csproj ./
RUN dotnet restore

# Copia o código e publica os binários compilados em modo de liberação
COPY . ./
RUN dotnet publish -c Release -o /app/out --no-restore

# Estágio 2: Runtime enxuto final sem ferramentas de desenvolvimento
FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS runner
WORKDIR /app

# Cria usuário não-privilegiado para execução segura
RUN adduser -u 10001 -D appuser
USER appuser

# Copia estritamente os artefatos compilados do estágio anterior
COPY --from=builder /app/out ./

EXPOSE 8080
ENTRYPOINT ["dotnet", "MinhaApi.dll"]

Nesse exemplo, o SDK de compilação permanece isolado no primeiro estágio e é descartado ao final do build. O contêiner final distribuído para produção contém apenas o runtime mínimo sobre uma distribuição Alpine Linux ultracompacta, reduzindo a imagem final para cerca de 80 MB e minimizando drasticamente a superfície de potenciais vulnerabilidades.

Persistência de Dados e Volumes

Como o sistema de arquivos interno de um contêiner é efêmero por padrão (todos os dados gravados em sua camada de escrita são destruídos no momento em que o contêiner é removido com docker rm), a execução de bancos de dados relacionais exige volumes persistentes:

• Volumes Gerenciados (Named Volumes): Diretórios criados e mantidos pelo próprio Docker em /var/lib/docker/volumes/, completamente isolados da estrutura de diretórios do sistema hospedeiro.
• Montagens de Ligação (Bind Mounts): Mapeiam diretamente um diretório específico da máquina do desenvolvedor para dentro do contêiner, muito utilizado em desenvolvimento para obter recarregamento dinâmico de código sem recompilar a imagem.

# Exemplo de inicialização de banco relacional com volume persistente seguro
docker run -d \
  --name db-producao \
  --restart unless-stopped \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=SenhaSeguraProducao \
  -v dados_postgres:/var/lib/postgresql/data \
  postgres:17-alpine

A Fronteira entre Docker e Kubernetes

É comum que desenvolvedores iniciantes confundam o papel do Docker com o do Kubernetes:

• O Docker atua como a ferramenta de construção, teste e execução do contêiner individual em uma única máquina.
• O Kubernetes (K8s) atua como o orquestrador distribuído responsável por coordenar clusters compostos por centenas de servidores, agendando onde cada contêiner deve rodar, gerenciando escalabilidade automática com base no uso de CPU e redirecionando tráfego caso um nó físico sofra pane de hardware.

Dominar a anatomia do Docker Engine e as técnicas de builds multi-stage é o primeiro passo para qualquer equipe que almeja entregar aplicações modernas, resilientes e preparadas para arquiteturas de nuvem em larga escala.