Docker: empacotando aplicações para rodar em qualquer ambiente

O que são containers e por que Docker mudou o desenvolvimento

Isolamento de processo sem overhead de máquina virtual

Containers são processos isolados que compartilham o kernel do sistema operacional host mas têm seu próprio sistema de arquivos, variáveis de ambiente, processos e interface de rede. Diferente de máquinas virtuais, que virtualizam o hardware inteiro e exigem um SO completo por instância, containers compartilham o kernel do host e iniciam em milissegundos com overhead mínimo de memória. Docker tornou containers acessíveis ao padronizar o formato de imagem (OCI), o runtime (containerd), e as ferramentas de build e distribuição — antes do Docker, containers Linux existiam via LXC mas eram complexos de usar. O impacto mais imediato foi resolver o problema de "funciona na minha máquina": a imagem Docker contém exatamente o mesmo binário, biblioteca e configuração que rodará em desenvolvimento, CI e produção.

Imagens Docker — camadas, registry e base images

Como o sistema de camadas torna builds eficientes e distribuição rápida

Uma imagem Docker é um conjunto de camadas somente-leitura empilhadas, onde cada instrução no Dockerfile cria uma nova camada. A eficiência do sistema vem do cache de camadas: se apenas a última camada muda (o código da aplicação), as camadas anteriores (sistema operacional, runtime, dependências) são reutilizadas do cache local e não precisam ser baixadas novamente. Registries como Docker Hub, AWS ECR, Google Artifact Registry e GitHub Container Registry armazenam e distribuem imagens — o docker push envia camadas novas; o docker pull baixa apenas as camadas ausentes localmente. Escolher a base image correta é importante para segurança e tamanho: imagens baseadas em Alpine Linux são 5 a 10 vezes menores que Ubuntu, reduzindo a superfície de ataque e o tempo de download no deploy.

Dockerfile — construindo imagens de forma reproduzível

Boas práticas que resultam em imagens menores, mais rápidas e seguras

O Dockerfile define cada passo para construir a imagem, da base image até o comando de inicialização. A ordem das instruções importa para o cache: coloque as instruções que mudam com menos frequência no início (instalação de dependências do sistema, cópia do arquivo de dependências) e as que mudam frequentemente no final (cópia do código-fonte). COPY package.json antes de COPY . permite que o docker build reutilize a camada de npm install enquanto apenas o código muda. Evite instalar ferramentas de desenvolvimento na imagem final (compiladores, debuggers, ferramentas de teste) — elas aumentam o tamanho e a superfície de ataque sem benefício em produção. Use .dockerignore para excluir node_modules, .git e arquivos de desenvolvimento do contexto de build.

Volumes — dados persistentes fora do container

Separando o estado efêmero do container dos dados que devem sobreviver

O sistema de arquivos de um container é efêmero — quando o container é removido, todos os dados escritos dentro dele são perdidos. Volumes Docker resolvem isso montando diretórios externos (do host ou gerenciados pelo Docker) dentro do container, de forma que os dados persistem independentemente do ciclo de vida do container. Volumes gerenciados pelo Docker (docker volume create) são preferíveis a bind mounts (montagem direta de diretórios do host) em produção porque o Docker gerencia permissões e localização, e são portáveis entre hosts. Bancos de dados em containers devem sempre usar volumes para os diretórios de dados: um container PostgreSQL sem volume perde todo o banco quando reinicia. Em Kubernetes, volumes Docker são substituídos por PersistentVolumes e PersistentVolumeClaims para abstrair o storage subjacente.

Redes Docker — comunicação entre containers

Como containers se descobrem e se comunicam com segurança

Docker cria redes virtuais que permitem containers se comunicarem por nome sem precisar conhecer endereços IP — que mudam a cada reinicialização. Containers na mesma rede Docker podem se referenciar pelo nome do container ou pelo alias de serviço: uma aplicação .NET pode conectar ao banco com a connection string Server=postgres;Port=5432 onde postgres é o nome do container na mesma rede. A rede bridge padrão não suporta resolução DNS por nome — sempre crie redes customizadas (docker network create) para containers que precisam se comunicar. A rede host remove o isolamento de rede e faz o container compartilhar a interface de rede do host — útil para performance mas com implicações de segurança sérias. Em produção com orquestradores como Kubernetes, a rede Docker é substituída por CNI plugins que implementam a especificação de rede do Kubernetes.

Docker Compose — múltiplos containers como serviço

Definindo e orquestrando stacks multi-container com um único arquivo

Docker Compose permite definir aplicações multi-container em um arquivo YAML declarativo, especificando serviços, imagens, variáveis de ambiente, volumes, redes e dependências entre serviços. Um único arquivo docker-compose.yml pode definir a aplicação web, o banco de dados, o cache Redis e o worker de processamento de filas — e um docker compose up inicia tudo na ordem correta. A diretiva depends_on garante que o banco inicie antes da aplicação, mas não espera que o banco esteja pronto para aceitar conexões — o retry na conexão ainda é necessário na aplicação. Docker Compose é excelente para desenvolvimento local e ambientes de CI, mas não substitui Kubernetes em produção para workloads que precisam de auto-scaling, service discovery avançado e gestão de secrets.

Boas práticas de segurança em containers

Reduzindo a superfície de ataque e limitando o impacto de comprometimentos

Rodar processos dentro do container como usuário não-root é a prática de segurança mais importante e frequentemente ignorada: um processo root dentro do container pode ser root no host em certas configurações, representando risco severo. Use a instrução USER no Dockerfile para definir um usuário sem privilégios. Scan de imagens com ferramentas como Trivy, Snyk ou AWS Inspector detecta vulnerabilidades conhecidas nas bibliotecas instaladas na imagem — automatize o scan no pipeline de CI e bloqueie deploys de imagens com vulnerabilidades críticas. Limite os recursos do container com --memory e --cpus para prevenir que um container comprometido ou com vazamento de memória afete outros containers no host. Evite montar o socket Docker (/var/run/docker.sock) dentro de containers de aplicação — qualquer processo com acesso ao socket Docker tem controle total sobre o host.

Multi-stage builds para imagens menores e mais seguras

Separar build de runtime para eliminar ferramentas desnecessárias da imagem final

Multi-stage builds permitem usar uma imagem grande e completa para compilar a aplicação e depois copiar apenas o artefato compilado para uma imagem base mínima. Para uma aplicação .NET, o primeiro estágio usa a imagem SDK completa (600MB) para compilar e publicar; o segundo estágio usa apenas o runtime ASP.NET (200MB) e copia o output do primeiro — a imagem final não contém o compilador, ferramentas de build ou código-fonte. Para Node.js, o primeiro estágio instala dependências de desenvolvimento e faz o build; o segundo estágio copia apenas o dist e instala apenas dependências de produção. Imagens menores iniciam mais rápido, consomem menos banda no deploy, têm menor superfície de ataque, e economizam custos de storage no registry e de memória em produção.

Docker em CI/CD — build, test e push automatizados

Integrando Docker no pipeline para garantir consistência entre ambientes

No pipeline de CI/CD, o Docker garante que os testes rodam exatamente no mesmo ambiente que a produção: o mesmo binário, mesmas dependências, mesma versão do runtime. Um pipeline típico faz docker build para construir a imagem, executa os testes dentro do container, faz o scan de segurança da imagem, e finalmente faz docker push para o registry se tudo passou. O uso de build cache no CI é crítico para performance — sem cache, cada build reconstrói todas as camadas do zero. GitHub Actions, GitLab CI e Jenkins suportam cache de camadas Docker nativamente. Tags de imagem devem incluir o SHA do commit para rastreabilidade: qual código exatamente está rodando em produção é determinístico quando a imagem é tagueada com o commit que a gerou.

Conclusão — Docker como fundação do desenvolvimento moderno

Previsibilidade, portabilidade e o caminho para Kubernetes

Docker transformou o desenvolvimento de software ao tornar o ambiente de execução parte do artefato entregável — a imagem Docker é o executável moderno, portável e reproduzível em qualquer máquina com Docker instalado. Dominar Dockerfile, volumes, redes e Docker Compose é pré-requisito para Kubernetes, ECS e qualquer plataforma de orquestração de containers. Boas práticas de segurança (usuário não-root, multi-stage build, scan de vulnerabilidades) e eficiência de build (ordem de camadas, .dockerignore, cache) fazem a diferença entre containers que passam em auditorias de segurança e containers que se tornam vetores de ataque. Continue em: Fundamentos obrigatórios antes de produção.