A primeira vez que usei Docker — e o que ele resolveu de vez
Em 2020 parei de ouvir falar e comecei a usar. O problema que me fez aprender Docker não foi filosofia de DevOps — foi 'funciona na minha máquina' uma vez de mais.
Em 2019 eu sabia que Docker existia. Sabia o pitch: "container = ambiente isolado que funciona igual em qualquer máquina."
Mas tinha a sensação de que era coisa de empresa grande. Para o que eu estava fazendo — aplicações Python rodando em um único servidor — parecia overhead desnecessário.
Em março de 2020 precisei onboar um dev no projeto. Levamos dois dias para colocar o ambiente dele funcionando. Versão do Python diferente, dependência que instalava versão conflitante no macOS dele, variável de ambiente que eu tinha no meu .zshrc mas não estava documentada.
Dois dias. Para setup.
Aprendi Docker nessa semana.
O conceito fundamental é simples: em vez de documentar como configurar o ambiente, você descreve o ambiente em código e o Docker garante que todos rodam o mesmo ambiente.
FROM python:3.8-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
Esse Dockerfile descreve: começa com Python 3.8 Alpine, instala as dependências, copia o código, e quando rodar, inicia com uvicorn.
docker build -t minha-api . — cria a imagem.
docker run -p 8000:8000 minha-api — roda.
Qualquer pessoa com Docker instalado roda o mesmo container. Não importa se é macOS, Windows, Linux, CI ou produção.
O que resolveu de vez:
Não foi o problema do "funciona na minha máquina" — esse tinha solução manual (documentar melhor, fixar versões). Foi que Docker faz a consistência ser o default, não o esforço.
Quando você tem Dockerfile, o environment documentation está no repositório, versionado, e é executável — não é um README que alguém esqueceu de atualizar.
Docker Compose veio logo depois — para quando você tem mais de um serviço:
version: "3.8"
services:
api:
build: .
ports:
- "8000:8000"
environment:
- DATABASE_URL=postgresql://postgres:password@db:5432/appdb
depends_on:
- db
db:
image: postgres:13
environment:
- POSTGRES_PASSWORD=password
- POSTGRES_DB=appdb
docker compose up — sobe a API e o banco de dados, configurados, conectados, prontos. Qualquer dev do time roda isso e tem o ambiente completo em 2 minutos.
O onboarding que levou 2 dias ficou em 20 minutos.
O que Docker não resolve: ele garante consistência de ambiente, não qualidade de código. Container rodando código ruim ainda roda código ruim.
E tem uma curva de aprendizado real — network, volumes, multi-stage builds, variáveis de ambiente. Não é complicado, mas tem detalhe suficiente para você gastar tempo aprendendo antes de ser fluente.
Vale. Em 2020 virou ferramenta padrão no meu toolkit — e em 2023, quando montei o ecossistema inteiro de /apps, Docker era o fundamento que fez tudo funcionar consistentemente.