Monitorar mudanças em volumes Docker usando inotifywait não funciona como esperado

No meu time, a gente usa bastante Docker pra isolar ambientes, mas um problema que sempre surge é na hora de monitorar mudanças em volumes montados. Recentemente, tentei usar inotifywait dentro de um container pra escutar alterações em um diretório que tava montado do host, mas simplesmente não pegava as mudanças.

A situação é comum: você tem um script rodando dentro do container que precisa reagir às mudanças de arquivos, mas o inotifywait não dispara, mesmo quando a coisa muda de verdade no sistema de arquivos do host.

A causa principal é que o inotifywait não reconhece alterações em volumes montados do host por causa de limitações do próprio kernel ou do modo como o Docker manipula esses eventos. A solução que funciona na prática é usar polling ao invés de eventos baseados em inotify, ou ajustar a configuração do Docker para melhorar a detecção. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.

No seu caso, pode ser interessante testar com --poll no inotifywait, assim:

inotifywait -e create -e modify -e delete -e move --recursive --monitor --timeout 0 --verbose --poll /caminho/monitor

Isso ajuda bastante na detecção, mesmo que o desempenho fique um pouco pior. Outra alternativa é usar ferramentas específicas de watcher que são mais tolerantes às limitações do volume Docker.

Quem já passou por isso e tem alguma dica prática pra evitar esse tipo de dor na hora de automatizar deploys ou scripts de build? 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. 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.