Entendendo a instrução ONBUILD no Dockerfile e seus riscos na produção

A instrução ONBUILD no Dockerfile é uma ferramenta poderosa, mas que pode causar dor de cabeça se usada sem critério. Ela permite definir ações que serão executadas na construção de uma imagem filha, o que é útil para criar imagens base com comportamentos padrão.

Porém, seu uso indiscriminado pode gerar surpresas na hora de fazer deploy ou atualizar ambientes. A documentação do Docker mostra que ela funciona como um gatilho, mas não deixa claro o impacto de ações automáticas que podem não fazer sentido em todos os contextos. A decisão fica mais saudável quando o time consegue medir o impacto depois.

No meu time, a gente evita usar ONBUILD sem um controle rigoroso, porque ela pode acionar comandos que não estão alinhados com o ambiente de produção, além de dificultar o entendimento do fluxo de build. O ideal é usar scripts explícitos ou etapas bem definidas, assim a gente mantém o controle sobre o que acontece em cada fase. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.

Quem já passou por perrengue com ONBUILD, sabe que um erro aqui ou ali pode complicar a release, especialmente se a equipe não estiver atenta ao que está embutido na imagem. Assim, minha dica é: avalie se realmente precisa dessa automação ou se dá pra fazer de forma mais transparente, com etapas claras no Dockerfile. 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.