Entendendo a instrução ONBUILD no Docker e seus riscos na prática

No mundo do Docker, a instrução ONBUILD costuma gerar uma certa confusão. Ela permite que você defina ações que serão executadas na construção de uma imagem filha, mas na prática, isso pode trazer riscos.

Por exemplo, ao usar ONBUILD para automatizar comandos em imagens que serão utilizadas como base, você precisa estar seguro de que esses comandos não vão impactar negativamente futuras construções ou introduzir efeitos colaterais difíceis de rastrear. A decisão fica mais saudável quando o time consegue medir o impacto depois.

A documentação oficial até explica o conceito, mas na hora de aplicar, a dúvida é: será que essa automação toda não acaba dificultando o controle de mudanças ou complicando rollbacks?

Na minha opinião, é melhor evitar usar ONBUILD a não ser que tenha certeza absoluta de que os comandos são seguros e reversíveis. Caso contrário, melhor fazer as ações explicitamente na sua Dockerfile principal. Assim, fica mais fácil de entender, testar e manter. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.

Já passaram por alguma situação onde o uso de ONBUILD complicou a manutenção ou gerou surpresas na produção? Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.