Docker/OSX は「デバイスに空き容量がありません」という理由を見つけることができません

Docker/OSX は「デバイスに空き容量がありません」という理由を見つけることができません

環境バージョン:

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ましたが、成功しませんでした。それらはすべて実際の値を表示しません。そのため、私はこれらのツールを間違った方法で使用しており、数字を間違った方法で解釈しているようです。inspectsystem df

母ホストからの統計は次のようになります:

  1. docker inspect与えるhttps://pastebin.com/53vLji1p

  2. docker 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)
<...>
  1. 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」などのフィールドが含まれなくなっているようです。

質問は次のとおりです:

  1. 実際のコンテナ使用状況の統計を確認して、調整を適用するにはどうすればよいでしょうか。

  2. 最大コンテナディスクサイズの構成はどこにありますか?

ありがとう!

アップデート

docker アプリを再起動しようとしましたが、すべて致命的なスペース エラーが発生しました -https://pastebin.com/twM3qN8N

つまり、docker は現時点ではまったく起動しません。わかりました... gh でも非常によく似た問題を見つけました -参考: docker for mac の最新バージョンをダウンロード.

以前、動作不良に関する問題を見たことがあります。qcow2 ファイルを削除すると修正されますが、サイズが近い場合は常にスペースの問題がありusedconfigured問題はサイズ変更にありました。しかし、この問題は私の問題とほぼ同じで、原因は 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 の設定から調整できます。

MacOS 用 Docker のディスク設定

画像クレジット: docker ドキュメント

詳細については以下をご覧ください。スペース


ディスクの使用に関する重要な注意点の 1 つは、ディスクのバイト数が不足する可能性があり、inode も不足する可能性があることです。どちらも同じエラーが発生します。indoesdf -iを確認するには、次のオプションを使用します。

df -h # to see disk free
df -hi # to see inodes free

コンテナの実行中にエラーが発生し、その後コンテナが削除された場合、コンテナの削除によってそのディスク領域が解放される可能性があります。

関連情報