docker / overlay2 /를 청소하는 것이 안전합니까?

109

AWS EC2에서 실행중인 일부 도커 컨테이너가 있는데 / var / lib / docker / overlay2 폴더는 디스크 크기가 매우 빠르게 증가합니다.

콘텐츠를 삭제해도 안전한지 궁금합니다. 또는 docker에 디스크 사용량을 늘리는 일종의 명령이 있습니다.

최신 정보:

나는 실제로 docker system prune -a이미 0Kb를 회수했습니다.

또한 내 / docker / overlay2 디스크 크기가 출력보다 훨씬 큽니다. docker system df

도커 문서와 BMitch의 답변을 읽은 후이 폴더를 만지는 것이 어리석은 생각이라고 생각하며 디스크 공간을 확보하기 위해 다른 방법을 시도 할 것입니다.

docker  docker-compose  docker-machine 
— qichao_he
소스
이것에 대한 답을 찾았습니까? 나는 여전히 같은 문제가 발생합니다.
— Saurabh_Jhingan
1
나는 도망 docker image prune --all다음과 docker system prune -a. / var / lib / docker / overlay2 아래의 파일에서 사용하던 디스크 공간을 약 50GB까지 회수했습니다. 그러나 docker system prune -a충분했을 것입니다. 또한 내 구성 세부 사항은 다음 OS: Ubuntu 20과 같습니다. ,Docker : 19.03.12
— Binita Bharati

답변:

73

Docker는 / var / lib / docker를 사용하여 이미지, 컨테이너 및 로컬 명명 된 볼륨을 저장합니다. 이를 삭제하면 데이터가 손실되고 엔진 실행이 중지 될 수 있습니다. overlay2 하위 디렉토리에는 특히 이미지 및 컨테이너에 대한 다양한 파일 시스템 계층 이 포함되어 있습니다.

사용하지 않는 컨테이너 및 이미지를 정리하려면을 참조하십시오 docker system prune. 볼륨 및 태그가 지정된 이미지를 제거하는 옵션도 있지만 데이터 손실 가능성으로 인해 기본적으로 활성화되어 있지 않습니다.

— BMitch
소스
1
대답은 동일합니다 (볼륨을 제외 할 수 있다는 점만 제외). 거기에서 물건을 지우고 부 수면 두 조각을 모두 유지할 수 있습니다. 이 작업에 제공된 도구를 사용하십시오.
— BMitch 2017-10-10
1
overlay2 폴더에는 이미지와 컨테이너에 필요한 파일 시스템 레이어가 있어야합니다. 이 조언을 무시할 수는 있지만 고장난 시스템을 복구하는 방법에 대한 조언을 요청하지 마십시오. 특히 파일 시스템을 정리할 수있는 지원 방법을 제공했기 때문입니다.
— BMitch 2010
21
docker system prune -a0kb 공간을 복구 한을 시도했습니다 . 지금은 / docker / overlay2 디스크 크기가 docker system df. 이것이 제가이 문제를 계속 파헤치는 이유입니다. 다시 한 번 답장 해 주셔서 감사합니다. 도커 문서에 대해 더 많이 읽어야하거나 도커를 완전히 지우고 다시 시작해야한다고 생각합니다. 유지해야하는 postgres 데이터베이스 만 있고 마운트했습니다
— qichao_he
9
나는 "지원되는"방법이 나에게도 효과가 없다고 말할 것입니다. 모든 docker 시스템 prune -a, docker volume prune, docker image prune 및 docker container prune을 수행하면 여전히 Docker에서 사용하는 디스크의 80 %가 남습니다. 그것은 모든 컨테이너가 중지 된 상태입니다.
— Craig Brett
1
@franzisk를 사용 /var/lib/docker하여 일관되지 않은 상태로 유지되는 단일 하위 디렉토리가 아닌 모두 삭제하려는 모든 것을 지우십시오 .
— BMitch
52

나는 이것이 나를 위해 가장 잘 작동한다는 것을 알았습니다.

docker image prune --all

기본적으로 Docker는 이름이 지정된 이미지가 사용되지 않더라도 제거하지 않습니다. 이 명령은 사용하지 않는 이미지를 제거합니다.

이미지의 각 레이어는 폴더 내부의 /usr/lib/docker/overlay2/폴더입니다.

— Sarke
소스
3
'이미지 정리'는 '시스템 정리'보다 훨씬 잘 작동했습니다. 감사!
— DavidG
경고! 이것은 실행되지 않는 컨테이너의 모든 이미지를 제거하므로 상당히 구조적입니다. 그들이 귀하의 것이고 아직 레지스트리로 푸시되지 않은 경우 몇 시간 동안 다시 빌드하게됩니다. 그러나 그것은 여전히 docker system df보여 지는 것 이상으로 갈 수 없습니다 (당신은 여전히 ​​공간이 overlay2
— 부족할
네, 이미지를 제거합니다.
— Sarke
주의 : 내가 docker swarm을 사용한 경우에는 컨테이너를 실행하는 경우에도 태그가 지정된 모든 이미지도 삭제되었습니다
— velop
이것은 효과가 있었지만 구매자는 이것이 컨테이너에없는 모든 것을 제거한다는 점에 유의하십시오.
— jimh
30

이 문제가 있었어요 ... 엄청나게 큰 통나무 였어요. 로그는 다음과 같습니다.

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

실행 명령 줄 또는 작성 파일에서이를 관리 할 수 ​​있습니다. 보기 : 로깅 드라이버 구성

개인적으로이 3 줄을 docker-compose.yml 파일에 추가했습니다.

my_container:
  logging:
    options:
      max-size: 10m
— 트리스탄
소스
2
링크에서 답변에 대한 몇 줄을 추가 할 수 있습니까?
— RtmY
거대한 로그 파일이있는 컨테이너를 식별하는 방법에 대한 정보를 얻는 것도 좋을 것입니다. 나는 많은 컨테이너와 로그 파일을 가지고 있으며, 일부는 거대한 일부는 작습니다.
— Micah Zoltu
OP 질문에 대한 답은 무엇입니까?!
— Slavik Meltser
2
이 답변은 특히 '로그'가 문제인 경우 부분적인 답변입니다 (일부 수정으로 개선 할 수 있습니까?). 이 대답을 볼 때까지 나는 지나치게 가득 찬에서 큰 디렉토리를 무작위로 삭제하기 시작했습니다 overlay2. 필자의 경우 총 용량 /var/lib/docker은 50GB 였고 36GB는 하나의 파일에서 사용되었습니다 /var/lib/docker/overlay2/<container id>/diff/var/log/faillog. 이 파일이 모든 것을 계속 실행하는 데 핵심이 아니라고 가정 할 때, 단기 해킹은 파일을 제거하는 것입니다 (또한 저도 조정할 것입니다 docker-compose).
— D. Woods
19

또한 빠르게 성장하는 데 문제가있었습니다 overlay2

/var/lib/docker/overlay2-Docker가 컨테이너에 대한 쓰기 가능한 레이어를 저장하는 폴더입니다. docker system prune -a-용기가 중지되고 제거 된 경우에만 작동 할 수 있습니다.

나는 들어가서 overlay2조사 함으로써 무엇이 공간을 소비하는지 알아낼 수있었습니다 .

해당 폴더에는 다른 해시 이름 폴더가 있습니다. 각각 폴더를 포함하여 여러 폴더가 있습니다 diff.

diff 폴더-컨테이너와 정확한 폴더 구조를 가진 컨테이너에 의해 작성된 실제 차이점이 포함되어 있습니다 (적어도 내 경우에는 우분투 18 ...)

그래서 나는 내 컨테이너 내부가 오염되는 폴더라는 du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp것을 알아내는 데 사용 했습니다/tmp .

해결 방법 -v /tmp/container-data/tmp:/tmp으로 docker run명령 매개 변수를 사용 하여 내부 /tmp폴더를 호스트 에 매핑 하고 호스트에 cron을 설정하여 해당 폴더를 정리했습니다.

cron 작업은 간단했습니다.

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

참고 : overlay2시스템 도커 폴더이며 언제든지 구조를 변경할 수 있습니다. 위의 모든 것은 내가 거기서 본 것을 기반으로합니다. 시스템이 완전히 공간이 부족하고 도커 컨테이너로 ssh하는 것을 허용하지 않았기 때문에 도커 폴더 구조로 이동해야했습니다.

— user2932688
소스
이 답변에 감사 드리며, 많은 .NET Framework를 생성하는 오래된 데이터베이스 / 앱을 컨테이너에 넣었습니다 /var/log/apache2/error.log. 내가하는 error.log를 재설정하고 access.log의 쉬운 관리 할 수 있도록 새 볼륨을 추가
— bcag2
6

배경

이 문제에 대한 책임은 컨테이너 볼륨의 잘못된 구성과 이러한 볼륨에 기록 된 임시 데이터의 도커 유출 (릴리스 실패) 문제로 나눌 수 있습니다. 우리는 앱이 자주 그리고 / 또는 많이 쓰는 컨테이너의 임시 / 로그 / 스크래치 폴더를 모두 매핑 (호스팅 폴더 또는 기타 영구 스토리지 클레임)해야합니다. Docker는 기본적으로 .NET Core에있는 자동 생성 된 소위 EmptyDirs의 정리를 책임지지 않습니다 /var/lib/docker/overlay2/*/diff/*. 이러한 "비 영구"폴더의 내용은 컨테이너가 중지 된 후 docker에 의해 자동으로 제거되어야하지만 분명히 그렇지 않습니다 (컨테이너가 아직 실행중인 경우 호스트 측에서 제거하는 것이 불가능할 수도 있으며 몇 달 동안 실행할 수 있음). 한 번에).

해결 방법

해결 방법에는 신중한 수동 정리가 필요하며 이미 다른 곳에서 설명했지만 가능한 한 교육적이고 일반화 할 수 있도록 노력한 사례 연구에서 몇 가지 힌트를 찾을 수 있습니다.

그래서 일어난 일은 (제 경우에는 clair-scanner) /diff/tmp도커의 하위 폴더에 몇 달에 걸쳐 수백 기가의 데이터를 쓸 수 있었던 범인 앱 입니다.overlay2

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

271G total

따라서의 모든 하위 폴더 /diff/tmp가 매우 자명하기 때문에 (모두 형식 clair-scanner-*이었고 생성 날짜가 사용되지 않음) 관련 컨테이너 ( docker stop clair)를 중지 하고이 오래된 하위 폴더를에서 조심스럽게 제거 diff/tmp하여 하나의 (가장 오래된) 하위 폴더 부터 신중하게 시작했습니다. Docker 엔진에 미치는 영향 테스트 ( systemctl restart docker디스크 공간을 확보 하려면 다시 시작 [ ] 이 필요함 ) :

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)

Docker를 다시 설치하거나 전체 폴더를 제거 할 필요없이 수백 기가 바이트의 디스크 공간을 회수했습니다. 디스크 공간을 확보하려면 docker 데몬을 다시 시작해야했기 때문에 실행중인 모든 컨테이너를 한 지점에서 중지해야했기 때문에 먼저 장애 조치 컨테이너가 / 다른 노드에서 올바르게 실행되고 있는지 확인하세요. docker prune명령이 구식 /diff/tmp(또는 심지어 /diff/*다른 스위치를 통해) 데이터도 포함 할 수 있기를 바랍니다 .

이제 3 년 된 문제입니다. Docker 포럼에서 풍부하고 다채로운 역사를 읽을 수 있습니다. 여기서 위 솔루션의 애플리케이션 로그를 겨냥한 변형이 2019 년에 제안되었으며 여러 설정에서 작동 한 것으로 보입니다 : https : // forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

— Mirekphd
소스
5

경고 : 생산 시스템에서 사용하지 마십시오.

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

좋습니다. 먼저 시스템 정리를 시도해 보겠습니다.

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

그렇게 좋지는 않지만 몇 메가 바이트를 정리 한 것 같습니다. 이제 미쳐 보자 :

/# 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% /
...

좋은! 일회용 서버 외에는 권장되지 않습니다. 이 시점에서 Docker의 내부 데이터베이스는 이러한 오버레이를 찾을 수 없으며 의도하지 않은 결과를 초래할 수 있습니다.

— 라비 루트 라
소스
/var/lib/docker(데몬이 중지되고 디렉토리에 특별한 파일 시스템 마운트 등이 없다고 가정하는 동안) 디렉토리를 완전히 호징하는 것은 사실 원점으로 돌아가는 빠르고 더러운 방법입니다. 왜 당신이 모든 반대표를 받는지 모르겠습니다. Docker는자가 치유를 시도하며 모든 희망이 사라질 때를 인식 /var/lib/docker하고 필요에 따라 디렉토리를 다시 초기화 합니다.
— L0j1k
거룩한 **** 마침내 작동하는 대답. 나는 4 시간 동안 가지 치기와 일을 해왔지만 방금 도커 서비스를 중지하고 모든 것을 쓰레기통에 넣고 다시 시작해야했습니다.
— Osi
그것은 작동 하지만, 그것은 또한 단지 부두 노동자가 생산 한 모든 것이 삭제합니다. 그래서 sé 당 좋은 해결책이 아닙니다 .
— Akito 2011
2

프로덕션에서는이 작업을 수행하지 마십시오.

@ ravi-luthra의 답변은 기술적으로 작동하지만 몇 가지 문제가 있습니다!

제 경우에는 디스크 공간을 복구하려고했습니다. lib/docker/overlay폴더 공간 30GB의를 복용하고 있었고, 난 단지 정기적으로 몇 컨테이너를 실행합니다. docker에 데이터 유출 문제가 있으며 컨테이너가 중지되면 일부 임시 데이터가 지워지지 않는 것 같습니다.

그래서 계속해서 lib/docker/overlay폴더의 모든 내용을 삭제했습니다 . 그 후 내 도커 인스턴스를 사용할 수 없게되었습니다. 컨테이너를 실행하거나 빌드하려고 할 때 다음 오류가 발생했습니다.

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

그런 다음 시행 착오를 거쳐 다음을 실행하여이 문제를 해결했습니다.

(경고 : 이것은 도커 볼륨 내의 모든 데이터를 삭제합니다)

docker system prune --volumes -a

따라서 시스템 작동 방식을 완전히 이해하지 않는 한 이러한 더러운 청소를 수행하지 않는 것이 좋습니다.

— 샨 카르 티야 가라 잔
소스
1

/ var / lib / docker에있는 모든 것은 컨테이너의 파일 시스템입니다. 모든 컨테이너를 중지하고 정리하면 폴더가 비어있게됩니다. 당신은 아마 그것을 원하지 않을 것입니다. 그래서 거기에서 무작위로 물건을 삭제하지 마십시오. / var / lib / docker에서 직접 삭제하지 마십시오. 때로는 그것을 피할 수 있지만 여러 가지 이유로 바람직하지 않습니다.

대신 다음을 수행하십시오.

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

당신이 보게 될 것은 하단에 표시된 가장 큰 파일입니다. 원하는 경우 해당 파일이 어떤 컨테이너에 있는지 확인하고 해당 컨테이너를 입력 docker exec -ti containername -- /bin/sh하고 일부 파일을 삭제하십시오.

docker system prune -a -f관심있는 컨테이너와 볼륨을 중지하지 않는 한 매일 / 주간 크론 작업을 수행 할 수도 있습니다 . 성장하는 이유를 파악하고 컨테이너 수준에서 수정하는 것이 좋습니다.

— 제이슨 휴즈
소스
0

최근에 비슷한 문제가 발생했습니다. overlay2가 점점 더 커졌지 만 무엇이 많은 공간을 차지하는지 파악할 수 없었습니다.

df overlay2의 크기가 약 24GB라는 것을 보여주었습니다.

와 du나는 공간을 점유 ... 실패 무엇을 알아 내려고 노력했다.

차이점은 프로세스 (Docker)에서 여전히 사용중인 파일 (제 경우에는 대부분 로그 파일)을 삭제했기 때문입니다. 따라서 파일은로 표시되지 않지만 du차지하는 공간은로 표시됩니다 df.

호스트 머신의 재부팅이 도움이되었습니다. 도커 컨테이너를 다시 시작하는 것은 아마도 이미 도움이되었을 것입니다 . linuxquestions.org 의이 기사 는 저를 이해하는 데 도움이되었습니다.

— mhe
소스
0

사람들이 명확한 매달린 볼륨, 이미지, 출구 컨테이너 등과 같은 시스템을 정리할 것을 제안하는 위의 주석에 추가합니다. 언젠가 앱이 범인이되어 짧은 시간에 너무 많은 로그를 생성하고 빈 직접 볼륨 (로컬 볼륨)을 사용하는 경우 ) 이것은 / var 파티션을 채 웁니다. 이 경우 아래 명령이 내 / var 파티션 디스크에서 공간을 소비하는 것이 무엇인지 알아내는 데 매우 흥미 롭다는 것을 알았습니다.

du -ahx / var / lib | 정렬 -rh | 머리 -n 30

이 명령은 단일 디스크에서 가장 많은 공간을 차지하는 상위 30 개를 나열합니다. 컨테이너와 함께 외부 저장소를 사용하는 경우 du 명령을 실행하는 데 많은 시간이 걸립니다. 이 명령은 마운트 볼륨을 계산하지 않습니다. 그리고 훨씬 빠릅니다. 공간을 차지하는 정확한 디렉토리 / 파일을 얻을 수 있습니다. 그런 다음 해당 디렉토리로 이동하여 어떤 파일이 유용한 지 여부를 확인할 수 있습니다. 이러한 파일이 필요한 경우 해당 위치에 영구 저장소를 사용하도록 앱을 변경하거나 해당 파일의 위치를 ​​변경하여 영구 저장소로 이동할 수 있습니다. 그리고 휴식을 위해 그들을 지울 수 있습니다.

— 아밋 본드 월
소스
0

아래 명령을 사용하여 도커 설치에 영향을 미치지 않고 도커 오버레이 폴더를 정리할 수 있습니다.

sudo systemctl stop docker
sudo rm -r /var/lib/docker/overlay2
sudo mkdir /var/lib/docker/overlay2
sudo systemctl start docker
— 사이파 완
소스
-5

"docker system prune -a"를 사용하여 볼륨 및 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
소스
3
이 명령은 질문에 대한 답을 제공하지 않습니다. 제안 된 명령은 질문 텍스트에도 기록되어 있습니다.
— MBT
그래서 이것은 재로 비추천되지만 아래의 똑같은 정확한 대답은 41 번 찬성됩니다. 이 사이트는 손상되었습니다.
— Adam Zahran
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.