Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
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.
O ponto é que, se usar, precisa documentar bem o que esses ONBUILD fazem, pra não ficar uma caixinha preta.
Concordo com o Guto, o risco maior é na manutenção.
O que seria sinal de parar esse teste antes de virar padrão
Concordo, aqui no meu time a gente ev ita ao máximo. Esses comandos automáticos podem pegar a gente de surpresa, principalmente se a gente precisar fazer rollback de uma versão antiga. Melhor ser explícito mesmo.
No meu caso, já usei pra automatizar umas tarefas, mas depois de um tempo percebi que complicou na hora de entender o que tava acontecendo na imagem. Acabou virando um pesadelo na manutenção.
Acho que o maior problema é na hora do deploy, pq esses comandos podem rodar em etapas que não estão no seu controle direto. Melhor evitar surpresas quando a equipe precisa fazer rollback rápido.