# Volume no Docker: guardar logs e arquivos fora do container

> Como usar docker run -v para que logs e arquivos sobrevivam ao fim do container e sejam compartilhados entre vários, no Windows e no Linux.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Containers
- URL: https://pages.formacaoaws.com.br/blog/volume-no-docker-windows-e-linux/
- Aula de origem: "Usando volume com Docker (Exemplo em Windows e Linux)" (https://www.youtube.com/watch?v=j_y7gDq5So4)

Quando um container é encerrado, tudo o que estava dentro dele vai embora, inclusive o log da aplicação. Com `docker run -v` você liga uma pasta do host a uma pasta do container: o log e qualquer arquivo ficam no host, sobrevivem ao `docker stop` e podem ser compartilhados por vários containers.

A aula é de outubro de 2021. Gravei no Windows, embora no dia a dia eu use Linux, e mostro os dois: a diferença está só no caminho que você passa ao volume.

## O problema: o container morre e leva os dados

Imagine o host e, dentro dele, um container rodando uma aplicação em Node. Você tem dados no host que o container precisa enxergar, ou dados que o container gera e que não podem se perder. Ao ser encerrado, o container remove tudo o que está dentro dele, e o log some junto.

Há um segundo caso, comum em aplicação com alta disponibilidade: vários containers da mesma aplicação escrevendo no mesmo lugar. Com três containers, cada um com o seu log, quando um morre o log dele vai embora. Eu quero um diretório só para os logs de todos.

A solução é criar um volume no host e compartilhá-lo com o container. O que o container escrever na pasta do volume fica no host. O que já estiver na pasta aparece dentro do container quando ele sobe.

**Fluxo:** Pasta logs no host (arquivos que você controla) → Volume (-v) (liga a pasta ao container) → Container (/usr/src/app/logs) → Dados (continuam depois do docker stop)

## Passo 1: preparar a aplicação para gravar log

O projeto de exemplo é uma aplicação Node mínima: a rota `/` registra "Chegou request" no log. Por padrão ela não gera arquivo de log. Para ter log, troquei o último comando do Dockerfile, o `CMD`, para mandar a saída da aplicação para um arquivo:

```dockerfile
CMD node app > logs/app.log
```

O diretório de trabalho da imagem é `/usr/src/app`, então o log vai para `/usr/src/app/logs/app.log`.

## Passo 2: construir a imagem e corrigir o erro do diretório

Construa a imagem, chamada `teste-volume`, e rode o container mapeando a porta 3000:

```bash
docker build -t teste-volume .
docker run -ti -p 3000:3000 teste-volume
```

Na primeira vez deu erro: a aplicação não conseguiu criar `logs/app.log` porque o diretório `logs` não existia na imagem. A correção é criá-lo no Dockerfile, com uma linha `RUN mkdir logs`, e construir a imagem de novo.

![O Dockerfile com a linha 13, RUN mkdir logs, que cria a pasta onde o log será gravado](https://pages.formacaoaws.com.br/blog/assets/posts/volume-no-docker-windows-e-linux/dockerfile-mkdir-logs.webp)

Rodando agora, não deu erro, e `localhost:3000` no navegador respondeu.

## Passo 3: ver o log sumir sem volume

Ainda sem volume, entre no container e acompanhe o log. Pegue o nome do container no `docker ps`:

```bash
docker ps
docker exec -ti <nome-do-container> bash
cd logs
tail -f app.log
```

Cada vez que atualizo a página, chega uma linha "Chegou request". Agora pare o container e suba outro:

```bash
docker stop <nome-do-container>
docker run -ti -p 3000:3000 teste-volume
```

No novo container, o mesmo `tail -f` mostra que o log anterior sumiu: só aparece a requisição que fiz depois. Era tudo gerado dentro do container, e é esse comportamento que o volume resolve.

## Passo 4: rodar com volume no Windows

O volume é o `-v`, no formato `pasta-no-host:pasta-no-container`. No Windows usei o caminho completo do projeto, com a pasta `logs` do host ligada a `/usr/src/app/logs`. Troque o caminho pelo da sua pasta:

```bash
docker run -d -p 3000:3000 -v /c/Projetos/docker-volume/fontes/logs:/usr/src/app/logs teste-volume
```

O `-d` roda o container em segundo plano e libera o terminal.

> **Importante:** as opções vêm antes do nome da imagem, cada uma com o seu valor. Na primeira tentativa deixei o `-p` sem valor e a porta depois do volume, e o Docker respondeu `Invalid containerPort: -v`. Na segunda, a porta ficou repetida depois do volume e ele tentou baixar a imagem `3000:3000`.

Na terceira deu certo: o `app.log` apareceu na pasta `logs` do projeto, no host, e as requisições do navegador chegam nele.

## Passo 5: provar que os dados sobrevivem ao container

Criei na pasta `logs` do host um arquivo `teste.txt` com o texto `teste1` e parei o container com `docker stop`. O `teste.txt` continuou lá. O `app.log` foi zerado quando subi o container de novo: é característica da minha aplicação, que ao iniciar recomeça o arquivo de log. O `teste.txt` quem controla sou eu, e ele ficou intacto.

Também funciona de dentro para fora. Entrei no container, instalei o `nano` e editei o arquivo:

```bash
docker exec -ti <nome-do-container> bash
cd logs
nano teste.txt
```

Escrevi `teste2` ali dentro e a alteração apareceu no arquivo do host.

![A pasta logs no host, com app.log e teste.txt, e o app.log aberto com a linha Chegou request](https://pages.formacaoaws.com.br/blog/assets/posts/volume-no-docker-windows-e-linux/app-log-no-host.webp)

## Passo 6: vários containers no mesmo volume

Para o cenário dos três containers, rodei o mesmo comando do passo 4 mais duas vezes, trocando só a porta do host (a do container continua 3000). O volume é o mesmo nos três:

```bash
docker run -d -p 3001:3000 -v /c/Projetos/docker-volume/fontes/logs:/usr/src/app/logs teste-volume
docker run -d -p 3002:3000 -v /c/Projetos/docker-volume/fontes/logs:/usr/src/app/logs teste-volume
```

Abri um terminal em cada um (`docker exec -ti <nome> bash`) e deixei em todos o acompanhamento do arquivo:

```bash
tail -f logs/teste.txt
```

Escrevi `teste3` no arquivo e ele apareceu nos três terminais. Escrevi `teste4` e apareceu nos três de novo. O mesmo vale para o log: uma requisição na porta 3000, 3001 ou 3002 gera uma linha no mesmo arquivo.

![O tail de logs/teste.txt dentro de um dos containers: o arquivo do volume mostra teste1, teste2, teste3 e teste4](https://pages.formacaoaws.com.br/blog/assets/posts/volume-no-docker-windows-e-linux/tail-teste-txt.webp)

## No Linux: o caminho fica mais simples

No Linux o `-v` aceita o diretório atual com `$(pwd)`, então você não precisa do caminho completo. O volume aponta para a pasta `logs` de onde você estiver:

```bash
docker run -d -p 3000:3000 -v "$(pwd)"/logs:/usr/src/app/logs teste-volume
```

No Windows não encontrei de forma trivial uma variável que desse só o caminho atual, por isso gravei a aula com o caminho completo. Em servidor, o mais comum é o Linux.

## Checklist

- Confirme que a aplicação grava numa pasta fixa dentro da imagem e que ela existe (`RUN mkdir logs`).
- Passe o volume com `-v pasta-no-host:pasta-no-container`, antes do nome da imagem.
- No Windows, use o caminho completo da pasta; no Linux, `"$(pwd)"/logs` basta.
- Use `-d` para o container rodar em segundo plano.
- Pare o container com `docker stop` e confira que os arquivos continuam no host.
- Para compartilhar entre containers, repita o mesmo `-v` em cada `docker run`, mudando só a porta do host.

Com o volume, o log e os arquivos deixam de morrer junto com o container. É esse tipo de prática, feita no terminal, que eu levo para dentro da Formação AWS.