web-dev-qa-db-ja.com

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
57
ming.kernel

これは、デバイスマッパーのカーネルの問題であり、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

これによりスペースが取り戻されましたが、それは単に代替インスタンスを起動することと大差ありません。より良い解決策は見つかりませんでした。

51

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

ソリューション1:

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

前:

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 info

ソリューション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

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

ナサニエルワイズブロット 受け入れられた回答でこれに言及した issue そして、私はこの問題からいくつかの情報を得た)


または

古いバージョンのDockerのコマンド1.13.x(Sudoではなくルートとして実行):

# 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)

After:

> 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
40
rjdkolb

私は同様の問題を抱えていましたが、これはすべての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-23230107

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

    Sudo rm -rf/var/lib/docker

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

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

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

Sudo dockerd -s devicemapper --storage-opt dm.fs=xfs --storage-opt dm.mountopt=discard
5
rodolk

/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を再構成する必要はありません。

3
Ajay Sharma

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

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

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

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

3
Jiang Jun

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

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

docker system Prune --volume
2
Nirbhay Shah

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

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

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

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

中間層も削除できます。

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

docker system Pruneを試して、重要ではないすべての画像を削除することができます

0
Max