-2
obrenoalvim
1 min de leitura ·

Docker em desenvolvimento local: você usa no dia a dia ou só finge que usa?

Docker para produção é consenso. Docker para desenvolvimento local é uma conversa diferente.

Tenho visto dois padrões opostos em times: quem roda tudo em container ("mas funciona na minha máquina" não existe) e quem instalou Docker, criou um docker-compose.yml e usa só quando lembra.

Onde Docker em dev realmente ajuda

Bancos de dados e serviços auxiliares. Redis, PostgreSQL, Elasticsearch, RabbitMQ: subir com docker compose up sem instalar nada localmente é genuinamente bom.

Times com SOs mistos. Um dev no Mac, outro no Windows, outro no Linux: Docker reduz "funciona aqui, não sei por que não funciona aí".

Onboarding. Novo dev clona o repo, roda docker compose up e tem o ambiente pronto. Isso tem valor real.

Onde Docker em dev atrapalha

Desempenho no Mac. Não é hype: o overhead de virtualização no macOS ainda é perceptível para aplicações que fazem muita I/O de arquivo. Next.js em dev com hot reload dentro de container no Mac pode ser frustrante.

Complexidade de debug. Breakpoints, attach de debugger, profiles de performance. Tudo tem uma camada extra de configuração.

Loop de feedback mais lento. Para desenvolvimento iterativo rápido, rodar direto no host ainda é mais ágil na maioria dos casos.

O que eu faço

Serviços de infraestrutura (banco, cache, filas) no Docker. Aplicação principal rodando direto no host. Esse meio-termo funciona para mim.

Qual é o padrão de vocês?

Carregando publicação patrocinada...
3

Qual é o padrão de vocês?

DevContainers. É um padrão incrível, difícil de configurar da primeria vez mas seu ambiente nunca para de funcionar.

1

DevContainers é exatamente o oposto do "instalei mas não uso". A configuração inicial é chata, mas o ponto que você levantou sobre nunca parar de funcionar é o que justifica o esforço. O ambiente está no repo, é reproduzível, e novo dev abre o VS Code e está rodando em minutos.

O trade-off que vejo é latência de I/O, especialmente no Mac com bind mount. Você sente isso no dia a dia ou o projeto não tem workload pesado o suficiente para ser um problema real?

3
1

Faz sentido, bancos e serviços auxiliares são onde Docker realmente vale no local. A questão de não poluir o sistema é o argumento mais prático que existe. Você containeriza a aplicação principal também, ou só os serviços?

3

tento por em container tudo, DB, redis, kafka, workers, API, algum backend pra processamento.
acho mais prático pra subir o ambiente de desenvolvimento sem ter que ficar configurando dependências no sistema. tô ate planejando pra tornar meu sistema todo em containers kkkk assim fics mais fácil migrar de sistema

1

Containerizar tudo tem custo no início mas paga no longo prazo, especialmente quando entra alguém novo no projeto. O que eu sinto falta às vezes é no hot reload da API dentro do container: o tempo de rebuild pode atrasar bastante o ciclo. Você já resolveu isso com volumes montados ou usa alguma outra estratégia para manter o desenvolvimento rápido?