Uso de Disco do Docker no Mac: O Que Realmente Consome Espaco

O Docker no Mac raramente parece enorme de uma vez. Ele cresce em camadas.

No comeco e uma imagem, um projeto, um volume de banco de dados, um container parado, um build cache que tu pretendes limpar depois. Depois a maquina fica mais apertada, o Docker Desktop comeca a parecer suspeito, e a conclusao usual e vaga mas emocionalmente satisfatoria: “O Docker esta comendo meu disco.”

Essa conclusao esta na direcao certa, mas e imprecisa demais para ser util. O problema real geralmente nao e “Docker em geral.” E acumulo entre imagens, layers, build cache, containers parados, volumes e dados de runtime que ninguem revisou como um sistema.

Resposta rapida

Por que o Docker silenciosamente fica tao grande no Mac

O Docker foi projetado para manter estado util ate que tu explicitamente diga o contrario. A propria documentacao do Docker descreve a limpeza como conservadora: imagens, containers, volumes e redes nao utilizados geralmente nao sao removidos a menos que tu pedes ao Docker para faze-lo.

Isso e conveniente para fluxos de desenvolvedor e exatamente por isso que o uso de disco cresce devagar.

No Mac, o quadro parece ainda menos obvio porque o Docker Desktop armazena containers e imagens Linux em um unico arquivo grande de imagem de disco. Isso significa que o host pode mostrar uma pegada grande do Docker enquanto as causas reais estao enterradas dentro de multiplas camadas de dados de runtime.

O padrao de crescimento geralmente e alguma combinacao de:

• imagens baixadas e reconstruidas em varios projetos;
• layers compartilhadas reutilizadas entre tags e versoes;
• containers parados que ainda mantem layers gravaveis;
• volumes que armazenam bancos de dados, arquivos enviados ou estado de servicos locais;
• build cache que mantem os builds rapidos ate se tornarem caros;
• objetos dangling deixados para tras apos reconstrucoes e retags.

O resultado e uma pegada que se expande silenciosamente porque cada adicao individual parece normal.

O que realmente ocupa espaco do Docker no Mac

Se tu queres um plano de limpeza util, separa a pegada do Docker em categorias em vez de trata-la como uma caixa preta gigante.

E por isso que um fluxo generico de “maior pasta” e fraco para o Docker. O mesmo tamanho total pode significar decisoes de limpeza muito diferentes dependendo se o espaco e principalmente build cache ou dados reais de volumes.

Imagens Docker e layers compartilhadas

Imagens costumam ser a primeira coisa em que desenvolvedores pensam, mas a historia mais profunda sao as layers. Uma maquina com varios runtimes de linguagem, builds locais estilo CI e multiplos microservicos pode acumular muitas layers compartilhadas e unicas rapidamente.

E por isso que o uso de disco nem sempre mapeia de forma limpa para a lista de imagens que tu te lembras de ter baixado.

Build cache do Docker

O build cache e uma das causas ocultas mais comuns em maquinas de desenvolvedor ativas. Ele existe para tornar builds futuros mais rapidos, o que significa que fica por ai ate tu o limpares. Isso tambem significa que deleta-lo geralmente e uma troca de desempenho, nao uma vitoria gratuita.

Containers Docker parados

Desenvolvedores subestimam isso o tempo todo. Um container que nao esta rodando ainda e um objeto de armazenamento. Se ele ainda existe, ainda pode ocupar espaco em disco.

Volumes Docker

E aqui que o risco aumenta. Os volumes podem conter os dados que tu realmente te importas: bancos de dados, mirrors de pacotes, uploads, indices de busca, conteudo de registro local ou estado de servicos.

Essa e a diferenca entre limpeza do Docker e limpeza de cache comum. Alguns armazenamentos do Docker sao reconstrutiveis. Alguns sao teu ambiente.

Imagens e objetos Docker dangling

Objetos dangling geralmente sao os candidatos mais seguros para limpeza. A documentacao de prune do Docker define imagens dangling como imagens que nao estao com tag e nao sao referenciadas por nenhum container. Sao exatamente o tipo de acumulo que cresce atraves de iteracao normal.

Como verificar o uso de disco do Docker no Mac

O melhor primeiro passo nao e o Finder. E uma visao no nivel do Docker do que o daemon acha que esta consumindo espaco.

A recomendacao do proprio Docker no Mac comeca com docker system df -v, que mostra uso de imagens, containers, volumes locais e espaco recuperavel. Essa e a forma mais rapida de parar de adivinhar.

Usa esta ordem de revisao:

1. Comeca com docker system df -v

Esse e o melhor primeiro resumo porque mostra:

• uso total e recuperavel de imagens;
• uso de containers;
• uso de volumes locais;
• um detalhamento mais completo quando usas a flag verbose.

Se o espaco recuperavel e pequeno, limpeza ampla provavelmente nao vai ajudar muito.

2. Revisa containers parados antes de fazer prune

Verifica se ha muitos containers encerrados que ninguem precisa mais. Esses costumam ser candidatos seguros de limpeza em comparacao com volumes ou estado de runtime ativo.

3. Revisa imagens separadamente do build cache

Imagens e build cache resolvem problemas diferentes. Se o cache e o principal ofensor, limpeza focada em cache geralmente e melhor do que um reset amplo de tudo que o Docker possui.

4. Revisa volumes antes de qualquer coisa que use --volumes

Essa e a parte que as pessoas pulam e depois se arrependem. Um volume pode parecer desanexado de um container atualmente em execucao, mas ainda representar dados locais reais de um projeto que tu planejas iniciar novamente amanha.

5. Revisa a imagem de disco do Docker Desktop no Mac

O FAQ do Docker para Mac observa que o Docker Desktop armazena containers e imagens Linux em um unico arquivo de imagem de disco e que algumas ferramentas mostram o tamanho maximo do arquivo em vez do tamanho real consumido. Isso importa porque um numero assustador do lado do host nem sempre e a mesma coisa que desperdicio imediatamente recuperavel.

Antes de fazer prune em qualquer coisa

Comandos rapidos de revisao do Docker

Esses comandos de inspecao sao uteis antes de tu remover qualquer coisa:

docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume ls

Usa-os para confirmar o que realmente e recuperavel antes de escolher qualquer escopo de prune.

Por que deletar pastas do Docker diretamente e arriscado

Delecao direta parece atrativa porque parece decisiva. Tambem e como tu transformas limpeza do Docker em roleta de limpeza de runtime.

Ha duas razoes.

Primeiro, o Docker rastreia estado de runtime e metadados. Quando tu removes arquivos gerenciados pelo Docker fora do proprio fluxo do Docker, tu arriscas quebrar a relacao entre o que o runtime acredita existir e o que realmente esta no disco.

Segundo, no Mac a pegada do Docker esta vinculada a imagem de disco gerenciada pelo Docker Desktop e ao armazenamento de runtime. A propria documentacao do Docker para Mac avisa explicitamente para nao mover a imagem de disco diretamente no Finder porque o Docker Desktop pode perde-la. A mesma licao geral se aplica a delecao bruta dentro do armazenamento gerenciado pelo Docker: acoes Docker-aware sao mais seguras do que adivinhacao no filesystem.

E por isso tambem que deletar arquivos dentro de um container em execucao nao e a mesma coisa que recuperar espaco em disco do host. Os docs do Docker para Mac observam que o espaco do host e recuperado quando imagens sao deletadas, nao automaticamente quando arquivos desaparecem dentro de containers em execucao.

Quando o prune ajuda

prune e util quando tu ja entendes a pegada e queres que o Docker remova objetos que considera nao utilizados.

Os principais casos onde ajuda sao diretos:

• docker system prune quando containers parados, redes nao utilizadas, imagens dangling e build cache nao utilizado se acumularam;
• docker builder prune quando o build cache e o problema real;
• docker volume prune quando tu verificaste que volumes nao utilizados sao realmente descartaveis;
• limpeza filtrada por tempo ou label quando tu queres estreitar o escopo em vez de varrer tudo.

E aqui que limpeza Docker-aware e claramente melhor do que delecao bruta de arquivos. O runtime entende tipos de objetos. O Finder nao.

Quando docker system prune e perigoso

O perigo nao e que prune seja ruim. O perigo e que “nao utilizado” no Docker ainda pode significar “importante para o meu fluxo de trabalho.”

Tem cautela quando:

• um container parado faz parte de um ambiente local que tu esperas retomar;
• o proximo build precisa do cache que tu estas prestes a apagar;
• volumes locais contem dados de banco de dados ou servicos que tu ainda te importas;
• docker system prune -a removeria imagens que nao estao rodando agora mas ainda fazem parte de trabalho ativo;
• tu estas prestes a adicionar limpeza de volumes sem antes confirmar o que esses volumes representam.

Os docs do Docker sao explicitos que volumes nao sao removidos automaticamente porque isso poderia destruir dados. Esse e o modelo mental certo para limpeza de volumes em geral: volumes merecem mais suspeita do que imagens ou cache dangling.

Como entender as consequencias antes da limpeza

Antes de tu limpar qualquer coisa, responde a questao das consequencias em linguagem simples:

O que eu terei que reconstruir, rebaixar, restaurar ou recriar depois disso?

Essa questao e mais util do que “Quanto posso deletar?”

Para o Docker, a revisao pratica geralmente se parece com isso:

1. A pegada principal e imagens, build cache, containers parados ou volumes?
2. Algum container em execucao faz parte do plano, ou a limpeza requer parar primeiro?
3. Se eu fizer prune do cache, estou confortavel com builds ou pulls mais lentos depois?
4. Se eu fizer prune dos volumes, qual estado de servico ou dados desaparece com eles?
5. Estou usando limpeza do Docker para resolver um problema real de espaco recuperavel, ou reagindo a uma imagem de disco grande e opaca?

Essa e a diferenca entre uma limpeza de desenvolvedor controlada e panico de armazenamento aleatorio.

Por que limpeza de desenvolvedor e diferente de limpeza comum de arquivos

Limpeza comum de arquivos pergunta: “Qual pasta e grande?”

Limpeza do Docker precisa de perguntas diferentes:

• isso e cache reconstruivel ou dados persistentes de servico;
• o runtime esta relatando como recuperavel;
• a limpeza deve acontecer atraves de comandos Docker em vez de delecao no filesystem;
• containers em execucao, containers parados ou volumes fazem parte do modelo de consequencias;
• eu preciso de uma revisao guiada antes de aplicar um caminho de limpeza arriscado?

E por isso que o Docker pertence a um fluxo container-aware, nao ao mesmo balde mental de deletar downloads ou esvaziar uma pasta de cache generica.

Onde o StorageRadar se encaixa

Isso importa porque o Docker nao e apenas “uma pasta grande.” E um ecossistema de tipos de objetos com diferentes consequencias de limpeza.

Se o build cache e o problema, tua acao e diferente de uma maquina pesada em volumes. Se containers em execucao devem ser parados primeiro, isso deve estar visivel antes da limpeza. Se o perfil e arriscado, o fluxo deve te desacelerar de proposito.

O que nao fazer

Evita estes erros comuns:

• nao trates toda pegada grande do Docker como um problema com um comando;
• nao executes rm -rf direto dentro de diretorios gerenciados pelo Docker porque os caminhos parecem grandes;
• nao assumas que uma imagem de disco grande do Docker Desktop significa que todo aquele espaco e seguramente recuperavel agora;
• nao adiciones limpeza de volumes casualmente se nao verificaste o que esses volumes contem;
• nao uses um prune amplo logo antes de uma demo, release ou rebuild de ambiente local que nao podes pagar.

Se o Docker e apenas parte de um problema maior na maquina de desenvolvedor, o guia complementar sobre Xcode DerivedData Ocupando Espaco Demais no Mac e uma proxima leitura util.

Conclusao

O uso de disco do Docker no Mac geralmente nao e misterioso depois que tu o divides nos buckets certos. Os maiores contribuintes tipicamente sao imagens, layers, build cache, containers parados, volumes, objetos dangling e armazenamento de runtime do Docker Desktop.

A jogada segura e inspecionar a pegada primeiro, separar artefatos reconstrutiveis de dados persistentes e usar limpeza Docker-aware somente depois de entender as consequencias.