É seguro limpar docker / overlay2 /

109

Eu tenho alguns contêineres docker em execução no AWS EC2, a pasta / var / lib / docker / overlay2 cresce muito rápido em tamanho de disco.

Estou me perguntando se é seguro excluir seu conteúdo. ou se o docker tiver algum tipo de comando para liberar algum uso do disco.


ATUALIZAR:

Na verdade, eu docker system prune -ajá tentei , que recuperou 0Kb.

Além disso, o tamanho do meu disco / docker / overlay2 é muito maior do que a saída de docker system df

Depois de ler a documentação do docker e a resposta do BMitch, acredito que é uma ideia estúpida mexer nessa pasta e vou tentar outras maneiras de recuperar meu espaço em disco.

qichao_he
fonte
você encontrou alguma resposta para isso? Ainda estou tendo o mesmo problema.
Saurabh_Jhingan
1
Eu corri docker image prune --alle então docker system prune -a. Ele recuperou meu espaço em disco em cerca de 50 GB, que estava sendo usado por arquivos em / var / lib / docker / overlay2. Mas, docker system prune -ateria sido o suficiente. Além disso, os meus detalhes de configuração são: OS: Ubuntu 20,Docker : 19.03.12
Binita Bharati

Respostas:

73

Docker uses /var/lib/docker to store your images, containers, and local named volumes. Deleting this can result in data loss and possibly stop the engine from running. The overlay2 subdirectory specifically contains the various filesystem layers for images and containers.

To cleanup unused containers and images, see docker system prune. There are also options to remove volumes and even tagged images, but they aren't enabled by default due to the possibility of data loss.

BMitch
fonte
1
The answer is the same (except you can exclude volumes). If you delete things in there and break it, you get to keep both pieces. Use the tools provided for this job.
BMitch
1
The overlay2 folder should contain the filesystem layers needed for your images and containers. You're free to ignore this advice, but please don't ask me for advice on how to recover a failed system after you break it, particularly since I gave you a supported way to cleanup your filesystem.
BMitch
21
Eu tentei docker system prune -a, que recuperou 0kb de espaço. No momento, o caso para mim é que o tamanho do disco de / docker / overlay2 é muito maior do que a saída de docker system df. Essa é a razão pela qual eu continuo cavando esse assunto. Mais uma vez, obrigado por sua resposta, senhor. Acho que preciso ler mais sobre a documentação do docker ou provavelmente apagá-lo totalmente e reiniciá-lo. Eu só preciso manter um banco de dados postgres e o
montei
9
Direi que a forma "com suporte" também não está funcionando para mim. Fazer toda a poda do docker system -a, do docker volume, do docker image e do docker container ainda me deixa com 80% do meu disco sendo usado pelo Docker. Isso com todos os contêineres parados.
Craig Brett
1
@franzisk para limpar tudo que você excluiria tudo em /var/lib/dockervez de um único subdiretório que o deixaria em um estado inconsistente.
BMitch
52

Achei que funcionou melhor para mim:

docker image prune --all

Por padrão, o Docker não removerá imagens nomeadas, mesmo se não forem usadas. Este comando removerá imagens não utilizadas.

Observe que cada camada em uma imagem é uma pasta dentro da /usr/lib/docker/overlay2/pasta.

Sarke
fonte
3
'podar imagem' funcionou muito melhor do que 'podar sistema'. Obrigado!
DavidG de
Atenção! Isso é bastante destrutivo, pois remove todas as imagens de contêineres que não estão em execução. Você os reconstruirá por horas se eles forem seus e ainda não forem colocados no registro. Mas ainda não pode ir além do que docker system dfmostra (você pode ainda estar sem espaço e aquele overlay2depósito de lixo maléfico precisa ser destruído manualmente.
mirekphd
Well, yeah, it removes the images.
Sarke
Attention: In my case where I used docker swarm it also deleted all tagged images, even for running containers
velop
This worked but buyer beware this removes EVERYTHING that is not in a container.
jimh
30

I had this issue... It was the log that was huge. Logs are here :

/var/lib/docker/containers/<container id>/<container id>-json.log

You can manage this in the run command line or in the compose file. See there : Configure logging drivers

I personally added these 3 lines to my docker-compose.yml file :

my_container:
  logging:
    options:
      max-size: 10m
Tristan
fonte
2
Can you add a few lines from the link to the answer?
RtmY
Would be nice to also get info on how to identify which container is the one with the giant log file. I have a bunch of containers and log files, some are huge some are tiny.
Micah Zoltu
How's that answers the OP question?!
Slavik Meltser
2
Essa resposta é parcial, especialmente se o problema fosse "logs" (talvez possamos melhorá-lo com algumas edições?). Até que eu visse essa resposta, eu estava prestes a começar a deletar aleatoriamente grandes diretórios do meu cheio overlay2. No meu caso, a capacidade total para /var/lib/dockerfoi 50GB e 36GB do que foi consumido por um arquivo: /var/lib/docker/overlay2/<container id>/diff/var/log/faillog. Supondo que este arquivo não seja central para manter tudo funcionando, meu hack de curto prazo é apenas removê-lo (e talvez eu também ajuste o meu docker-compose).
D. Woods
19

também teve problemas com crescimento rápido overlay2

/var/lib/docker/overlay2 - é uma pasta onde o docker armazena camadas graváveis ​​para seu contêiner. docker system prune -a- pode funcionar apenas se o recipiente for parado e removido.

no meu, fui capaz de descobrir o que consome espaço entrando overlay2 investigando e investigando.

essa pasta contém outras pastas nomeadas de hash. cada um deles possui várias pastas, incluindo diffpasta.

diff pasta - contém a diferença real escrita por um contêiner com estrutura de pasta exata como seu contêiner (pelo menos foi no meu caso - ubuntu 18 ...)

então eu costumava du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpdescobrir que /tmpdentro do meu contêiner está a pasta que fica poluída .

então, como solução alternativa, usei o -v /tmp/container-data/tmp:/tmpparâmetro de docker runcomando para mapear a /tmppasta interna para hospedar e configurar um cron no host para limpar essa pasta.

A tarefa cron era simples:

  • sudo nano /etc/crontab
  • */30 * * * * root rm -rf /tmp/container-data/tmp/*
  • save and exit

NOTA: overlay2é a pasta docker do sistema, e eles podem alterar sua estrutura a qualquer momento. Tudo acima é baseado no que eu vi lá. Tive que ir na estrutura de pasta do docker apenas porque o sistema estava completamente sem espaço e nem mesmo me permitia fazer o ssh no contêiner do docker.

user2932688
fonte
Obrigado por esta resposta, colocamos em contêineres um antigo banco de dados / aplicativo que gera muitos /var/log/apache2/error.log. Reinicializo error.log e access.log e adiciono um novo volume para
facilitar o
6

Backgroud

A culpa pelo problema pode ser dividida entre nossa configuração incorreta dos volumes do contêiner e um problema com o vazamento do docker (falha na liberação) de dados temporários gravados nesses volumes. Devemos mapear (para hospedar pastas ou outras solicitações de armazenamento persistentes) todas as pastas temporárias / logs / scratch do nosso contêiner onde nossos aplicativos gravam com frequência e / ou pesadamente. O Docker não se responsabiliza pela limpeza de todos os chamados EmptyDirs criados automaticamente e localizados por padrão em /var/lib/docker/overlay2/*/diff/*. O conteúdo dessas pastas "não persistentes" deve ser removido automaticamente pelo docker após o contêiner ser interrompido, mas aparentemente não é (pode ser impossível limpar do lado do host se o contêiner ainda estiver em execução - e pode estar em execução por meses de uma vez).

Gambiarra

Uma solução alternativa requer uma limpeza manual cuidadosa e, embora já tenha sido descrito em outro lugar, você ainda pode encontrar algumas dicas de meu estudo de caso, que tentei tornar o mais instrutivo e generalizável possível.

Então o que aconteceu é que o aplicativo culpado (no meu caso clair-scanner) conseguiu gravar ao longo de alguns meses centenas de gigs de dados na /diff/tmpsubpasta do dockeroverlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

Assim, como todas as subpastas /diff/tmperam autoexplicativas (todas tinham a mesma forma clair-scanner-*e datas de criação obsoletas), parei o contêiner associado ( docker stop clair) e removi cuidadosamente essas subpastas obsoletas diff/tmp, começando prudentemente com uma única (mais antiga), e testar o impacto no motor do docker (que exigiu reiniciar [ systemctl restart docker] para recuperar espaço em disco):

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

Recuperei centenas de GB de espaço em disco sem a necessidade de reinstalar o docker ou limpar suas pastas inteiras. Todos os contêineres em execução tiveram que ser interrompidos em um ponto, porque a reinicialização do daemon do docker foi necessária para recuperar espaço em disco, portanto, certifique-se primeiro de que seus contêineres de failover estejam funcionando corretamente em um / outro nó (s) Eu gostaria que o docker prunecomando pudesse cobrir o obsoleto /diff/tmp(ou mesmo/diff/* ) também (por meio de outra opção).

É um problema de 3 anos agora, você pode ler sua história rica e colorida nos fóruns do Docker, onde uma variante voltada para logs de aplicativos da solução acima foi proposta em 2019 e parece ter funcionado em várias configurações: https: // forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

mirekphd
fonte
5

AVISO: NÃO USE EM UM SISTEMA DE PRODUÇÃO

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

Ok, vamos primeiro tentar podar o sistema

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

Não tão bom, parece que limpou alguns megabytes. Vamos enlouquecer agora:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

Agradável! Lembre-se de que isso NÃO é recomendado em nada além de um servidor descartável. Neste ponto, o banco de dados interno do Docker não será capaz de encontrar nenhuma dessas sobreposições e isso pode causar consequências indesejadas.

Ravi Luthra
fonte
Alojar completamente o /var/lib/dockerdiretório (enquanto o daemon está parado e assumindo que o diretório não contém montagens especiais de sistema de arquivos ou similares) na verdade é uma maneira rápida e suja de voltar à estaca zero. Não sei por que você está recebendo todos os votos negativos. O Docker tenta se autocurar e reconhecerá quando todas as esperanças se perderem e reinicializará o /var/lib/dockerdiretório conforme necessário.
L0j1k
Puta merda, finalmente uma resposta funcional. Estou podando e fazendo outras coisas há 4 horas, mas deveria ter parado o serviço do docker, colocar tudo no lixo e reiniciá-lo.
Osi,
Ele funciona , mas também apenas exclui tudo que Docker produziu. Portanto, não é uma boa solução, por sessão.
Akito
2

NÃO FAÇA ISSO NA PRODUÇÃO

A resposta dada por @ ravi-luthra funciona tecnicamente, mas tem alguns problemas!

No meu caso, estava apenas tentando recuperar espaço em disco. A lib/docker/overlaypasta estava ocupando 30 GB de espaço e eu só executava alguns contêineres regularmente. Parece que o docker tem algum problema com vazamento de dados e alguns dos dados temporários não são apagados quando o contêiner para.

Então fui em frente e apaguei todo o conteúdo da lib/docker/overlaypasta. Depois disso, minha instância do docker tornou-se inutilizável. Quando tentei executar ou construir qualquer contêiner, recebi este erro:

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

Então, com algumas tentativas e erros, resolvi esse problema executando

(AVISO: isso excluirá todos os seus dados nos volumes do docker)

docker system prune --volumes -a

Portanto, não é recomendável fazer essas limpezas sujas, a menos que você entenda completamente como o sistema funciona.

Shankar Thyagarajan
fonte
1

Tudo em / var / lib / docker são sistemas de arquivos de contêineres. Se você parar todos os contêineres e removê-los, a pasta ficará vazia. Você provavelmente não quer isso, então não vá deletar coisas ali dentro. Não exclua coisas em / var / lib / docker diretamente. Você pode se safar às vezes, mas é desaconselhável por muitos motivos.

Em vez disso:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

O que você verá são os arquivos maiores mostrados na parte inferior. Se você quiser, descubra em quais recipientes esses arquivos estão, insira esses recipientes comdocker exec -ti containername -- /bin/sh e exclua alguns arquivos.

Você também pode fazer docker system prune -a -fum cron job diário / semanal, contanto que não deixe contêineres e volumes parados de seu interesse. É melhor descobrir os motivos do crescimento e corrigi-los no nível do contêiner.

Jason Hughes
fonte
0

Recentemente, tive um problema semelhante, overlay2 ficou cada vez maior, mas não consegui descobrir o que consumia a maior parte do espaço.

df me mostrou que overlay2 tinha cerca de 24 GB de tamanho.

Com dueu tentei descobrir o que ocupava o espaço ... e falhei.

A diferença veio do fato de que os arquivos excluídos (principalmente arquivos de log no meu caso) ainda estavam sendo usados ​​por um processo (Docker). Assim, o arquivo não aparece com, dumas o espaço que ocupa será mostrado comdf .

A reinicialização da máquina host ajudou. Reiniciar o contêiner do docker provavelmente já teria ajudado ... Este artigo em linuxquestions.org me ajudou a descobrir isso.

mhe
fonte
0

adicionando ao comentário acima, no qual as pessoas estão sugerindo remover o sistema como volumes pendentes, imagens, contêineres de saída etc. Às vezes, seu aplicativo se torna o culpado, ele gerou muitos logs em um curto período de tempo e se você usar um volume direto vazio (volumes locais ) isso preenche as partições / var. Nesse caso, achei o comando abaixo muito interessante de descobrir o que está consumindo espaço em meu disco de partição / var.

du -ahx / var / lib | sort -rh | cabeça -n 30

Este comando listará os 30 primeiros, que estão consumindo mais espaço em um único disco. Significa que se você estiver usando armazenamento externo com seus contêineres, consome muito tempo para executar o comando du. Este comando não contará os volumes de montagem. E é muito mais rápido. Você obterá os diretórios / arquivos exatos que estão consumindo espaço. Então você pode ir para esses diretórios e verificar quais arquivos são úteis ou não. se esses arquivos forem necessários, você pode movê-los para algum armazenamento persistente, fazendo alterações no aplicativo para usar o armazenamento persistente para esse local ou alterar a localização desses arquivos. E para descansar, você pode eliminá-los.

Amit Bondwal
fonte
0

Você pode limpar a pasta de sobreposição do docker sem afetar as instalações do docker usando os comandos abaixo.

sudo systemctl stop docker
sudo rm -r /var/lib/docker/overlay2
sudo mkdir /var/lib/docker/overlay2
sudo systemctl start docker
SaiPawan
fonte
-5

Eu usei "docker system prune -a" para limpar todos os arquivos em volumes e overlay2

    [root@jasontest volumes]# docker system prune -a
    WARNING! This will remove:
            - all stopped containers
            - all networks not used by at least one container
            - all images without at least one container associated to them
            - all build cache
    Are you sure you want to continue? [y/N] y
    Deleted Images:
    untagged: ubuntu:12.04
    untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
    deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
    deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
    deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
    deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
    deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
    deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
    untagged: osixia/openldap:1.2.1
    untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
    deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
    deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
    deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
    deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
    deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
    deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
    deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
    deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
    deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
    untagged: centos:centos7
    untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
    deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
    deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7

    Total reclaimed space: 533.3MB
    [root@jasontest volumes]# ls -alth
    total 32K
    -rw-------  1 root root  32K May 23 21:14 metadata.db
    drwx------  2 root root 4.0K May 23 21:14 .
    drwx--x--x 14 root root 4.0K May 21 20:26 ..
user1681424
fonte
3
Este comando não responde à pergunta. O comando proposto está até mesmo escrito no texto da pergunta ..
MBT
então esta votação foi reduzida a cinzas, mas a mesma resposta exata abaixo foi votada 41 vezes. Este site está quebrado.
Adam Zahran