Contexto
Estou construindo uma aplicação Django usando uma imagem Docker baseada em
python:3.13-alpine3.23, em um pipeline CI do GitLab.
Problema
Após substituir a dependência
cx-Oracle por
oracledb no
requirements.txt, o tempo de instalação no Docker subiu de cerca de 48 segundos para mais de 10 minutos, impactando bastante o ciclo de CI.
Análise técnica
O principal culpado é o fato de que o Alpine usa musl, que não tem suporte a rodas (wheels) pré-compiladas para muitas bibliotecas, obrigando o pip a buildar tudo do zero. Isso causa um delay enorme, como exemplificado na questão do StackOverflow.
Soluções práticas
- Usar imagens base com glibc: Uma alternativa é trocar a base por uma imagem mais compatível, como
python:3.13-slim. Assim, conseguimos rodas pré-compiladas e instalação mais rápida.
- Construir wheels para Alpine: Se a mudança de base não for possível, considere criar suas próprias rodas compatíveis com musl, embora seja mais complexo.
- Cache de dependências: Aproveite cache do Docker para evitar rebuilds desnecessários.
- Pré-instalar dependências: Se possível, criar uma imagem customizada onde as dependências já estejam instaladas, reduzindo o tempo do pipeline.
O que a comunidade acha?
- Vocês já passaram por isso? Como mitigar o impacto na CI?
- Vale a pena migrar para uma base mais compatível ou investir na build de wheels customizadas?
- Quais estratégias de rollback ou deploy incremental podem ajudar nesse contexto?
Perguntas finais
Como vocês gerenciam o tradeoff entre compatibilidade, velocidade de build e manutenção em ambientes Alpine? Compartilhem suas experiências e dicas.
Vamos debater!
No meu time, a gente sempre tenta evitar builds longos no CI, então migrar pra uma imagem mais compatível foi uma das primeiras ações. Além do mais, isso melhora o DX do desenvolvedor, que não fica esperando horas pra testar uma dependência nova.
A questão do rollback também fica mais fácil se usar imagens base que suportem wheels. O ganho fica mais claro quando existe rollback e métrica acompanhando.
Concordo com o André. Além disso, é importante ter um cache bem configurado no pipeline, pra evitar baixar tudo de novo toda vez. Mas o ponto do Alpine ser mais lento por causa do musl é real. Talvez a troca de base seja a melhor estratégia mesmo. Também vale definir quem revisa quando o fluxo sair do caminho feliz.