Volume no Docker: guardar logs e arquivos fora do container

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.

1Preparar 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:

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.

2Construir a imagem e corrigir o erro do diretório

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

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.

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

3Ver o log sumir sem volume

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

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:

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.

4Rodar 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:

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.

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

5Provar 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:

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.

6Vá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:

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:

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.

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:

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.