DockerイメージがDockerで使用されていないディスクスペースを消費するのはなぜですか

Dockerをセットアップし、Dockerのシステムデータを保存するためにまったく異なるブロックデバイスを使用しました。

[root@blink1 /]# cat /etc/sysconfig/docker
# /etc/sysconfig/docker

other_args="-H tcp://0.0.0.0:9367 -H unix:///var/run/docker.sock -g /disk1/docker"

/disk/1完全に異なるハードドライブを使用していることに注意してください/dev/xvdi

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  5.1G  2.6G  67% /
devtmpfs        1.9G  108K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvdi        20G  5.3G   15G  27% /disk1
/dev/dm-1       9.8G  1.7G  7.6G  18% /disk1/docker/devicemapper/mnt/bb6c540bae25aaf01aedf56ff61ffed8c6ae41aa9bd06122d440c6053e3486bf
/dev/dm-2       9.8G  1.7G  7.7G  18% /disk1/docker/devicemapper/mnt/c85f756c59a5e1d260c3cdb473f3f4d9e55ac568967abe190eeaf9c4087afeac

問題は、DockerイメージをダウンロードしてDockerコンテナーを実行し続けると、他のハードドライブ/dev/xvda1も使い果たされているように見えることです。

いくつかのDockerイメージを削除することで、この問題を確認できます。Dockerイメージをいくつか削除した後、/dev/xvda1スペースが増えました。

私は何かが足りないのですか？

私のDockerバージョン：

[root@blink1 /]# docker info
Containers: 2
Images: 42
Storage Driver: devicemapper
 Pool Name: docker-202:1-275421-pool
 Pool Blocksize: 64 Kb
 Data file: /disk1/docker/devicemapper/devicemapper/data
 Metadata file: /disk1/docker/devicemapper/devicemapper/metadata
 Data Space Used: 3054.4 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 4.7 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.20-20.44.amzn1.x86_64
Operating System: Amazon Linux AMI 2014.09

これは、デバイスマッパーのカーネルの問題であり、OSのRedHatファミリー（RedHat、Fedora、CentOS、およびAmazon Linux）に影響します。削除されたコンテナは、マップされたディスク領域を解放しません。これは、影響を受けるOSで、コンテナを起動および再起動するときにスペースが徐々に不足することを意味します。

Dockerプロジェクトはこれを認識しており、カーネルはおそらくアップストリームで修正されています（https://github.com/docker/docker/issues/3182）。

ある種の回避策は、Dockerに書き込み用の独自のボリュームを与えることです（「Dockerがディスクスペースを使い果たしたとき」）。これは、実際にスペースを消費することを妨げるものではなく、システムの他の部分を停止した後に停止するだけです。

私の解決策は、dockerをアンインストールしてから、そのすべてのファイルを削除してから、再インストールすることでした。

sudo yum remove docker
sudo rm -rf /var/lib/docker
sudo yum install docker

これでスペースが回復しましたが、代わりのインスタンスを起動するのと大差ありません。私はより良い解決策を見つけていません。

/ var / lib / docker全体を削除しても問題ありません。これらはより安全な方法です：

解決策1：解決策1：

この問題の次のコマンドは、スペースをクリアします。/var/lib/dockerを削除したり、Windowsの場合は、ここでディスクイメージの場所を確認するよりもはるかに安全です。

前：

docker info

出力例：

Metadata file: 
Data Space Used: 53.38 GB
Data Space Total: 53.39 GB
Data Space Available: 8.389 MB
Metadata Space Used: 6.234 MB
Metadata Space Total: 54.53 MB
Metadata Space Available: 48.29 MB

Dockerの新しいバージョン（17.x +など）のコマンド

docker system prune -a

停止しているすべてのコンテナ、ネットワーク、イメージ、およびビルドキャッシュが削除されるという警告が表示されます。通常、これを削除しても安全です。（次にコンテナーを実行すると、Dockerレジストリーからプルされる場合があります）

出力例：

Total reclaimed space: 1.243GB

その後、Docker情報を再度実行して、クリーンアップされたものを確認できます。

docker info

解決策2：解決策2：

これに加えて、Dockerコンテナ内のプログラムがファイルシステムに多くの/巨大なファイルを書き込んでいないことを確認してください。

実行中のDockerプロセスのスペース使用量を確認してください

docker ps -s #may take minutes to return

またはすべてのコンテナについて、終了した場合でも

docker ps -as #may take minutes to return

その後、問題のあるコンテナを削除できます

docker rm <CONTAINER ID>

宇宙のギグを使用している可能性のある原因を見つける

docker exec -it <CONTAINER ID> "/bin/sh"
du -h

私の場合、プログラムは一時ファイルのギグを書いていました。

（Nathaniel Waisbrotがこの問題の受け入れられた回答で言及し、私はこの問題からいくつかの情報を得ました）

または

古いバージョンのDockerのコマンド（例：1.13.x（sudoではなくrootとして実行））：

# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)

# Delete 'dangling' images (If there are no images you will get a docker: "rmi" requires a minimum of 1 argument)
docker rmi $(docker images -f "dangling=true" -q)

# Delete 'dangling' volumes (If there are no images you will get a docker: "volume rm" requires a minimum of 1 argument)
docker volume rm $(docker volume ls -qf dangling=true)

後：

> docker info
Metadata file: 
Data Space Used: 1.43 GB
Data Space Total: 53.39 GB
Data Space Available: 51.96 GB
Metadata Space Used: 577.5 kB
Metadata Space Total: 54.53 MB
Metadata Space Available: 53.95 MB

/var/lib/dockerディレクトリを移動します。

/dataディレクトリに十分なスペースがあると仮定すると、そうでない場合は、十分なスペースがある代わりに、

sudo systemctl stop docker

sudo mv /var/lib/docker /data


sudo ln -s /data/docker /var/lib/docker

sudo systemctl start docker

このように、dockerを再構成する必要はありません。

同じ問題がありました。私のシナリオでは、vboxのストレージ容量が不足していました。調査の結果、Dockerのローカルボリュームが30GBを消費していることが判明しました。Ubuntu16.04ホスト。

あなたのものを見つけるために。

docker system df

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              3                   0                   1.361GB             1.361GB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       7                   0                   9.413GB             9.413GB (100%)
Build Cache                                                 0B                  0B



docker system prune --volumes


  WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all volumes not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N]

これにより、使用されていないローカルボリュームのディスク領域が解放されます。私のシナリオでは、20GBのストレージスペースを解放しました。停止したコンテナはすべて削除されるため、保持する場合は、保持するコンテナが実行されていることを確認してから実行してください。

同様の問題が発生しました。これは、すべてのDockerイメージ用の十分なスペースがディスクにない場合に発生すると思います。Dockerイメージ用に6GBを予約しましたが、私の場合は十分ではないことがわかりました。とにかく、私はすべてのイメージとコンテナを削除しましたが、それでもディスクはいっぱいに見えました。ほとんどのスペースは/ var / lib / docker / devicemapperと/ var / lib / docker / tmpによって使用されていました。

このコマンドは私には機能しませんでした：

# docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/

まず、Dockerサービスを停止しました。

sudo service docker stop

次に、/ var / lib / dockerを削除しました。

次に、https：//github.com/docker/docker/issues/18867#issuecomment-232301073で誰かが提案したことを実行しました

• dockerメタデータの既存のインスタンスを削除しますrm-rf / var / lib / docker

  sudo rm -rf / var / lib / docker

• 次のオプションをdockerデーモンに渡します。-sdevicemapper--storage-optdm.fs = xfs --storage-opt dm.mountopt = discard

• Dockerデーモンを起動します。

最後の2つのステップでは、次のコマンドを実行します。

sudo dockerd -s devicemapper --storage-opt dm.fs=xfs --storage-opt dm.mountopt=discard

Docker pruneは、デフォルトではボリュームを削除しません。

あなたは次のようなことを試すことができます

docker volume prune -f

問題＃18867で述べたように-コンテナのデータを削除するdevicemapperはGithub.comから使用済みスペースを解放できません

以下のコマンドを実行してみてください。

# docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/

このfstrimツールを使用して、デバイスマッパーのシンプロビジョニングされたディスクをトリミングします。

たぶんあなたdocker system pruneは重要ではないすべての画像を削除しようとすることができます

MacOSでこの問題が発生した場合、私にとって有効な解決策は、Dockerがホストの論理スペースを予約して削除するために使用するDocker.rawファイルを探すことでした。Dockerデスクトップをお持ちの場合は、次のことができます。

Preferences -> Resources -> Advanced次に、Disk image locationタブの下を確認します。

ターミナルでそのフォルダに移動し、Docker.rawファイルを削除するだけです（$ rm -rf Docker.raw）

重要な注意：これを行うのは、既存のイメージやボリュームが不要な場合のみです。

はい、Dockerは/ var / lib / dockerフォルダーを使用してレイヤーを保存します。スペースを再利用してストレージを他のディレクトリに移動する方法はいくつかあります。

より大きなディスクスペースをマウントし、/ var / lib / dockerのコンテンツを新しいマウント場所に移動して、シンボリックリンクを作成できます。

上記のタスクを実行する方法についての詳細な説明があります。

http://www.scmtechblog.net/2016/06/clean-up-docker-images-from-local-to.html

中間層も削除できます。

https://github.com/vishalvsh1/docker-image-cleanup