Tudo sobre o novo Docker compose file watch
Tags: docker, containers, development, devops
Published: 2023-10-20 22:28:14

---
title: Tudo sobre o novo Docker compose file watch
published: true
cover_image: https://raw.githubusercontent.com/khaosdoctor/blog-assets/master/images/2023/07/articles.png
date: 2023-07-06 11:00:05 UTC
tags: docker,containers,development,devops
canonical_url: https://blog.lsantos.dev/docker-compose-watch/
---

Depois de muitos anos de pedidos, finalmente a Docker resolveu implementar um [watch](https://docs.docker.com/compose/file-watch/) mode no comando compose! Com ele a gente vai poder iniciar uma espécie de atualização automática dos nossos containers sempre que nossos arquivos forem modificados no disco!

## O problema

Um dos maiores problemas para quem usava (ou até usa) o Docker compose, é que, sempre que temos nosso cluster de containers ativo, e estamos desenvolvendo localmente com um desses containers, quando fazemos uma modificação em algum dos arquivos do projeto, precisamos reiniciar todo o compose para criar a nova imagem.

Geralmente, quando estamos fazendo uma API externa, por exemplo, não temos tanto esse problema porque podemos rodar a API em si fora do compose, enquanto apontamos para dentro dos containers de dependências, por exemplo, de alguma API externa ou algo do tipo. Mas, as vezes, isso não é possível, geralmente quando precisamos que seja o que for que a gente está fazendo fique na mesma rede do Docker, ou então precise estar rodando dentro de um container. Nesse caso, a única saída é rodar tudo dentro do Docker compose.

Porém, sempre que a gente atualiza um dos arquivos do projeto, temos que rodar aquele famoso `docker compose down` seguido de um `docker compose up --rebuild` para poder reconstruir o nosso serviço e continuar desenvolvendo.

## A solução

Por muitos anos, a galera sugeriu que o docker compose tivesse um modo watch, ou seja, um modo que pudesse ouvir o que está acontecendo com um determinado arquivo ou conjunto de arquivos do projeto e rodar um comando específico quando eles forem alterados. Depois de alguns anos, temos o **[compose file watch](https://docs.docker.com/compose/file-watch/) mode**. E o mais legal é que você não precisa habilitar ele para todos os seus serviços.

Isso permite que a gente agora comece a desenvolver diretamente dentro dos containers do compose, tornando o ambiente muito mais fácil de ser migrado de um lado para o outro, independente se o seu projeto precisa ou não de uma integração direta com o Docker.

Para ativar o modo `watch` basta que você coloque a chave `watch` em qualquer serviço dentro do seu `docker-compose.yml`. Essa chave leva um array de objetos com duas propriedades, uma é o `path` e o outra é a `action`, basicamente o serviço vai tomar uma `action` quando tiver uma mudança em um determinado `path`.

Vamos a um exemplo:

```
services:
	web:
    	build: .
        command: npm run dev
        x-develop:
        	watch:
            	- action: sync
                  path: ./web
                  target: /src/web
                  ignore:
                    - node_modules
```

> No momento, o compose watch mode está em estado experimental, por isso temos que usar a chave `x-develop` para dizer que estamos ativando um comando beta.

## Actions

Existem dois tipos de actions pré definidas que você pode tomar: `sync` e `rebuild`:

### Sync

Esse tipo de ação vai garantir que qualquer mudança feita no seu arquivo local, fora do container, seja adicionada ao container e substitua o arquivo que está dentro dele.

É muito parecido com o conceito de bind mounts, ou até mesmo de volumes, que continuam existindo dentro do Docker, mas, ao contrário deles, você tem uma granularidade maior com o Sync do que com os volumes. Um exemplo disso é justamente poder ignorar arquivos ou diretórios inteiros, coisa que não podemos fazer a não ser que tivéssemos múltiplos volumes.

Um caso de uso muito interessante disso é justamente no nosso amado JavaScript, especialmente com Node.js, o ideal é que a gente ignore completamente a pasta `node_modules` porque, por mais que a gente tenha muito código JS lá dentro, algumas dependências usam Native Modules, que não vão funcionar em ambientes diferentes do que eles foram criados e compilados para executar.

### Rebuild

Quando usamos o Rebuild, vamos ter o equivalente de rodar `docker compose up --build <serviço>` sempre que salvarmos o `path`.

Enquanto o `sync` é mais recomendado para aplicações que podem fazer um _hot reload_, isto é, recarregar a aplicação já é suficiente para poder verificar as modificações, como um front-end ou algo do tipo, o `rebuild` é mais indicado para quando temos uma modificação em algum arquivo chave (tipo o `package.json`) que precisa de uma recompilação da imagem para reinstalar ou remover dependências que podem ter sido modificadas.

> Outro caso de uso é para linguagens compiladas, que precisam passar pelo processo completo de build para serem refeitas, embora existam casos onde você pode somente trocar o binário de uma aplicação que será suficiente.

### Path e Target

Ambas as ações vão acompanhadas de duas outras propriedades, o `path` e o `target`.

Em resumo, o `target` é o caminho do arquivo observado dentro do container, por exemplo, se meu arquivo `package.json` está na raiz da minha pasta local, mas dentro da pasta `/app` do meu container, então meu target será `/app/package.json`.

Lembrando que, por regra, todos os caminhos são baseados no diretório de build da sua aplicação, ou seja, o local onde o docker encontrou o Dockerfile

## Executando

Para executar o docker compose watch, primeiramente precisamos criar a build do nosso serviço com `docker compose up -d --build --wait`, isso fará com que o docker inicie o compose e construa todas as imagens.

Depois, podemos rodar `docker compose alpha watch` para iniciar o watch mode que vai ler as configurações que queremos do nosso arquivo.

# Conclusão

O Docker watch é um comando que será muito útil na maioria dos workflows de programação, especialmente quando temos que desenvolver aplicações de grande porte que permitem um Hot Reload.

Com esse comando podemos abrir as portas para o desenvolvimento dentro de containers cada vez mais, ou seja, não vamos ter diferenças substanciais entre as máquinas e chega do "na minha máquina funciona" de uma vez por todas!

> **Importante:** Lembre-se que o comando ainda está no estado alpha, então é possível que a API dele mude nos próximos meses, se isso acontecer, vou tentar atualizar o artigo para refletir as mudanças!