Primeiro verifique o uso do disco do sistema:

df -h

Se / ou /var estiver cheio, verifique o tamanho do diretório do Docker:

sudo du -h --max-depth=1 /var/lib/docker | sort -h

Os grandes consumidores comuns geralmente incluem estes:

/var/lib/docker/overlay2
/var/lib/docker/containers
/var/lib/docker/volumes
/var/lib/docker/buildkit

Depois observe a distribuição do espaço pela própria visão do Docker:

docker system df
docker system df -v

docker system df mostra imagens, contêineres, volumes locais e cache de build separadamente, o que é mais seguro do que olhar apenas du. du informa qual diretório está grande; os comandos do Docker informam a quais objetos esse espaço pertence.

A documentação oficial do Docker também diz claramente: o Docker adota uma estratégia conservadora com objetos não utilizados; imagens, contêineres, redes e volumes não são limpos automaticamente por padrão, a menos que você execute prune explicitamente.

Primeiro veja os contêineres parados:

docker ps -a

Se houver muitos contêineres temporários já encerrados, você pode limpar os contêineres parados:

docker container prune

Depois veja as imagens:

docker images

Limpe apenas as imagens pendentes (dangling):

docker image prune

Limpe as imagens antigas não usadas por nenhum contêiner:

docker image prune -a

Se você não tem certeza se uma imagem ainda será necessária para rollback, não adicione -a ainda. Em produção, image prune -a pode apagar imagens que não estão referenciadas por nenhum contêiner no momento, mas que você pretendia manter para rollback.

Em máquinas que executam docker build com frequência no VPS, o cache de build pode ser maior que as próprias imagens. Verifique:

docker builder du

Limpe o cache de build:

docker builder prune

Se você confirmar que não precisa de nenhum cache antigo, então considere:

docker builder prune -a

Uma abordagem mais segura é adicionar um filtro de tempo, por exemplo limpar apenas o cache com mais de 7 dias:

docker builder prune --filter "until=168h"

Isso é mais adequado para um VPS em produção do que apagar tudo sem pensar, porque reduz o impacto de baixar e recompilar novamente no próximo build.

Muitas pessoas só ficam de olho em overlay2, mas o que realmente enche o disco são os logs de contêineres. O driver de logs json-file padrão do Docker grava stdout e stderr em arquivos. Se a aplicação não para de imprimir logs de erro e não há rotação de logs, um único log de contêiner pode crescer para vários GB.

Verifique o tamanho dos arquivos de log dos contêineres:

sudo du -h /var/lib/docker/containers/*/*-json.log | sort -h

Para conter o sangramento temporariamente, primeiro localize o contêiner anômalo:

docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}"
docker logs --tail=100 容器名

Não abra logs json enormes diretamente em um editor. Mais importante ainda, corrija a origem dos logs: a aplicação está em loop de erros, as verificações de saúde são frequentes demais, o proxy reverso está tentando novamente sem parar?

A solução de longo prazo é configurar a rotação de logs para o Docker. Edite:

sudo mkdir -p /etc/docker
sudo nano /etc/docker/daemon.json

Escreva ou mescle a seguinte configuração:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Depois reinicie o Docker:

sudo systemctl restart docker

Observação: essa configuração normalmente afeta apenas contêineres recém-criados. Contêineres existentes podem precisar ser recriados para usar as novas opções de logging. Se você usa Docker Compose, recomenda-se executar:

docker compose down
docker compose up -d

Desde que você já tenha confirmado que o arquivo compose e a configuração de volumes estão corretos.

/var/lib/docker/volumes pode ser grande, mas muitas vezes armazena bancos de dados, arquivos enviados, configurações e dados de filas. Esse diretório não pode ser confundido com o cache de imagens.

Primeiro verifique o uso dos volumes:

docker system df -v

Liste os volumes:

docker volume ls

Se você quiser determinar se um volume ainda é usado por um contêiner:

docker ps -a --filter volume=卷名

O Docker fornece:

docker volume prune

Mas esse comando exclui volumes não usados por contêineres. O problema é: durante alguma manutenção com parada, o contêiner do banco de dados pode não existir temporariamente, mas o volume ainda é o seu único dado. Em produção, não execute volume prune sem backup e sem confirmar a finalidade.

Uma ordem mais segura é:

1. Primeiro faça backup dos volumes importantes;
2. Confirme que o projeto compose foi abandonado;
3. Confirme que o nome do volume não é de banco de dados, armazenamento de objetos ou diretório de uploads;
4. Depois exclua o volume especificado pelo nome.

docker volume rm 卷名

docker system prune é um comando de limpeza rápida que limpa contêineres parados, redes não usadas, imagens pendentes e cache de build. Por padrão, ele não limpa volumes.

A versão relativamente segura:

docker system prune

Com filtro de tempo:

docker system prune --filter "until=168h"

A versão de alto risco:

docker system prune -a --volumes

Esse comando não é adequado como "limpeza universal" em um tutorial para iniciantes. -a amplia o escopo da limpeza de imagens, e --volumes inclui também os volumes não usados na limpeza. Para um VPS rodando WordPress, Nextcloud, Gitea ou um banco de dados, uma vez que o julgamento sobre o volume esteja errado, o que pode ser limpo são dados de negócio.

Não é recomendado. overlay2 é o diretório de armazenamento do sistema de arquivos overlay do Docker, não um diretório de cache comum. Ele crescer geralmente é apenas um resultado; a causa pode ser:

• A camada gravável do contêiner grava arquivos temporários continuamente;
• A aplicação grava cache e arquivos enviados dentro do contêiner em vez de em um volume;
• Imagens e contêineres antigos não foram limpos;
• O cache de build se acumula a longo prazo;
• Os logs não têm rotação.

Primeiro encontre os contêineres com camadas graváveis anômalas:

docker ps -s

Se o SIZE de um contêiner for muito grande, sua camada gravável está crescendo. As causas comuns são a aplicação gravar cache, arquivos enviados e arquivos exportados dentro do contêiner. A solução não é apagar o overlay2, mas montar os diretórios persistentes em um volume ou diretório do host e ajustar a configuração da aplicação.

Recomenda-se tratar nesta ordem:

1. df -h para confirmar qual partição está cheia;
2. sudo du -h --max-depth=1 /var/lib/docker | sort -h para encontrar os diretórios grandes do Docker;
3. docker system df -v para determinar a proporção de imagens, contêineres, volumes e cache de build;
4. Primeiro limpe contêineres parados e imagens pendentes;
5. Depois limpe o cache de build;
6. Verifique os logs json-file e configure a rotação;
7. Só então trate os volumes;
8. Não apague overlay2 diretamente.

Se o seu VPS tem apenas um disco de sistema de 20GB ou 30GB, você deve fazer três coisas antes de implantar o Docker:

• Configurar max-size e max-file para os logs do Docker;
• Colocar bancos de dados, diretórios de uploads e dados de negócio em volumes com nomes claros ou em um disco de dados separado;
• Executar regularmente comandos que limpam apenas cache antigo, por exemplo:

docker system prune --filter "until=168h"
docker builder prune --filter "until=168h"

Também mantenha o monitoramento:

df -h
docker system df

Se você já encontrou o disco cheio, não reinicie um monte de serviços primeiro. Quando o disco está 100%, bancos de dados, serviços de logs e gerenciadores de pacotes podem falhar ao gravar. Primeiro libere uma pequena quantidade de espaço seguro e depois corrija as causas raiz uma por uma.

O Docker encher o disco em um VPS parece que overlay2 está grande demais, mas na verdade muitas vezes são imagens antigas, contêineres parados, cache de build, logs json-file e gerenciamento de volumes misturados. A forma realmente segura de lidar não é apagar o diretório do Docker, mas primeiro classificar com docker system df -v e depois limpar do menor para o maior risco.

Lembre-se desta linha de base: imagens e cache podem ser baixados novamente, contêineres parados geralmente podem ser limpos, logs podem ser rotacionados, mas os volumes podem conter seus dados de negócio. Confirme antes de limpar e, depois de limpar, adicione rotação de logs e regras de manutenção periódica, para não ser interrompido pelo mesmo problema novamente em algumas semanas.