データが別の場所にあるのに、コンテナがシステムディスクをいっぱいにする原因は何ですか？

ログ、キャッシュ、一時ファイル、または意図しない書き込みがDockerのローカルストレージ内に残ると、コンテナによってシステムディスクがいっぱいになることがあります。

メディアライブラリやデータベースのボリュームを別のプールに移しても、コンテナイメージ、書き込み可能レイヤー、JSONログ、BuildKitキャッシュ、メタデータ、またはマウントリストから漏れたパスまでは移動しません。外部マウントに失敗すると、想定されたホストディレクトリが空のままになり、明らかなエラーなしにアプリケーションがシステムディスクへ新しいデータを書き込むこともあります。

アプリケーションデータを調べる前にDockerのルートディレクトリを計測する

Dockerのデータルートを含むファイルシステムを確認し、ホスト上のディレクトリサイズと、Dockerが集計するイメージ、コンテナ、ボリューム、ビルドキャッシュの使用量を比較します。削除する前に使用量を記録してください。

あるCloudronユーザーは、/var/lib/docker/overlay2が表示されているすべてのアプリケーションデータを合わせた容量を超えていることを発見しました。これは、外部ライブラリとは別にDockerストレージルートを計測する必要性を示しています。

システムディスクがいっぱいで外部プールに空きがある場合は、コンテナ、オーバーレイレイヤー、ボリューム、イメージ、ビルドキャッシュのどこで増加しているかを特定します。アクティブなデータと復旧可能なデータを分類する前に、無差別なpruneを実行しないでください。

無制限に増加するコンテナJSONログを確認する

ログドライバーと各コンテナのログファイルサイズを確認します。サービスが主要データを別の場所に保存していても、標準出力と標準エラー出力がDockerのローカルコンテナディレクトリ内で無制限に増加することがあります。

Code Mavenは、デフォルトのログファイルが概要の外で増え続けていたため、docker system dfでは主な問題が明らかにならなかった事例を紹介しています。見えない容量消費の原因は、増え続けるコンテナログでした。

ログをローテーションまたは切り詰める前に、エラーを大量に出力しているアプリケーションの問題を特定して修正します。今後のコンテナには上限付きのログローテーションを設定し、新しいファイルが想定した上限で増加を停止することを確認してください。

コンテナの書き込み可能レイヤーに書き込まれたデータを探す

想定している永続化パスと、アプリケーションが実際に使用するキャッシュ、トランスコード、ダウンロード、データベース、サムネイル、バックアップ、一時ディレクトリを比較します。マウントされていない書き込みは、すべてシステムディスク上のコンテナの書き込み可能レイヤーに残ります。

Dockerフォーラムの説明によると、書き込みや変更されたイメージファイルは書き込み可能レイヤーに保存され、大容量の未ローテーションログはコンテナメタデータ内に保存されます。外部データボリュームがあっても、これらによって1つのコンテナがローカル容量のほぼすべてを消費することがあります。

コンテナごとのサイズレポートを使用し、コンテナ内で変更量が大きいパスを調べます。永続化が必要なデータにのみ明示的なバインドマウントまたは名前付きボリュームを追加し、価値のあるデータをバックアップした後、コンテナを再作成して不要になった書き込み可能レイヤーの内容を破棄します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

コンテナ起動時に外部マウントが存在していたことを確認する

Dockerがコンテナを起動する前に、SSD、NAS共有、またはストレージプールが想定したホストパスにマウントされていたことを確認します。デバイスの識別情報とマウント出力を、コンテナから見えるディレクトリと比較してください。

外部マウントが存在しない場合でも、システムファイルシステム上の基盤となる空のディレクトリは残っていることがあります。コンテナはそのフォールバックディレクトリへ通常どおり書き込めるため、外部プールに変化がないように見える一方で、システムディスクが増加します。

データが入ったフォールバックディレクトリの上にストレージを再マウントする前に、コンテナを停止します。隠れたファイルを安全に移動または調整し、マウント依存関係や起動時チェックを追加して、想定したデバイスがない場合はアプリケーションの起動を拒否します。

イメージレイヤー、ビルドキャッシュ、放置されたオブジェクトを調べる

未使用のイメージ、停止したコンテナ、匿名ボリューム、BuildKitキャッシュを確認します。アプリケーションの永続データが正しく別の場所にマウントされていても、頻繁な更新やローカルビルドによって多数のレイヤーが蓄積することがあります。

Mobyプロジェクトのフォーラムの説明では、オーバーレイマウントによってディスク使用量の把握が難しくなること、また基盤ファイルシステムの使用量を注意深く解釈する必要があることが説明されています。別のHome Assistantの事例でも、時間の経過とともにログとレイヤーによるoverlay2の増加が確認されています。

現在のComposeプロジェクトとバックアップによって未使用であることを確認できたオブジェクトだけを削除します。Dockerのメタデータ参照が不整合になる可能性があるため、個々のoverlay2ディレクトリを手動で削除しないでください。

増加量のベースラインで修正を検証する

原因となったパスを修正した後、以前増加を引き起こしたワークロードを実行しながら、Dockerルートの使用量、ログサイズ、コンテナの書き込み可能サイズ、外部プールの使用量を定期的に記録します。

ZimaSpaceの大容量NAS転送のステージングワークフローは、データが意図したプールに保存されることを確認するための再現可能な負荷を提供します。

システムディスクの増加が想定されるイメージとログの動作に一致し、永続的なアプリケーションデータが外部プールで増加し、外部マウントがない場合にはルートファイルシステムへ黙って書き込むのではなく安全に起動が失敗することを確認できて初めて、問題は解決したといえます。