# docker --version
Docker version 1.10.3, build 99b71ce

# docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29
Server Version: 1.10.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 99
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.13.0-83-generic
Operating System: <unknown>
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.9 GiB
Name: dev34-devc
ID: VKMX:YMJ2:3NGV:5J6I:5RYM:AVBK:QPOZ:ODYE:VQ2D:AF2J:2LEM:TKTE
WARNING: No swap limit support

또한 docker가 컨테이너, 볼륨 또는 이미지를 나열하지 않음을 보여야합니다.

$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

$ docker volume ls
DRIVER              VOLUME NAME

이상한; 특히 때문에;

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29

docker images / docker ps 의 출력과 일치하지 않습니다.

어떤 운영 체제에서 실행 중입니까?

Operating System: <unknown>

@tonistiigi 어떤 아이디어?

그 후였습니다. 그동안 일부 프로세스가 시작된 것 같습니다.

내가 말하는 상태 (지금 가지고 있음)는 다음과 같습니다.

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0

그리고 나는 여전히 가지고 있습니다.

$ sudo du -hs /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
296M    /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea

우리는 업그레이드 된 커널로 Ubuntu Lucid에 있습니다 = /

$ uname -a
Linux dev34-devc 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.1 LTS
Release:        10.04
Codename:       lucid

흥미로운 문제인 것 같습니다.
그것을 재현 할 수있는 방법이 있습니까? 멍멍

확실히 가능하지만 방법을 모르겠습니다.
활성 Docker 호스트 중 하나에서 아래 스크립트를 실행하고 남은 내용을 확인하십시오.
우리의 경우에는 항상 많은 diff가 남아 있습니다.

```#! bash

! / bin / bash

set -eu

echo "경고 :: 모든 docker 프로세스를 중지하고 모든 docker 이미지를 제거합니다."
읽기 -p "계속 (y / n)?"
if [ "$ REPLY"! = "y"]; 그때
echo "중단 중."
1 번 출구
fi

xdocker () {exec xargs -P10 -r -n1 --verbose docker "$ @"; }

-x 설정

용기를 제거하다

도커 ps -q | xdocker 중지
도커 ps -aq | xdocker rm

태그 제거

도커 이미지 | sed 1d | grep -v '^'| 열 1 2 | sed 's / / : /'| xdocker rmi

이미지 제거

도커 이미지 -q | xdocker rmi
도커 이미지 -aq | xdocker rmi

볼륨 제거

도커 볼륨 ls -q | xdocker 볼륨 rm
```

이런 일이 발생하는 것을 볼 수있는 한 가지 가능한 방법은 aufs 마운트 해제에 오류가있는 경우입니다. 예를 들어 EBUSY 오류가있는 경우 이미지 구성이 이전에 이미 삭제되었을 수 있습니다.

@bukzor 빈 그래프 디렉토리에서 시작하여 이미지를 가져 와서 실행하고 스크립트를 실행 한 후 완전히 정리되지 않는 상태로 만드는 재현

흥미 롭 겠지만 하루 종일 작업 한 것 같습니다.
나는 그것을 할 수 없습니다.

a800 위의 (임의로 선택된) 문제가되는 diff에 대한 추가 데이터가 있습니다.

```#! sh
$ docker-find a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | sudo xargs -n1 wc -l | 정렬 -rn

• sudo find / nail / var / lib / docker '('-path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
• sudo find / nail / var / lib / docker '('-path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep -l a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  15 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / nail / var / lib / docker / aufs / layers / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / nail / var / lib / docker / aufs / layers / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / nail / var / lib / docker / aufs / layers / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / nail / var / lib / docker / aufs / layers / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / nail / var / lib / docker / aufs / layers / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / nail / var / lib / docker / aufs / layers / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / nail / var / lib / docker / aufs / layers / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / nail / var / lib / docker / aufs / layers / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nail / var / lib / docker / aufs / layers / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / nail / var / lib / docker / aufs / layers / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / nail / var / lib / docker / image / aufs / layerdb / sha256 / d1c659b8e3d0e893e95c8eedc755adcb91a1c2022e1090376b451f7206f9b1c0 / cache-id

So we see there's a chain of child layers, with `f3286009193` as the tip.

$ docker-find f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 '$'

• sudo find / nail / var / lib / docker '('-path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• sudo find / nail / var / lib / docker '('-path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep --color -l 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id

So that layer was used in mount `eb809c0321`. I don't find any references to that mount anywhere:

$ docker-find eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e

• sudo find / nail / var / lib / docker '('-path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / init-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / parent
• sudo find / nail / var / lib / docker '('-path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep -color -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  ```

마운트가 사용 된 컨테이너를 찾을 수있는 방법이 있습니까?
문서는 마운트 ID가 더 이상 컨테이너 ID와 같지 않다고 만 말하는데, 이는별로 도움이되지 않습니다.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 는 컨테이너 ID입니다. 문서의 의미는 aufs id (귀하의 경우 f3286009193f )가 컨테이너 ID가 아니라는 것입니다.

/ cc @dmcgowan 도

@tonistiigi 좋아요.

그렇다면 분명히 산은 컨테이너보다 오래되었습니다.

컨테이너 수명주기의 어느 시점에서 마운트가 정리됩니까?
실행 / 중지 된 컨테이너에 대한 임시 쓰기 가능 auf입니까?

@bukzor (rw) 마운트는 컨테이너 삭제시 삭제됩니다. 컨테이너 프로세스 중지시 마운트 해제가 발생합니다. Diff 폴더는 개별 레이어 콘텐츠가 저장되는 장소입니다. 레이어가 마운트되었는지 여부는 중요하지 않습니다.

@bukzor aufs ID와 컨테이너 ID 사이의 링크는 image/aufs/layerdb/mounts/<container-id>/mount-id 에서 찾을 수 있습니다. aufs ID를 알기 만해도 컨테이너 ID를 찾는 가장 쉬운 방법은 image/aufs/layerdb 디렉토리를 grep하는 것입니다. 아무것도 발견되지 않으면 정리가 깨끗하게 완료되지 않은 것입니다.

비슷한 문제가 발생합니다.

Docker 데몬 서버에서 매일 CI를 실행하고 있습니다. / var / lib / docker / aufs / diff는 디스크 용량을 상당히 많이 차지합니다.

여기 또는 관련 스레드 (위의 @bukzor 의 bash 스크립트 포함)에서 제안 된 합리적인 모든 것을 시도한 후에도 2gb 에서 aufs/diff 여전히 있습니다.

적절한 수정이 부족합니다. 다른 모든 이미지를 동시에 제거하지 않고 남은 마운트를 제거하는 간단한 방법이 있습니까? (현재 실행중인 컨테이너가 없다면 마운트가 없어야 할 것 같군요?)

동일한 문제가 발생합니다. 이 컴퓨터를 사용하여 많은 컨테이너를 테스트 한 다음 커밋 / 삭제합니다. 내 / var / lib / docker / aufs 디렉토리는 현재 7.9G 무겁습니다. 이 디렉토리의 저장 공간이 제한되어 있기 때문에이 디렉토리를 다른 마운트 지점으로 이동해야합니다. :(

# du -sh /var/lib/docker/aufs/diff/
1.9T    /var/lib/docker/aufs/diff/

@mcallaway aufs/diff 모든 것은 컨테이너에서 수행되는 fs 쓰기가 될 것입니다.

나는 같은 문제가 있습니다. 내가 가진 모든 컨테이너는 실행 상태에 있지만 이러한 컨테이너와 관련이없고 오래된 제거 된 컨테이너와 관련된 많은 aufs diff 디렉토리가 있습니다. 수동으로 제거 할 수 있지만 옵션은 아닙니다. 그러한 행동에는 이유가 있어야합니다.

k8s 1.3.5와 docker 1.12를 사용합니다.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc 도움이되었습니다.

나는 같은 문제가 있습니다. dind (도커의 도커)와 함께 Gitlab CI를 사용하고 있습니다.

IMHO 레지스트리의 이미지가 동일한 태그 내에서 업데이트되고 가져 왔을 때 관련 컨테이너가 다시 시작되고 spotify/docker-gc 를 실행하지 않으면 이전 컨테이너와 이미지가 GCed되지 않습니다.

다른 사람이 이것을 확인할 수 있습니까?

@kayrus가 맞습니다. docker는 "태그가없는"이미지도 _removed_되어야한다고 자동으로 가정하지 않습니다. 컨테이너는 여전히 해당 이미지를 사용할 수 있으며 해당 이미지에서 새 컨테이너를 계속 시작할 수 있습니다 (ID로 참조). docker rmi $(docker images -qa -f dangling=true) 사용하여 "매달려있는"이미지를 제거 할 수 있습니다. 또한 docker 1.13은 데이터 관리 명령 (https://github.com/docker/docker/pull/26108 참조)을 가져와 사용하지 않는 이미지, 컨테이너 등을보다 쉽게 ​​정리할 수 있습니다.

@thaJeztah 는 /var/lib/docker/aufs/diff/ 실제로 "태그가없는"이미지를 포함합니까?

@kayrus 예 그들은 이미지의 일부입니다 (태그 및 태그 없음)

유사한 문제, 컨테이너 / 이미지 / 볼륨 없음, ~ 13Gb의 diff 발생

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1030
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.861 GiB
Name: gitrunner
ID: GSAW:6X5Z:SHHU:NZIM:O76D:P5OE:7OZG:UFGQ:BOAJ:HJFM:5G6W:5APP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

$ docker volume ls
DRIVER              VOLUME NAME
$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$

$ df -h
Filesystem                                 Size  Used Avail Use% Mounted on
...
/dev/mapper/gitrunner--docker-lib--docker   18G   15G  2.6G  85% /var/lib/docker

/var/lib/docker# sudo du -sm aufs/*
13782   aufs/diff
5       aufs/layers
5       aufs/mnt

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: xfs
 Dirs: 1122

여기에도 같은 문제가 있습니다. 1.13이 데이터 관리 명령을받을 수 있다는 것을 이해하지만 그 동안 Docker를 죽이지 않고이 디렉터리의 내용을 안전하게 삭제하고 싶습니다.

이것은이 시점에서 상대적으로 차단됩니다.

여기도 마찬가지입니다. 아직 공식적인 해결책이 없습니까?

(Docker Community) Slack에서이 문제를 여러 번 불러 왔습니다. 소수의 사람들이 가비지 컬렉션 스크립트 / cmd 목록을 실행할 때마다 솔루션으로 실행해야합니다.

그 사이에 도움이되었지만 (읽기 : 해결되지 않음-공간이 여전히 가득 차고 있음), 이것이 이상적인 장기 수정이 아니라는 데 모두 동의 할 수 있다고 생각합니다.

@jadametz 1.13에는 docker system prune 있습니다.
그 외에도 Docker가 어떻게 도움이 될 수 있는지 잘 모르겠습니다 (제안에 개방). 이미지는 자체적으로 시스템에 도달하는 것이 아니라 끌어 오기, 빌드 등을 통해 이루어집니다.

실제 고아 레이어 (시스템에서 참조하는 이미지 없음)와 관련하여 별도로 해결해야합니다.

나는 똑같은 문제가 있습니다!

docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 1.12.1 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 2501 Dirperm1 Supported: false Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host null overlay Swarm: inactive Runtimes: runc Default Runtime: runc Security Options: apparmor Kernel Version: 3.13.0-96-generic Operating System: Ubuntu 14.04.2 LTS OSType: linux Architecture: x86_64 CPUs: 8 Total Memory: 14.69 GiB Name: ip-172-31-45-4 ID: R5WV:BXU5:AV6T:GZUK:SAEA:6E74:PRSO:NQOH:EPMQ:W6UT:5DU4:LE64 Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): false Registry: https://index.docker.io/v1/ WARNING: No swap limit support Insecure Registries: 127.0.0.0/8

이미지, 컨테이너 또는 볼륨이 없습니다. aufs / diff에서 42Gb

이 디렉토리를 안전하게 지우는 데 도움이되는 모든 것이 매우 유용합니다! 이 스레드의 모든 것을 성공하지 못했습니다. 감사.

@adamdry 전용 타사 스크립트 : https://github.com/docker/docker/issues/22207#issuecomment -252560212

감사합니다 @kayrus 나는 실제로 그것을 시도했고 그것은 나의 총 디스크 사용량을 약간 증가 시켰고 aufs / diff 디렉토리에 아무것도하지 않는 것처럼 보였다.

실행되지 않은 docker system prune 도 시도했습니다. 그리고 제거 할 이미지를 찾지 못한 docker rmi $(docker images -qa -f dangling=true) 시도했습니다.

관심있는 사람을 위해 나는 이제 이것을 사용하여 모든 컨테이너, 이미지, 볼륨 및 오래된 auf를 정리하고 있습니다.

### FYI I am a Docker noob so I don't know if this causes any underlying issues but it does work for me - use at your own risk ###

여기에서 얻은 많은 영감 : http://stackoverflow.com/questions/30984569/error-error-creating-aufs-mount-to-when-building-dockerfile

docker rm -f $(docker ps -a -q) && docker rmi -f $(docker images -q) && docker rmi -f $(docker images -a -q)
service docker stop
rm -rf /var/lib/docker/aufs
rm -rf /var/lib/docker/image/aufs
rm -f /var/lib/docker/linkgraph.db
service docker start

@adamdry 제거시 오류를 숨길 수 있으므로 rm / rmi를 수행 할 때 -f 사용하지 않는 것이 가장
저는 현재 상황을 고려합니다. -f 가 오류를 숨기면 사용자에게 완전히 보이지 않는 남은 상태가 남아 있습니다. 버그로.

나는 또한 완전히 새롭고 놀라운 설치에서 이것을보고 있습니다.

root<strong i="6">@builder</strong>:/var/lib/docker# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.4
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 63
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay host null bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.625 GiB
Name: builder
ID: 2WXZ:BT74:G2FH:W7XD:VVXM:74YS:EA3A:ZQUK:LPID:WYKF:HDWC:UKMJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
 127.0.0.0/8
root<strong i="7">@builder</strong>:/var/lib/docker# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
root<strong i="8">@builder</strong>:/var/lib/docker# docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
root<strong i="9">@builder</strong>:/var/lib/docker# du -hd2
4.0K    ./swarm
6.0M    ./image/aufs
6.0M    ./image
4.0K    ./trust
28K ./volumes
4.0K    ./containers
276K    ./aufs/layers
292K    ./aufs/mnt
1.5G    ./aufs/diff <-------------------------
1.5G    ./aufs
4.0K    ./tmp
72K ./network/files
76K ./network
1.5G    .
root<strong i="10">@builder</strong>:/var/lib/docker# 

@robhaswell 새로운 설치이므로 이것을 시도 하시겠습니까? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry 내 작업을 차단했기 때문에 이미 /var/lib/docker/aufs 를) 삭제했습니다. 당신은 당신의 지시가 무엇을 성취하기를 기대합니까? 나중에 문제가 다시 발생하지 않게되면 문제를 재현하고 안내를 시도해 볼 수 있습니다. 그러나 목적이 공간을 확보하는 것이라면 이미 달성 한 것입니다.

@robhaswell 예, 디스크 공간을 확보하는 것이었지만 이미지를 다시 빌드하려고 할 때 후속 문제가 있었지만 해당 스크립트의 모든 단계를 수행하여 해당 문제를 해결했습니다.

빌드 중에 레이어 빌드 프로세스 (복사 할 Blob도 포함) 중에 빌드 프로세스가 중단되고 컨테이너가 중지되면 / var / lib / docker / aufs / diff /에 데이터가 남습니다. 매달린 이미지가 나타났습니다. 청소도 공간을 확보하지 못했습니다. Docker 시스템 정리의 일부로 포함 할 수 있습니까? 이 폴더 내의 Blob 데이터를 삭제하는 것만으로 공간을 확보 할 수 있으며 문제가 발생하는지 확실하지 않습니다.

Docker 버전 : 1.13.0-rc1

빌드 중에 레이어 빌드 프로세스 (복사 할 Blob도 포함) 중에 빌드 프로세스가 중단되고 컨테이너가 중지되면 데이터가 남습니다.

이것은 내 문제의 원인 일 수도 있습니다. 많은 빌드를 중단합니다.

docker pull 동안 다음 두 가지 경우를 관찰했습니다.

1. 프로세스가 다운로드 (/ var / lib / docker / tmp /에 이미지 레이어를 다운로드 함)라고 말할 때 중단되면 해당 폴더의 모든 데이터를 정리합니다.
2. 추출 중이라고 말할 때 프로세스가 중단되면 (tmp에서 / var / lib / docker / aufs / diff /로 레이어를 추출한다고 가정합니다), tmp 및 diff blob 데이터를 모두 정리합니다.

이미지 빌드 과정에서

1. "빌드 컨텍스트를 도커 데몬으로 전송"(내 경우에는 / var / lib / docker / tmp /에서 blob 데이터를 복사) 할 때 프로세스를 중단하면 영구적으로 남아 있으며 수동으로 삭제하는 것 외에는 어떤 명령으로도 정리할 수 없습니다. 이미지의 업데이트가 어떻게 처리되는지 잘 모르겠습니다.
2. 대규모 소프트웨어 설정과 같이 Blob 데이터를 포함하는 레이어가 빌드되는 동안 프로세스가 중단되면 도커 컨테이너가 이미지에서 계속 작업합니다. 제 경우에는 이미 tmp 폴더에서 사용할 수있는 1 개의 레이어 blob 데이터 만 전체 이미지를 구성합니다. 그러나 docker stop 명령을 사용하여 컨테이너를 중지하면 두 가지 경우가 발생합니다.
   ㅏ. 마운트 프로세스가 계속 발생하면 tmp 및 diff 폴더에 데이터가 남습니다.
   비. 데이터가 diff 폴더에 복사되면 tmp 폴더에서 데이터를 제거하고 diff 폴더에 데이터를 남겨두고 폴더를 마운트 할 수 있습니다.

빌드 프로세스를 정상적으로 중지하려면 제어가 필요한 자동화 된 빌드 프로세스가 있습니다. 최근에 구성이 낮은 시스템의 메모리 부족 오류로 인해 프로세스가 커널에 의해 종료되었습니다.

하나의 이미지가 2 개의 레이어로 빌드되고 1 개의 레이어가 빌드되고 두 번째가 중단되면 Docker 시스템 정리는 중단되고 컨테이너가 중지 된 레이어의 컨테이너에 대한 데이터를 정리하는 것처럼 보입니다. 그러나 인터럽트의 경우 이전 레이어의 데이터를 정리하지 않습니다. 또한 청구 된 총 디스크 공간을 반영하지 않았습니다. aufs 파일 시스템이있는 AWS, ubuntu 14.04, x86_64 비트 시스템에서 이러한 테스트를 실행했습니다. docker 1.13.0 rc3 및 docker 1.12를 사용하여 docker prune 테스트를 실행했습니다.

뿡 빵뀨
내가 잘못 해석하는 것이 있으면 알려주십시오.

/var/lib/docker/tmp 파일이 정리되지 않는 문제를 열었습니다. https://github.com/docker/docker/issues/29486

Docker 시스템 정리는 중단되고 컨테이너가 중지 된 계층의 컨테이너에 대한 데이터를 정리하는 것 같습니다. 그러나 인터럽트의 경우 이전 레이어의 데이터를 정리하지 않습니다.

나는 그 상황을 재현하려고했지만 간단한 사례로는 그것을 볼 수 없었다.

비어있는 /var/lib/docker 새로 설치로 시작하고 다음을위한 큰 파일을 만듭니다.
테스트 및 Dockerfile;

mkdir repro && cd repro
fallocate -l 300M bigfile

cat > Dockerfile <<EOF
FROM scratch
COPY ./bigfile /
COPY ./bigfile /again/
COPY ./bigfile /and-again/
EOF

docker build 시작하고 빌드하는 동안 취소하지만 빌드 후에는 _after_
컨텍스트가 전송되었습니다.

docker build -t stopme .
Sending build context to Docker daemon 314.6 MB
Step 1/4 : FROM scratch
 --->
Step 2/4 : COPY ./bigfile /
 ---> 28eb6d7b0920
Removing intermediate container 98876b1673bf
Step 3/4 : COPY ./bigfile /again/
^C

/var/lib/docker/aufs/ 내용 확인

du -h /var/lib/docker/aufs/
301M    /var/lib/docker/aufs/diff/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084/again
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
601M    /var/lib/docker/aufs/diff
8.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
4.0K    /var/lib/docker/aufs/mnt/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
16K /var/lib/docker/aufs/mnt
601M    /var/lib/docker/aufs/

docker system prune 명령을 실행하여 이미지, 컨테이너를 정리합니다.

docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:253b2968c0b9daaa81a58f2a04e4bc37f1dbf958e565a42094b92e3a02c7b115
deleted: sha256:cad1de5fd349865ae10bfaa820bea3a9a9f000482571a987c8b2b69d7aa1c997
deleted: sha256:28eb6d7b09201d58c8a0e2b861712701cf522f4844cf80e61b4aa4478118c5ab
deleted: sha256:3cda5a28d6953622d6a363bfaa3b6dbda57b789e745c90e039d9fc8a729740db

Total reclaimed space: 629.1 MB

/var/lib/docker/aufs/ 내용 확인

du -h /var/lib/docker/aufs/
4.0K    /var/lib/docker/aufs/diff
4.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
8.0K    /var/lib/docker/aufs/mnt
20K /var/lib/docker/aufs/

-init 마운트가 남아있는 것을 확인했습니다. 해결할 수 있는지 확인해 보겠습니다.
(비어있는 디렉토리 임에도 불구하고)

내가 사용한 dockerfile의 유일한 차이점은 (다른 레이어를 만드는 데)
기스로부터
COPY [ "./bigfile", "randomNoFile1", /]
COPY [ "./bigfile", "randomNoFile2", /]
EOF

차이가 나는지 잘 모르겠습니다.

아니요, 문제는 빈 init 폴더에 관한 것이 아닙니다. 제 경우에는 얼룩이었습니다. 하지만 월요일에 다시 확인하고 업데이트 할 수 있습니다.

또한 5GB 파일을 사용하여 dev urandom에서 바이트를 읽어 생성했습니다.
귀하의 경우 동일한 파일이 두 번 추가됩니다. 단일 레이어를 만들고 그로부터 두 번째 레이어를 마운트합니까 아니면 두 개의 별도 레이어입니까? 제 경우에는 항상 2 개의 별도 레이어입니다.

뿡 빵뀨
문제에 대한 빠른 답변에 감사드립니다. 이 기능을 추가하면 큰 도움이 될 것입니다!

@ monikakatiyar16 ADD 및 RUN 명령을 수행하는 동안 빌드를 여러 번 취소하여이 문제를 재현하려고했지만 삭제 후 aufs/diff 아무것도 유출되지 않았습니다. ADD/COPY 작업 중에 컨테이너가 실행되어서는 안되므로 중지하는 컨테이너를 이해할 수 없습니다. 우리가 실행할 수있는 재생기를 모아 주시면 대단히 감사하겠습니다.

내가 뭔가 잘못하고있을 가능성이 있습니다. 주말에 여행하기 때문에 월요일에 여기에서 필요한 모든 정보를 재현하고 업데이트 할 것입니다.

트윗 담아 가기
나는 당신이 옳다고 느낍니다. 실제로 활성 및 실행중인 것으로 나열된 컨테이너가 없습니다. 대신 죽은 컨테이너가 있습니다. 제 경우에는 Docker 시스템 정리가 작동하지 않았는데, 이는 Ctrl + C로 프로세스가 종료되지 않았기 때문일 수 있습니다. 대신 백그라운드에서 계속 실행되었습니다. 제 경우에는 그 이유가 될 것입니다. 해당 얼룩을 제거 할 수 없습니다.

Ctrl + C를 사용하여 프로세스를 중단하면 빌드 프로세스가 종료되지만 docker-untar 프로세스는 백그라운드에서 살아남아 이미지 빌드 작업을 계속합니다. (참고 : / var / lib / docker는 AWS의 대용량 데이터에 EBS 볼륨을 사용하기 위해 / home / lib / docker에 소프트 링크됩니다.)

root 12700 10781 7 11:43 ? 00:00:04 docker-untar /home/lib/docker/aufs/mnt/d446d4f8a7dbae162e7578af0d33ac38a63b4892905aa86a8d131c1e75e2828c

큰 파일을 만들고 이미지를 만드는 데 사용했던 스크립트 (gc_maxpush_pull.sh)를 첨부했습니다.

또한 Ctrl + C (DockerBuild_WOProcessKill)로 이미지를 빌드하고 이미지를 빌드하는 빌드 프로세스의 동작을 첨부하고 Ctrl + C로 이미지를 중단합니다. 프로세스를 종료 (DockerBuild_WithProcessKill)

명령 사용-

대용량 파일 생성 : ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

이미지 빌드 : ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

복제 단계 :

1. 5GB의 대용량 파일 만들기
2. 빌드 프로세스를 시작하고 빌드 컨텍스트 보내기가 종료되고 실제로 blob을 복사 한 후에 만 ​​중단합니다.
3. 잠시 후 이미지 빌드를 완료하고 도커 이미지에 표시합니다 (예 : 내가 첨부 한 경우 1-DockerBuild_WOProcessKill).
4. 프로세스가 종료되면 시간이 걸리고 blob 데이터가 / diff에 남습니다 (파일에 첨부 된대로 프로세스를 갑자기 종료해야 함-DockerBuild_WithProcessKill).

내가 생각하는 것이 옳다면, 이것은 도커 프룬의 문제가 아니라 어떻게 든 나를 위해 작동하지 않는 도커 빌드를 죽이는 것입니다.

(도커 풀에서 처리 된대로) 복사 된 데이터를 정리하는 빌드 이미지 프로세스를 중단하거나 중지하는 우아한 방법이 있습니까?

이전에는 프로세스를 죽이지 않았습니다. 또한 docker-untar의 기능과 / mnt 및 / diff 폴더 모두에 마운트하고 나중에 / mnt 폴더를 정리하는 이유가 궁금합니다.

Docker 버전 1.12.5, AWS에서 7392c3b 빌드로이를 테스트했습니다.

도커 정보
컨테이너 : 2
달리기 : 0
일시 중지됨 : 0
중지됨 : 2
이미지 : 0
서버 버전 : 1.12.5
스토리지 드라이버 : aufs
루트 디렉토리 : / home / lib / docker / aufs
백업 파일 시스템 : extfs
Dirs : 4
Dirperm1 지원 : false
로깅 드라이버 : json-file
Cgroup 드라이버 : cgroupfs
플러그인 :
볼륨 : 로컬
네트워크 : 오버레이 브리지 null 호스트
Swarm : 비활성
런타임 : runc
기본 런타임 : runc
보안 옵션 : 의류
커널 버전 : 3.13.0-105-generic
운영 체제 : Ubuntu 14.04.4 LTS
OSType : 리눅스
아키텍처 : x86_64
CPU : 2
총 메모리 : 3.859GiB
이름 : master
ID : 2 NQU : D2C5 : 5 WPL : IIDR : P6FO : OAG7 : GHW6 : ZJMQ : VDHI : B5CI : XFZJ : ZSZM
Docker 루트 디렉토리 : / home / lib / docker
디버그 모드 (클라이언트) : false
디버그 모드 (서버) : false
레지스트리 : https://index.docker.io/v1/
경고 : 스왑 제한 지원 없음
안전하지 않은 레지스트리 :
127.0.0.0/8

@ monikakatiyar16 빌드 중에 untar 프로세스를 수동으로 종료 하면 빌드 출력에 Error processing tar file(signal: killed): 됩니다. 컨테이너를 docker ps -a 에 남겨 두는 것이 올바른 동작이며 모든 빌드 오류에서 동일한 일이 발생하며 빌드 실패를 유발 한 문제를 디버깅 할 수 있습니다. 이 컨테이너를 삭제하는 데 아무런 문제가 없으며 그렇게하면 /var/lib/docker/aufs 모든 데이터도 정리됩니다.

@tonistiigi 네 맞습니다. 컨테이너와 관련된 볼륨을 삭제할 수 있었고 docker-untar 프로세스를 종료 한 후 모든 것을 정리했습니다. 이 경우 Docker 시스템 정리도 작동합니다.

볼륨을 남긴 실제 문제는 docker-untar 프로세스를 종료하지 않고 볼륨과 함께 docker 컨테이너를 제거하려고 시도했을 때 다음과 같은 오류가 발생했습니다.

docker rm -v -f $(docker ps -a -q)
Error response from daemon: Driver aufs failed to remove root filesystem 97931bf059a0ec219efd3f762dbb173cf9372761ff95746358c08e2b61f7ce79: rename /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70 /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70-removing: device or resource busy

데몬 로그 :

Error removing mounted layer 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[0956] Handler for DELETE /v1.25/containers/78fb899aab98 returned error: Driver aufs failed to remove root filesystem 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[1028] Error unmounting container 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: no such file or directory

Docker 빌드를 중단하기 위해 지금 따라야 할 순서는 다음과 같습니다.
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

docker v1.13.0-rc4 경우 Interrupt docker build > Kill docker untar process > docker system prune -a 수 있습니다.

이것은 완벽하게 작동하는 것 같습니다. 정리 문제는 없지만 유일한 문제는 docker-untar 프로세스가 docker-build 프로세스와 함께 종료되지 않는 것입니다.

Docker-untar 프로세스를 함께 중지하는 도커 빌드의 우아한 인터럽트에 대한 새로운 문제를 검색 / 업데이트 / 로그합니다.

(도커 v1.12.5 및 v1.13.0-rc4로 확인)

업데이트 : Docker 데몬에 빌드 컨텍스트를 보내는 동안 docker-untar를 죽일 때 build : Error response from daemon: Error processing tar file(signal: terminated) 오류가 발생하지만 레이어 복사 중에는 그렇지 않습니다 (나에게)

인내심을 갖고 시간을 내 주셔서 감사합니다!

/var/lib/docker/aufs 도커 스웜 모드 작업자의 크기가 지속적으로 증가하는 것을보고 있습니다. 이 작업은 대부분의 경우 떼 관리자에 의해 자율적으로 관리되며 여기 저기에서 일부 유지 관리 명령을 제외하고는 수동 컨테이너 생성이 거의 없습니다.

나는 서비스 컨테이너에서 docker exec 를 실행합니다. 그게 원인인지 확실하지 않습니다.

제 경우에이 문제를 해결하기위한 해결 방법은 다른 작업자를 시작하고 전체 노드를 --availability=drain 로 설정 한 다음 몇 개의 볼륨 마운트를 수동으로 이동하는 것입니다.

ubuntu@ip-172-31-18-156:~$ docker --version
Docker version 1.12.3, build 6b644ec

이것은 오랫동안 우리 CI 서버를 강타했습니다. 이 문제를 해결해야합니다.

@orf 감사합니다

여기에도 같은 문제가 있습니다. 컨테이너, 볼륨 및 이미지 제거 중 어느 것도 Docker 1.13 정리 명령이 효과가 없습니다.

또한 일부 이미지 빌드 취소를 확인했습니다. 아마도 도달 할 수없는 폴더를 남길 수 있습니다.
지금은 좋은 오래된 rm 방법을 사용할 것이지만 이것은 분명히 버그입니다.

/ var / lib / docker / aufs / diff의 파일이 30G의 / dev / sda1 파일 시스템에 대해 100 % 공간을 채 웁니다.

root @ Ubuntu : / var / lib / docker / aufs / diff # df -h

마운트 된 사용 가능 사용률 (%)에 사용한 파일 시스템 크기
udev 14G 0 14G 0 % / dev
tmpfs 2.8G 273M 2.5G 10 % / 실행
/ dev / sda1 29G 29G 0100 % /
tmpfs 14G 0 14G 0 % / dev / shm
tmpfs 5.0M 0 5.0M 0 % / run / lock
tmpfs 14G 0 14G 0 % / sys / fs / cgroup
/ dev / sdb1 197G 60M 187G 1 % / mnt
tmpfs 2.8G 0 2.8G 0 % / run / user / 1000

du -h -d 1 / var / lib / docker / aufs / diff | grep '[0-9] G>'
쇼

4.1G / var / lib / docker / aufs / diff / a0cde42cbea362bbb2a73ffbf30059bcce7ef0256d1d7e186264f915d15
14G / var / lib / docker / aufs / diff / 59aee33d8a607b5315ce103cd99f17b4dfdec73c9a2f3bb2afc7d02bfae
20G / var / lib / docker / aufs / diff

또한 도커 시스템 정리 시도했지만 도움이되지 않았습니다.

이 버그가 코드에서 수정되기 전에 diff에서 초대형 파일의 지속적인 문제에 대한 해결책을 찾은 사람이 있습니까?

예, 방법은 이미 주어졌지만 여기에 내가 직장에서 여기에 넣은 모든 것을 파괴하는 종말의 스 니펫이 있습니다 (볼륨에 대한 로컬 폴더 제외). bashrc 또는 다른 bash 구성 파일을 넣으려면.

```
alias docker-full-cleanup = 'func_full-cleanup-docker'

func_full-cleanup-docker () {

echo "경고 : 볼륨, 컨테이너 및 이미지와 같은 모든 것을 도커에서 제거합니다. 감히 하시겠습니까? [y / N]"
읽기 선택

if [( "$ choice"== "y") -o ( "$ choice"== "Y")]
그때
sudo echo "> sudo 권한 확인 [OK]"
sizea = sudo du -sh /var/lib/docker/aufs

echo "Stopping all running containers"
containers=`docker ps -a -q`
if [ -n "$containers" ]
then
  docker stop $containers
fi

echo "Removing all docker images and containers"
docker system prune -f

echo "Stopping Docker daemon"
sudo service docker stop

echo "Removing all leftovers in /var/lib/docker (bug #22207)"
sudo rm -rf /var/lib/docker/aufs
sudo rm -rf /var/lib/docker/image/aufs
sudo rm -f /var/lib/docker/linkgraph.db

echo "Starting Docker daemon"
sudo service docker start

sizeb=`sudo du -sh /var/lib/docker/aufs`
echo "Size before full cleanup:"
echo "        $sizea"
echo "Size after full cleanup:"
echo "        $sizeb"

fi
}```

지금은 rm -rf 명령을 실행하여 diff 폴더에서 파일을 제거했습니다. diff 폴더가 전체 dis 공간을 다시 차지하면 아마도 스크립트를 조사해야 할 것입니다.
이 문제가 해결 방법 대신 코드에서 수정되기를 바랍니다.

안녕하세요, 도커 1.10.2에서 동일한 문제가 발생했습니다. kubernetes를 실행하고 있습니다. 이것은 내 도커 버전입니다.

Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 4
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 50
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.954 GiB
Name: ubuntu-k8s-03
ID: NT23:5Y7J:N2UM:NA2W:2FHE:FNAS:56HF:WFFF:N2FR:O4T4:WAHC:I3PO
Debug mode (server): true
 File Descriptors: 10
 Goroutines: 23
 System Time: 2017-02-14T15:25:00.740998058+09:00
 EventsListeners: 0
 Init SHA1: 3e247d0d32543488f6e70fbb7c806203f3841d1b
 Init Path: /usr/lib/docker/dockerinit
 Docker Root Dir: /var/lib/docker
WARNING: No swap limit support

/var/lib/docker/image/aufs/imagedb 아래의 레이어 파일을 분석하여 /var/lib/docker/aufs/diff 및 /var/lib/docker/aufs/mnt/ 아래에서 사용하지 않는 모든 diff 디렉터리를 추적하려고합니다. 다음은 제가 사용한 스크립트입니다.

https://gist.github.com/justlaputa/a50908d4c935f39c39811aa5fa9fba33

하지만 도커 데몬을 중지하고 다시 시작할 때 문제가 발생했습니다. 도커의 상태가 일관되지 않은 것 같습니다.

/var/log/upstart/docker.log :

DEBU[0277] Cleaning up old shm/mqueue mounts: start.
DEBU[0277] Cleaning up old shm/mqueue mounts: done.
DEBU[0277] Clean shutdown succeeded
Waiting for /var/run/docker.sock
DEBU[0000] docker group found. gid: 999
DEBU[0000] Server created for HTTP on unix (/var/run/docker.sock)
DEBU[0000] Using default logging driver json-file
INFO[0000] [graphdriver] using prior storage driver "aufs"
DEBU[0000] Using graph driver aufs
INFO[0000] Graph migration to content-addressability took 0.00 seconds
DEBU[0000] Option DefaultDriver: bridge
DEBU[0000] Option DefaultNetwork: bridge
INFO[0000] Firewalld running: false
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT]
DEBU[0000] /sbin/iptables, [--wait -t nat -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t nat -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -N DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -C DOCKER-ISOLATION -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -I DOCKER-ISOLATION -j RETURN]
/var/run/docker.sock is up
DEBU[0000] Registering ipam driver: "default"
DEBU[0000] releasing IPv4 pools from network bridge (dcfcc71060f02440ae53da5ee0f083ca51c33a290565f1741f451754ae6b4257)
DEBU[0000] ReleaseAddress(LocalDefault/10.254.69.0/24, 10.254.69.1)
DEBU[0000] ReleasePool(LocalDefault/10.254.69.0/24)
DEBU[0000] Allocating IPv4 pools for network bridge (159d0a404ff6564b4fcfe633f0c8c123c0c0606d28ec3b110272650c5fc1bcb6)
DEBU[0000] RequestPool(LocalDefault, 10.254.69.1/24, , map[], false)
DEBU[0000] RequestAddress(LocalDefault/10.254.69.0/24, 10.254.69.1, map[RequestAddressType:com.docker.network.gateway])
DEBU[0000] /sbin/iptables, [--wait -t nat -C POSTROUTING -s 10.254.69.0/24 ! -o docker0 -j MASQUERADE]
DEBU[0000] /sbin/iptables, [--wait -t nat -C DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -t nat -I DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -D FORWARD -i docker0 -o docker0 -j DROP]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 ! -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]
DEBU[0001] /sbin/iptables, [--wait -t nat -C PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -C OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t nat -A OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -D FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -I FORWARD -j DOCKER-ISOLATION]
WARN[0001] Your kernel does not support swap memory limit.
DEBU[0001] Cleaning up old shm/mqueue mounts: start.
DEBU[0001] Cleaning up old shm/mqueue mounts: done.
DEBU[0001] Loaded container 0790b33ec8e5345ac944d560263b8e13cb75f80dd82cd25753c7320bbcb2747c
DEBU[0001] Loaded container 0e36a6c9319e6b7ca4e5b5408e99d77d51b1f4e825248c039ba0260e628c483d
DEBU[0001] Loaded container 135fb2e8cad26d531435dcd19d454e41cf7aece289ddc7374b4c2a984f8b094a
DEBU[0001] Loaded container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
DEBU[0001] Loaded container 35eb075b5815e621378eb8a7ff5ad8652819ec851eaa4f7baedb1383dfa51a57
DEBU[0001] Loaded container 6be37a301a8f52040adf811041c140408224b12599aa55155f8243066d2b0b69
DEBU[0001] Loaded container d98ac7f052fef31761b82ab6c717760428ad5734df4de038d80124ad5b5e8614
DEBU[0001] Starting container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
ERRO[0001] Couldn't run auplink before unmount: exit status 22
ERRO[0001] error locating sandbox id d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b: sandbox d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b not found
WARN[0001] failed to cleanup ipc mounts:
failed to umount /var/lib/docker/containers/2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973/shm: invalid argument
ERRO[0001] Failed to start container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973: error creating aufs mount to /var/lib/docker/aufs/mnt/187b8026621da2add42330c9393a474fcd9af2e4567596d61bcd7a40c85f71da: invalid argument
INFO[0001] Daemon has completed initialization
INFO[0001] Docker daemon                                 commit=c3959b1 execdriver=native-0.2 graphdriver=aufs version=1.10.2
DEBU[0001] Registering routers
DEBU[0001] Registering HEAD, /containers/{name:.*}/archive

docker run 까지 새 컨테이너를 만들려고하면 다음 메시지와 함께 실패했습니다.

docker: Error response from daemon: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument.
See 'docker run --help'.

데몬 로그에 다음이 표시됩니다.

DEBU[0173] Calling POST /v1.22/containers/create
DEBU[0173] POST /v1.22/containers/create
DEBU[0173] form data: {"AttachStderr":false,"AttachStdin":false,"AttachStdout":false,"Cmd":["/hyperkube","kubelet","--api-servers=http://localhost:8080","--v=2","--address=0.0.0.0","--enable-server","--hostname-override=172.16.210.87","--config=/etc/kubernetes/manifests-multi","--cluster-dns=10.253.0.10","--cluster-domain=cluster.local","--allow_privileged=true"],"Domainname":"","Entrypoint":null,"Env":[],"HostConfig":{"Binds":["/sys:/sys:ro","/dev:/dev","/var/lib/docker/:/var/lib/docker:rw","/var/lib/kubelet/:/var/lib/kubelet:rw","/var/run:/var/run:rw","/etc/kubernetes/manifests-multi:/etc/kubernetes/manifests-multi:ro","/:/rootfs:ro"],"BlkioDeviceReadBps":null,"BlkioDeviceReadIOps":null,"BlkioDeviceWriteBps":null,"BlkioDeviceWriteIOps":null,"BlkioWeight":0,"BlkioWeightDevice":null,"CapAdd":null,"CapDrop":null,"CgroupParent":"","ConsoleSize":[0,0],"ContainerIDFile":"","CpuPeriod":0,"CpuQuota":0,"CpuShares":0,"CpusetCpus":"","CpusetMems":"","Devices":[],"Dns":[],"DnsOptions":[],"DnsSearch":[],"ExtraHosts":null,"GroupAdd":null,"IpcMode":"","Isolation":"","KernelMemory":0,"Links":null,"LogConfig":{"Config":{},"Type":""},"Memory":0,"MemoryReservation":0,"MemorySwap":0,"MemorySwappiness":-1,"NetworkMode":"host","OomKillDisable":false,"OomScoreAdj":0,"PidMode":"host","PidsLimit":0,"PortBindings":{},"Privileged":true,"PublishAllPorts":false,"ReadonlyRootfs":false,"RestartPolicy":{"MaximumRetryCount":0,"Name":"always"},"SecurityOpt":null,"ShmSize":0,"UTSMode":"","Ulimits":null,"VolumeDriver":"","VolumesFrom":null},"Hostname":"","Image":"gcr.io/google_containers/hyperkube:v1.1.8","Labels":{},"NetworkingConfig":{"EndpointsConfig":{}},"OnBuild":null,"OpenStdin":false,"StdinOnce":false,"StopSignal":"SIGTERM","Tty":false,"User":"","Volumes":{},"WorkingDir":""}
ERRO[0173] Couldn't run auplink before unmount: exit status 22
ERRO[0173] Clean up Error! Cannot destroy container 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566: nosuchcontainer: No such container: 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566
ERRO[0173] Handler for POST /v1.22/containers/create returned error: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument

내 접근 방식이 올바른지 여부를 아는 사람이 있습니까? 해당 폴더를 삭제 한 후 문제가 발생하는 이유는 무엇입니까?

나는 적어도 우리가 어떤 상황에서도이 dirs를 유출하지 않도록하기 위해 # 31012를 열었습니다.
물론 busy 오류의 다양한 원인도 살펴 봐야합니다.

이것은 내가 기억할 수있는 한 나를 물고 있었다. 며칠 전에 overlay2 드라이버로 전환하고 aufs 폴더를 완전히 누크했을 때 위에서 설명한 것과 거의 동일한 결과를 얻었습니다 ( docker system df 는 1.5Gigs, df 는 15Gigs) .

스토리지를 사용하여 약 1T의 diff가있었습니다. 도커 데몬을 다시 시작한 후 약 700GB를 복구했습니다. 그래서 데몬을 중지하면 이것들이 정리됩니다.

불행히도 다시 시작해도 아무런 효과가 없습니다.

서비스를 다시 시작해도 도움이되지 않았습니다. 이것은 심각한 문제입니다. 모든 컨테이너 / 이미지를 제거해도 이러한 차이점은 제거되지 않습니다.

데몬을 중지해도 이러한 항목은 제거되지 않습니다.

모든 컨테이너를 제거하고 여전히 diff dirs가있는 경우 일부 유출 된 rw 레이어가있을 수 있습니다.

방금이 문제가 발생했습니다. /var/lib/docker/aufs/diff 은 28G를 차지하고 루트 파일 시스템을 100 %로 전환하여 GitLab 서버가 응답을 중지했습니다. 우리는 GitLab CI에 도커를 사용하고 있습니다. 이 문제를 해결하기 위해 위에서 제안한 @sogetimaitral 명령 중 일부를 사용하여 임시 파일을 삭제했으며 백업 및 실행 중입니다. 서버를 다시 시작하고 CI를 트리거하기 위해 새 커밋을 보냈는데 모든 것이 정상적으로 작동하는 것 같습니다.

나는 이것이 다시 일어날 것이라고 확실히 걱정한다. 여기서 거래는 무엇입니까? 수정해야하는 도커 버그입니까?

1. 예, 버그가 있습니다 (제거에 문제가 있고 --force on rm이 이러한 문제를 무시 함)
2. 일반적으로 컨테이너 fs에 많은 양의 데이터를 쓰지 말고 대신 볼륨을 사용하십시오 (폐기 볼륨 포함). diff dir이 크면 컨테이너 fs에 많은 양의 데이터가 기록되고 있음을 나타냅니다.

제거 할 때 "--force"를 사용하지 않으면이 문제가 발생하지 않을 것입니다 (또는 적어도 "죽은"컨테이너가 많이 있고 정리 방법 / 무엇을 알 수 있습니다.).

나는 수동으로 도커를 전혀 사용하지 않습니다. 우리는 gitlab-ci-multi-runner를 사용하고 있습니다. 그렇다면 GitLab의 끝에서 버그일까요?

(기본적으로) 컨테이너를 강제 제거하는 것처럼 보입니다. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. 이렇게하면 무시되는 컨테이너를 제거하지 못하여 고아 차이가 발생할 수 있습니다.

좋아, 그러면 이것이 gitlab-ci-multi-runner 버그라는 것을 알 수 있습니다. 이것이 올바른 해석입니까? 이 문제를 해결할 수있는 문제를 만들어 드리겠습니다.

내가 추측하는 조합입니다. "강제"제거를 사용하면 정리 (예 : 컨테이너가 아직 중지되지 않은 경우 등)를보다 쉽게 ​​처리 할 수 ​​있으며 동시에 ( @ cpuguy83에서 언급 한 "버그"라고 함) 다음과 같은 실제 문제를 숨길 수도 있습니다. docker가 컨테이너 파일 시스템을 제거하지 못했습니다 (다양한 이유가있을 수 있음). "force"를 사용하면 이러한 경우 컨테이너가 제거됩니다. 없는 경우 컨테이너가 주변에 남아 있습니다 (그러나 "죽음"으로 표시됨).

gitlab 실행기가 강제 제거없이 올바르게 작동 할 수 있다면 변경 (또는 구성 가능)하는 것이 좋습니다.

드론을 사용하고 있는데 같은 문제가 있습니다. 컨테이너가 어떻게 제거되는지 코드를 확인하지 않았지만 강제로 제거한다고 생각합니다.

Docker의 Docker 문제 일 수 있습니까? docker-compose로 Drone을 시작하고 있습니다.

계속해서 개발자를 반복하기 위해 gitlab-ci-multi-runner 문제를 제출하기로 결정했습니다. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

솔직히 우리는 Spotify의 docker gc를 드론 CI로 실행하여이 문제를 해결했습니다.

El El mar, 3 월. 2017 년 12 월 28 일 오후 3시 38 분, Geoffrey Fairchild <
[email protected]> escribió :

계속해서 gitlab-ci-multi-runner 문제를 제출하기로 결정했습니다.
개발자를 다음에서 루프 :
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard 이 팁에 감사드립니다! spotify에서 매시간 docker-gc를 실행하면 문제가 해결되었습니다.

이미지 빌드 / 컨테이너 실행 (Gitlab CI Docker 통합 아님) 명령을 사용하여 Gitlab CI (도커에서 실행되지 않음)에서이 문제가 실행되고 있습니다. 우리는 어떤 형태의 강제 제거도 실행하지 않습니다. 단순히 docker run --rm ... 및 docker rmi image:tag

편집 : 죄송합니다, 실제로 원래 문제는 동일합니다. 차이점은 spotify/docker-gc 를 실행해도 문제가 해결되지 _ 아닙니다 _.

아래에서 볼 수 있듯이 이미지 0 개, 컨테이너 0 개, 아무것도 없습니다!
docker system info 동의하지만 aufs 스토리지에 대해 Dirs: 38 를 언급합니다.

그것은 수상하다! /var/lib/docker/aufs/diff/ 를 살펴보면 실제로 41 개 이상의 디렉토리에 1.7GB의 데이터가 있음을 알 수 있습니다. 그리고 그것은 내 개인 상자이고 프로덕션 서버에서는 19GB입니다.

이것을 어떻게 청소합니까? spotify/docker-gc 사용해도 제거되지 않습니다.

philippe@pv-desktop:~$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

philippe@pv-desktop:~$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

philippe@pv-desktop:~$ docker system info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 38
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-72-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.34 GiB
Name: pv-desktop
ID: 2U5D:CRHS:RUQK:YSJX:ZTRS:HYMV:HO6Q:FDKE:R6PK:HMUN:2EOI:RUWO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: silex
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

philippe@pv-desktop:~$ ls -alh /var/lib/docker/aufs/diff/
total 276K
drwxr-xr-x 40 root root 116K Apr 13 15:32 .
drwxr-xr-x  5 root root 4.0K Sep 18  2015 ..
drwxr-xr-x  4 root root 4.0K Jun 17  2016 005d00efb0ba949d627ad439aec8c268b5d55759f6e92e51d7828c12e3817147
drwxr-xr-x  8 root root 4.0K May  2  2016 0968e52874bbfaa938ffc869cef1c5b78e2d4f7a670e19ef47f713868b9bfbdf
drwxr-xr-x  4 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0
drwxr-xr-x  6 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0-init
drwxr-xr-x 21 root root 4.0K Apr  8  2016 250ecb97108a6d8a8c41f9d2eb61389a228c95f980575e95ee61f9e8629d5180
drwxr-xr-x  2 root root 4.0K Dec 22  2015 291f16f99d9b0bc05100e463dbc007ef816e0cf17b85d20cf51da5eb2b866810
drwxr-xr-x  2 root root 4.0K May  2  2016 3054baaa0b4a7b52da2d25170e9ce4865967f899bdf6d444b571e57be141b712
drwxr-xr-x  2 root root 4.0K Feb  5  2016 369aca82a5c05d17006b9dca3bf92d1de7d39d7cd908ed665ef181649525464e
drwxr-xr-x  3 root root 4.0K Jun 17  2016 3835a1d1dfe755d9d1ada6933a0ea7a4943caf8f3d96eb3d79c8de7ce25954d2
(...strip)

philippe@pv-desktop:~$ du -hs /var/lib/docker/aufs/diff/
1.7G    /var/lib/docker/aufs/diff/

philippe@pv-desktop:~$ docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0 B

안전하게 rm -r /var/lib/docker/aufs 하고 docker deamon을 다시 시작할 수 있습니까?

spotify/docker-gc 해도 고아가 정리되지 않습니다.

편집 : @CVTJNII 감사합니다!

Docker 데몬을 중지하고 / var / lib / docker를 모두 지우는 것이 더 안전합니다. / var / lib / docker / aufs를 지우면 어쨌든 이미지가 손실되므로 깨끗한 / var / lib / docker로 시작하는 것이 좋습니다. 이것이 제가 지금이 문제에 대해 몇 달 동안 사용해온 "솔루션"입니다.

17.06부터는 더 이상 새로운 분리 된 diff가 없어야합니다.
대신 Dead 상태의 컨테이너가 표시되기 시작할 수 있습니다. 제거 중에 복구 할 수없는 오류가 발생하여 관리자가 처리해야 할 수있는 경우이 문제가 발생합니다.

또한 제거는 좀 더 강력하며 경쟁 조건이나 마운트 해제 실패로 인한 오류가 발생하기 쉽습니다.

@ cpuguy83 : 좋은 소식입니다. 이런 일이 발생하면 관리자가 무엇을해야하는지 설명해 주시겠습니까?

@Silex 원인에 따라 다릅니다.
일반적으로 발생한 것은 일부 마운트가 컨테이너로 누출되어 device or resource busy 오류가 발생하는 것입니다. cadvisor와 같은 것을 실행하는 경우 전체 도커 디렉토리를 cadvisor 컨테이너에 마운트하라는 지침에 따라 거의 보장됩니다.

이것은 까다로울 수 있습니다. 문제가되는 컨테이너를 중지 한 다음 dead 컨테이너를 제거해야 할 수 있습니다.

최신 커널 (3.15+)을 사용하는 경우 더 이상 문제가 발생하지 않을 수 있지만 여전히 약간의 문제가있을 수 있습니다.

Docker 버전 17.06.0-ce, 빌드 02c1d87

모든 이미지, 볼륨, 네트워크 및 컨테이너를 제거하려고 시도했지만 도움이되지 않았습니다.
또한 시도한 명령 :

docker system prune -af
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

여전히 남아있는 파일 :

root<strong i="11">@Dark</strong>:/var/lib/docker/aufs# ls -la *
diff:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  4 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  6 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  5 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  6 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  4 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  6 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  4 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  6 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

layers:
total 52
drwx------ 2 root root 45056 Jul 28 17:28 .
drwx------ 5 root root  4096 Jul  9 00:18 ..
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

mnt:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

어떻게 삭제할 수 있습니까?

@ haos616 먼저 실행중인 모든 컨테이너를 중지 한 다음 docker system prune -af 를 실행합니다.
이것은 나를 위해 트릭을했습니다.
컨테이너를 실행하는 동안 작동하지 않았습니다.

이전 버전의 docker에서 업그레이드 한 경우 해당 버전에서 해당 diff가 생성 / 남은 것일 수 있습니다. Docker 17.06은 레이어 제거에 실패한 경우 컨테이너를 제거하지 않습니다 (--force 사용시). 이전 버전은 고아 레이어로 이어질 수 있습니다.

@ julian-pani 처음에는 그렇게했지만 도움이되지 않습니다.

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

@thaJeztah 아니요. 한두 달 전에 Docker를 청소했습니다. 그런 다음 버전은 이미 17.06이었습니다. docker system prune -af 명령을 사용했습니다. 그것은 모든 것을 제거했습니다.

https://github.com/spotify/docker-gc 를 컨테이너로 실행하면 효과가 있었지만 한 단계 더 나아가 필요한 이미지 중 일부도 삭제했습니다.

그래서 안전을 위해 아래와 같이 작은 래퍼 스크립트를 넣었습니다.

#!/bin/sh
docker images -q > /etc/docker-gc-exclude    # Save all genuine images as exclude
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

spotify에 다시 한 번 감사드립니다

IIUC, spotify 스크립트는 docker rm 및 docker rmi 호출합니다. 실제로 고아 diff를 제거 했습니까?

커뮤니티에 대한 일부 피드백 일뿐입니다.이 모든 내용을 읽었으며 실제로 일관되게 또는 안정적으로 작동하는 솔루션이없는 것 같습니다. 내 "수정"은 단순히 내 AWS 인스턴스의 디스크 공간을 두 배로 늘리는 것입니다. 그리고 나는 그것이 엉뚱한 해결책이라는 것을 너무 잘 알고 있지만 Docker의 부풀어 오른 aufs에 대해 찾은 최고의 해결 방법입니다. 이것은 정말로 고쳐 져야합니다.

@fuzzygroup 17.06은 더 이상 분리 된 diff를 만들지 않아야하지만 아직 이전 diff를 정리하지는 않습니다.

이 스크립트로 정리할 수 있습니다. 왜 작동하지 않는지 모르겠지만 누가 압니까.
어쨌든 그것은 나를 위해 잘 작동합니다. 모든 이미지, 컨테이너 및 볼륨을 삭제합니다. 자주 실행되지 않아야하므로 사소한 부작용이 있습니다. 그러나 그것을 사용하거나 사용하지 않는 것은 당신에게 달려 있습니다.

https://gist.github.com/Karreg/84206b9711cbc6d0fbbe77a57f705979

https://stackoverflow.com/q/45798076/562769 는 관련이있는 것 같습니다. 빠른 수정을 게시했습니다.

참고로, 17.06.1-ce 여전히이 항목이 표시됩니다.

Containers: 20
 Running: 0
 Paused: 0
 Stopped: 20
Images: 124
Server Version: 17.06.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 185
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 4.4.0-83-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.796GiB
Name: gitlab-cirunner
ID: PWLR:R6HF:MK3Y:KN5A:AWRV:KHFY:F36D:WASF:7K7B:U7FY:2DJA:DBE2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

/var/lib/docker/aufs/diff 에는 -init-removing 및 -removing 접두사가있는 많은 디렉토리가 포함됩니다.

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

참고로, 여전히 17.06.1-ce에서 이것을보고 있습니다.

아직도 정확히 무엇을보고 있습니까?
diff 디렉토리가 누출 될 수있는 방법이 없어야합니다. 업그레이드시 diff 디렉토리가 존재했다면 여전히 존재하지만 여전히 존재합니다.

내가 말할 수있는 한 고아가 된 diff가 여전히 보입니다. docker system prune 도 삭제하지 않았고 docker-gc 도 삭제하지 않았습니다. rm -rf /var/lib/docker/aufs/diff/*-removing 수동 실행이 작동하는 것 같습니다.

예, docker는 아직 오래된 고아 디렉토리를 정리하지 않습니다.

오래되었다는 것은이 문제가있는 이전 버전의 docker에서 만든 것을 의미합니까?

이것은 우리가 약 2 주 전에 수행 한 Docker의 새로운 설치입니다. 그 고아는 그 이후로 생성되었을 것입니다. 그래서 docker가 여전히 고아를 만들고있는 것 같습니다.

내 말은, 후반에 시간 나는있어 112 새로운 차이점 -removing 내가 수동으로 rm'ed 때문에.

$ ls /var/lib/docker/aufs/diff/ | grep removing | wc -l
112

"17.06은 더 이상 분리 된 diff를 만들지 말아야하지만 아직 이전 diff를 정리하지 않을 것입니다."라고 말했지만 확실히 이것이 맞지 않거나 뭔가 빠졌습니까? -removing 태그가 붙은 것은 고아가 아닌가?

@orf 최신 커널에서 제거 중에 문제가 발생하는 것은 예상치 못한 일입니다. /var/lib/docker 을 컨테이너에 마운트하고 있습니까?

aufs 드라이버를 확인하여 실제로 그렇지 않은 경우 성공적인 제거를보고하는 특정 문제가 있는지 확인합니다.

/var/lib/docker 을 컨테이너에 마운트하지 않습니다.

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic #106~14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

14.04 LTS를 실행 중입니다.

이 문제를 디버그하는 데 도움이 될 수있는 것이 있으면 알려주세요.

다른 이유로 (swarm 모드 네트워킹) Docker를 위해 14.04로 이동했습니다.
기계.
2017 년 8 월 21 일 월요일 오전 8:23 orf [email protected] 작성 :

/ var / lib / docker를 컨테이너에 마운트하지 않습니다.

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic # 106 ~ 14.04.1-Ubuntu SMP Mon June 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU / Linux

14.04 LTS를 실행 중입니다.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/22207#issuecomment-323773033 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

이것은 17.06.01-ce에서 더 나빠 보입니다. 빌드 머신을이 버전으로 업데이트하고 즉시 빌드 프로세스의 일부로 남아있는 *-init-removing 및 *-removing 디렉토리를보기 시작했습니다. 서비스를 중지하고 /var/lib/docker 디렉터리를 제거하고 서비스를 다시 시작한 후 몇 번의 빌드가 디스크 공간 부족에 가까워졌습니다. 서비스를 다시 중지하고 apt-get purge docker-ce 하고 /var/lib/docker 다시 제거하고 17.06.0-ce 버전을 설치했습니다. /var/lib/docker/aufs/diff 및 디스크 공간에서 추가 디렉토리를 얻지 못하는 것은 빌드 머신에있는 이미지를 나타냅니다. 저는 개발 머신에서도 동작을 재현했습니다. 이미지를 빌드하는 것만으로도 이미지의 각 레이어에 대해 이러한 추가 디렉토리가 생성되는 것처럼 보이므로 디스크 공간이 정말 빨리 부족합니다. 다시 말하지만, 17.06.0-ce로 되 돌리는 것은 문제가없는 것 같으므로 지금은 거기에 머무를 것입니다.

@mmanderson 보고

@mmanderson docker ps -a Dead 상태의 컨테이너가 있습니까?

내 모든 도커 빌드 서버에 공간이 부족합니다.

지난주에 Docker 버전 17.06.1-ce, 빌드 874a737로 업그레이드했습니다. 나는 다른 어떤 것도 변경되지 않았으며이 문제는 업그레이드 프로세스의 일부로 나타 났거나 나타났습니다. aufs diff 디렉토리는 방대하며 이미 모든 이미지와 매달린 볼륨을 정리했습니다.

issue-22207.txt
@ cpuguy83 어떤 상태에도 컨테이너가 없습니다. 다음은 17.06.01-ce로 이것을 증명하기 위해 간신히 수행 한 작업입니다.

1. Ubuntu 16.04.03 LTS에 docker 17.06.01-ce를 새로 설치하여 시작했습니다 (즉, docker가 설치되지 않고 / var / lib / docker 디렉토리가 없음). 설치 후 빈 / var / lib / docker / aufs / diff 디렉토리를 확인했습니다.
2. ubuntu : latest를 기반으로하는 매우 간단한 dockerfile로 docker 빌드를 실행했습니다
3. 빌드를 실행 한 후 docker ps -a 를 실행하여 어떤 상태의 컨테이너도 표시하지 않습니다. 이 몇 가지 *-remaining 에서 폴더 /var/lib/docker/aufs/diff 폴더에 있습니다.
4. docker system df 를 실행하여 이미지, 컨테이너 및 볼륨을 확인합니다. 결과는

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              2                   0                   132.7MB             132.7MB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

1. du -sch /var/lib/docker/*/ 실행하면 /var/lib/docker/aufs/ 2,200 du -sch /var/lib/docker/*/ 표시됩니다.
2. docker rmi $(docker images -q) 를 실행하여 빌드 된 이미지 레이어를 제거합니다. 이 후에 docker system df 를 실행하면 모두 0이 표시됩니다. 실행 du -sch /var/lib/docker/*/ 쇼 152M /var/lib/docker/aufs/ 하고있다 *-remaining 폴더의 모든 폴더 것은 그 기존과 함께하기 전에이 없었 *-remaining 폴더가 아직 거기에 있습니다.

@erikh 이것이 당신이 겪고있는 문제입니까?

@ cpuguy83 17.06.01-ce를 제거하고 / var / lib / docker 디렉토리를 제거하고 17.06.0-ce를 설치 한 후 동일한 빌드를 실행하려고합니다. 17.06.01에서 수정 된 ADD from remote URL's 버그로 인해 빌드가 실패합니다. 그러나 완료하는 단계에 대해 *-remaining 디렉토리가 없으며 docker system prune 및 docker rmi $(docker image -q) 모든 것을 정리 한 후 /var/lib/docker/aufs/diff 디렉토리가 다시 비어 있습니다. 공간이 확보됩니다.

감사합니다. 이것은 17.06.1의 회귀입니다 ...
수정해야 할 PR : https://github.com/moby/moby/pull/34587

굉장합니다, @ cpuguy83의 빠른 패치에 감사드립니다! / cc @erikh

@rogaha! 네, 당신과 @ cpuguy83 덕분에!

훌륭한 스크립트에 대해 @Karreg 에게 감사드립니다. 모든 오래된 ophaned diff를 제거하고 손실 된 디스크 공간을 다시 확보 한 후 이제 새 도커 이미지를 설치하기 전에 VM을 정리하는 데 정기적으로 사용하고 있습니다. 이 문제에 대한 큰 도움과 거의 완벽한 해결 방법입니다. @ TP75

Docker, Inc.가 컴퓨터 데이터 저장소 제조업체와 일부 계약을 맺은 것 같습니다.

@Karreg 의 스크립트는 저에게 잘 작동했고 diffs 디렉토리의 모든 공간을 비

같은 문제가 있습니다.
Docker 호스트 세부 정보

root @ UbuntuCont : ~ # 도커 정보
컨테이너 : 3
달리기 : 0
일시 중지됨 : 0
중지됨 : 3
이미지 : 4
서버 버전 : 17.06.1-ce
스토리지 드라이버 : aufs
루트 디렉토리 : / var / lib / docker / aufs
백업 파일 시스템 : extfs
Dirs : 14
Dirperm1 지원 : true
로깅 드라이버 : json-file
Cgroup 드라이버 : cgroupfs
플러그인 :
볼륨 : 로컬
네트워크 : 브리지 호스트 macvlan null 오버레이
로그 : awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm : 비활성
런타임 : runc
기본 런타임 : runc
바이너리 초기화 : docker-init
컨테이너 버전 : 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc 버전 : 810190ceaa507aa2727d7ae6f4790c76ec150bd2
초기화 버전 : 949e6fa
보안 옵션:
의류
seccomp
프로필 : 기본값
커널 버전 : 4.4.0-93-generic
운영 체제 : Ubuntu 16.04.3 LTS
OSType : 리눅스
아키텍처 : x86_64
CPU : 1
총 메모리 : 3.358GiB
이름 : UbuntuCont
ID : QQA5 : DC5S : C2FL : LCC6 : XY6E : V3FR : TRW3 : VMOQ : QQKD : AP2M : H3JA : I6VX
Docker 루트 디렉토리 : / var / lib / docker
디버그 모드 (클라이언트) : false
디버그 모드 (서버) : false
레지스트리 : https://index.docker.io/v1/
실험적 : 거짓
안전하지 않은 레지스트리 :
127.0.0.0/8
라이브 복원 활성화 : false

root @ UbuntuCont : / var / lib / docker / aufs / diff # ls
031c85352fe85f07fede77dee0ac9dc2c7723177a819e72c534e1399208c95fa
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d-init
0fb1ffc90969e9706801e2a18870f3ecd857a58f1094fbb968b3fa873e4cf2e4
10549179bd21a9c7af018d4ef305bb9196413b9662fce333b607104c40f38781
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-init-removing
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c- 제거
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606-init
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-init-removing
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da- 제거
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-init-removing
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c- 제거
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-init-removing
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5- 제거
59cbb25a4858e7d3eb9146d64ff7602c9abc68509b8f2ccfe3be76681481904f
5d1c661b452efce22fe4e109fad7a672e755c64f538375fda21c23d49e2590f6
605893aba54feee92830d56b6ef1105a4d2166e71bd3b73a584b2afc83319591
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-init-removing
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281- 제거
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-init-removing
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779- 제거
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-init-removing
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26- 제거
a72735551217bb1ad01b77dbdbb9b8effa9f41315b0c481f8d74b5606c50deb4
aa58f2000b9f7d1ed2a6b476740c292c3c716e1d4dc04b7718580a490bba5ee8
b552cb853e33a8c758cb664aec70e2c4e85eacff180f56cbfab988a8e10c0174- 제거
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-init-removing
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55- 제거
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2-init

@kasunsjc 귀하의 게시물 바로 위에있는 게시물을 읽으십시오.

17.06.2-ce로 업그레이드하면이 문제가 해결되었음을 확인합니다. 업그레이드 후 (지난 시간에) 디렉토리를 수동으로 만들 필요가 없었습니다.

17.06.2-ce _appears_도이 문제를 해결했습니다. 거기에 더 이상 -removing 디렉토리가 없으며 충분한 공간을 확보했습니다.

나는 있으리라 믿고있어 -init I가에있는 디렉토리 aufs/diff (그들 중 일부는 꽤 오래된) 관련이 없습니다. 그러나 그것들은 모두 작기 때문에 거의 중요하지 않습니다.

17.07.0으로 업데이트하면 여기서도 문제가 해결되었습니다. docker system prune --all -f 조차도 디렉토리가 이전에 제거되지는 않았지만 업그레이드 후에 재부팅시 자동 제거되었습니다.

이 문제를 확인하면 Ubuntu 16.04 (17.06.2-ce 포함)에서 해결되었습니다. 업데이트하자마자 공간이 정리되었습니다.