/var/lib/docker cresce até virar o problema do disco inteiro. A solução é um único comando, mas rodá-lo às cegas é exatamente como as pessoas acabam apagando a imagem base sobre a qual estavam prestes a construir. Primeiro olhe, depois limpe.
1. Veja para onde foi o espaço
$ clai mostra quanto espaço em disco o docker está usando e quanto pode ser recuperado→ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 47 13 28.88GB 20GB (69%)Containers 16 9 126.8MB 513.8kB (0%)Local Volumes 38 7 6.311GB 4.084GB (64%)Build Cache 181 0 0B 0BLeia a coluna RECLAIMABLE antes de qualquer coisa. Aqui as imagens são o problema, os volumes vêm em segundo, os containers são ruído.
2. A limpeza segura
$ clai remove containers parados, imagens órfãs e redes não usadas→ docker system pruneO prune simples leva os containers parados, as imagens órfãs (camadas sem nenhuma tag), redes não usadas e o cache de build. Não toca em imagens com tag nem em volumes. Esse você pode rodar sem pensar duas vezes.
3. A limpeza agressiva
$ clai remove todas as imagens que nenhum container em execução está usando→ docker system prune -a⚠ CAUTION — remove toda imagem não usada por um container em execução-a amplia "não usada" de sem tag para não usada agora por nenhum container em execução. Sua imagem base de 4 GB, baixada com cuidado, conta como não usada se agora não houver nada rodando — você vai baixá-la de novo no próximo build.
4. Volumes: o espaço que ninguém espera
$ clai lista os volumes do docker que nenhum container está usando→ docker volume ls -qf dangling=trueO prune ignora volumes por padrão, de propósito — é lá que ficam os bancos de dados. Primeiro liste, reconheça os nomes, e só depois decida. docker volume prune apaga dados que, por definição, não têm backup.
5. Só o cache de build
$ clai limpa o cache de build do docker com mais de uma semana→ docker builder prune --filter 'until=168h'Numa máquina de CI, isso costuma ser o ganho maior e mais seguro. --filter until= deixa você manter as camadas recentes, então o próximo build continua rápido.
6. Para não acontecer de novo
$ clai limita os arquivos de log dos containers docker a 10 megabytes e 3 arquivos→ sudo tee /etc/docker/daemon.json <<'EOF'{"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}}EOFOs logs de containers não têm rotação por padrão. Essa é a única configuração que evita o erro mais comum de se repetir. Ela vale para containers criados depois de um restart do daemon.
Pegadinhas
prune -acom nada rodando apaga tudo. A definição de "em uso" é um container em execução, não uma imagem que você gosta. Suba seu stack primeiro, ou use--filter 'until=720h'em vez disso.- Prune não reduz um disco cheio no Docker Desktop. No macOS e no Windows, a imagem de disco da VM não devolve espaço ao host automaticamente.
- Um volume apagado não volta. Não existe lixeira. Faça backup antes de limpar volumes, sempre.
Perguntas relacionadas
Qual a diferença entre docker system prune e docker image prune -a? system prune cobre containers, redes, imagens e cache de build de uma vez; image prune -a só remove imagens, mas remove até as com tag.
Por que /var/lib/docker/overlay2 é tão grande? São as camadas de imagens e containers. Não apague nada ali manualmente — os metadados ficam em outro lugar e você vai corromper o armazenamento de imagens. Use o prune.
Dá para ver qual imagem é a maior? docker image ls --format '{{.Size}}\t{{.Repository}}:{{.Tag}}' | sort -rh as ordena.
Veja também
- Docker e Kubernetes: a memória muscular, substituída
- df diz que o disco está cheio, du diz que não
- Limpe logs e backups antigos com uma frase
CliAI marca o prune -a como CAUTION e pergunta antes de executar — porque a diferença entre os dois prunes são 20 GB de downloads repetidos. Instale em uma linha.