É seguro limpar docker / overlay2 /

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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 ..