Investigando uso de disco do Docker - docker system df / Logs / Volumes

2025-12-15 Tempo de leitura: Cerca de 10 min Dificuldade: Intermediário

O que você vai aprender

• Como identificar o que está consumindo espaço em disco em ambientes Docker
• Usar docker system df para determinar se imagens/containers/volumes são a causa
• Passos seguros de verificação antes de qualquer exclusão

1. Primeiro: Verifique se o disco está realmente cheio (df)

Conclusão: Execute df -h primeiro -- a partição cheia nem sempre é do Docker.

Antes de culpar o Docker, verifique o que está cheio:

$ df -h

Padrões comuns

• / está cheio (dados do Docker geralmente ficam sob root)
• /var é uma partição separada que está cheia (efeito de /var/lib/docker)

2. Verifique quanto o Docker está usando

Conclusão: Execute docker system df para ver qual categoria é a maior antes de investigar.

Obtenha uma visão geral primeiro:

$ docker system df

O que procurar

• Images: Imagens estão se acumulando?
• Containers: Containers parados estão se acumulando?
• Local Volumes: Volumes estão crescendo?
• Build Cache: Cache de build está se acumulando?

3. Localize o que está crescendo

Conclusão: Execute du -h -d 1 /var/lib/docker -- saída grande confirma que o Docker é a origem.

Os dados do Docker geralmente ficam aqui (pode variar conforme a configuração):

• Dados do Docker: /var/lib/docker
• Logs de container: /var/lib/docker/containers/<container-id>/*.log

Verifique o tamanho de /var/lib/docker:

$ sudo du -h -d 1 /var/lib/docker | sort -h

4. Verifique inchaço de logs de container

Conclusão: Arquivos *-json.log grandes no diretório de containers indicam inchaço de logs.

O Docker armazena stdout/stderr dos containers como logs por padrão. Logging continuo causa crescimento aqui.

4-1. Verifique o tamanho do diretório de containers

$ sudo du -h -d 2 /var/lib/docker/containers | sort -h | tail -n 20

4-2. Encontre arquivos de log grandes (top 20)

$ sudo find /var/lib/docker/containers -type f -name "*.log" -printf "%s %p\n" | sort -n | tail -n 20

5. Identifique qual container é a causa

Conclusão: Use docker ps -a ou docker inspect para mapear um ID de container ao seu nome.

Mapeie o ID do container (string longa no caminho) ao nome do container:

5-1. Listar containers (ID e nome)

$ docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Image}}"

5-2. Obter detalhes de um ID de container específico

$ docker inspect <container-id> --format '{{.Name}}'

Nota: .Name pode ter um / no início.

6. Verifique o crescimento de volumes

Conclusão: Execute docker volume ls para listar volumes, depois verifique qual container usa cada um.

Dados de banco, uploads do WordPress, caches etc. tendem a se acumular em volumes.

6-1. Listar volumes

$ docker volume ls

6-2. Ver qual container usa qual volume

$ docker ps -a --format "table {{.Names}}\t{{.Mounts}}"

7. Precauções de segurança (importante)

Conclusão: Nunca execute docker system prune sem verificar -- volumes contêm dados reais.

Abordagens de mitigação

Se inchaço de logs é a causa, os próximos passos típicos incluem:

• Configurar rotação de logs (Docker logging driver / log-opts com limites)
• Revisar o volume de logs da aplicação (tempestades de erro, logs de debug)
• Encaminhar logs necessários para um sistema separado

Verificação

Conclusão: Execute novamente df -h e docker system df para confirmar que o uso diminuiu.

Após investigação ou mitigação, verifique a melhoria:

$ df -h
$ docker system df