
環境バージョン:
macos 10.14.4
docker server 18.09.2
docker desktop Version 2.0.0.3 (31259)
コンテナ内でエラーが発生しno space left on device
、オーバーフローがどこから発生したのかを判断できません。
最悪なのは、マザーホストシステムの観点から実際のコンテナサイズを判断できないことです (info/inpsect/system df ツール)。実際、docker とマザーホストの統計は等しくありません :/
内部に次の df 統計を含むコンテナーがあります。
root@31a71014ad95:/usr/local/app# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 63G 21G 40G 34% /
tmpfs 64M 0 64M 0% /dev
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
osxfs 234G 182G 48G 80% /shared_from_host
/dev/sda1 63G 21G 40G 34% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 2.0G 0 2.0G 0% /proc/acpi
tmpfs 2.0G 0 2.0G 0% /sys/firmware
(shared_from_host
- はマザーホストとの統合のための共有ボリュームです)
macOS の一般的な画像ファイル サイズについて読んだのですが、問題ないようですし、デフォルトの 64 GB サイズからは程遠いようです。
ls -lah ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
-rw-r--r--@ 1 coin staff 21G May 26 22:25 /Users/usss/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
Docker コンテナには大きなサブディレクトリが必ず含まれています:
root@31a71014ad95:/usr/local/app# du -hs ./*|grep CRISP
12G ./CRISPRCasFinder
コンテナのディスク使用量統計を推定するための推奨方法として、、を見ps -s
ましたが、成功しませんでした。それらはすべて実際の値を表示しません。そのため、私はこれらのツールを間違った方法で使用しており、数字を間違った方法で解釈しているようです。inspect
system df
母ホストからの統計は次のようになります:
docker inspect
与えるhttps://pastebin.com/53vLji1pdocker ps -s
与える
%docker container ps -sa
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE
31a71014ad95 nvm:nvm_tag "/bin/bash" 6 hours ago Exited (137) 23 minutes ago cr 3.52GB (virtual 5.44GB)
<...>
docker system df
与える
%docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 8 6 5.52GB 3.021GB (54%)
Containers 6 0 3.541GB 3.541GB (100%)
Local Volumes 33 6 2.751GB 2.381GB (86%)
Build Cache 0 0 0B 0B
これらの値はいずれも、du を使用したコンテナの使用状況 (上記参照) のようには見えません。これらの値は注目すべき値でしょうか?
私が見つけた最も有用で詳細な例はhttps://www.projectatomic.io/blog/2016/03/daemon_option_basedevicesize/
しかし、私の現在のDockerバージョンでは、出力には著者がイラストに使用している「基本デバイスサイズ」や「DeviceSize」などのフィールドが含まれなくなっているようです。
質問は次のとおりです:
実際のコンテナ使用状況の統計を確認して、調整を適用するにはどうすればよいでしょうか。
最大コンテナディスクサイズの構成はどこにありますか?
ありがとう!
アップデート
docker アプリを再起動しようとしましたが、すべて致命的なスペース エラーが発生しました -https://pastebin.com/twM3qN8N
つまり、docker は現時点ではまったく起動しません。わかりました... gh でも非常によく似た問題を見つけました -参考: docker for mac の最新バージョンをダウンロード.
以前、動作不良に関する問題を見たことがあります。qcow2 ファイルを削除すると修正されますが、サイズが近い場合は常にスペースの問題がありused
、configured
問題はサイズ変更にありました。しかし、この問題は私の問題とほぼ同じで、原因は qcow2 ファイルのサイズが十分に大きいことです。
一時的な回避策としてすべてのデータを消去することが分かりましたが、全力で消去する前に代替手段、または少なくともディスク使用率メトリックに関する何らかの説明を見つけたいと思っています。
アップデート2
qcow なしでの部分的な決定は明確だが理解がない
あらゆる種類の記事を読み続け、読んだ後http://phutchins.com/blog/2017/01/04/fixing-docker-no-space-left-on-device/
df -h
そして、2017 年のデフォルトの奇妙な 20 GB 制限に気づきました。そして考えました。想像してみましょう。コンテナー内とUI 設定では約 64 GB と報告されているにもかかわらずdocker desktop
、まだ 20 GB の制限があります。あり得そうですか?
そして、記事に書かれているように、qemu をインストールし、イメージに +5Gb を追加しました。
%qemu-img resize ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2 +5G
すると、すべてが起動して動作しました。qemu ファイルのサイズは依然として同じです。
%ls -lah ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
-rw-r--r--@ 1 usss staff 21G May 27 00:46 /Users/usss/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2
しかし、コンテナの観点からの使用法は少し変わりました
root@31a71014ad95:/usr/local/app# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 68G 21G 45G 32% /
tmpfs 64M 0 64M 0% /dev
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
osxfs 234G 178G 55G 77% /shared_from_host
/dev/sda1 68G 21G 45G 32% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 2.0G 0 2.0G 0% /proc/acpi
tmpfs 2.0G 0 2.0G 0% /sys/firmware
現在は 45Gb 利用可能と表示されています (上記は 40Gb でした)。
しかし、少なくとも今はすべて機能していますが、shadowed
消費がどこに隠れているかはまったく理解されていません。
答え1
デスクトップ バージョンの Docker のディスク領域は、組み込み Docker VM に割り当てたディスクによって制限される場合があります。この VM 内には、イメージ、コンテナー、名前付きボリューム、および外部ソース (MacOS の /Users ディレクトリなど) から VM に明示的にマウントされていないその他のファイルがあります。この VM の設定は、Docker の設定から調整できます。
詳細については以下をご覧ください。スペース
ディスクの使用に関する重要な注意点の 1 つは、ディスクのバイト数が不足する可能性があり、inode も不足する可能性があることです。どちらも同じエラーが発生します。indoesdf -i
を確認するには、次のオプションを使用します。
df -h # to see disk free
df -hi # to see inodes free
コンテナの実行中にエラーが発生し、その後コンテナが削除された場合、コンテナの削除によってそのディスク領域が解放される可能性があります。