Dockerのログでホストの起動ドライブがいっぱいになるのを防ぐには？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Do You Stop Docker Logs From Filling a Host Boot Drive? - Zima Store Online

即時にログを生成しているプロセスを停止し、使用中のログ保存先を特定してから、上限付きのローテーションを適用し、ログの大量出力を引き起こしているエラーや再起動ループを修正します。

DockerベースのNASやホームサーバーでは、メディアやデータベースを別のプールに保存していても、コンテナの標準出力と標準エラー、systemdジャーナルのデータ、アプリケーション固有のファイルがシステムファイルシステム内に残っているため、ブートドライブが満杯になることがあります。安全な手順は、まず直近の証拠を十分に残し、制御不能な増加を止め、どのログ層が容量を使用しているかを分類し、既存および今後のサービスに保持期間を設定し、基盤となるアプリケーションが同じ量のログを出力し続けていないことを確認することです。

実際に増大しているログ保存先を特定する

まずブートファイルシステムの空き容量を確認し、Dockerのデータルート、コンテナごとのログファイル、システムジャーナル、ホストからマウントされたアプリケーションのログディレクトリのサイズを比較します。何かを削除または切り詰める前に、最大のパスを記録してください。

あるDockerのディスク容量に関する事例では、通常のDockerの概要では主な使用先が判明しませんでした。デフォルトのログファイルが別途増大していたためです。決定的な証拠は、ローカルのDockerストレージパスにある増え続けるコンテナログでした。

実行中の各コンテナに設定されているログドライバーとログパスを確認し、最大のファイルをコンテナ名および直近のメッセージと照合します。コンテナログで使用量を説明できない場合は、Docker関連のディスク問題がすべてjson-fileに起因すると決めつけず、journaldやアプリケーション固有のフォルダーも調査してください。

緊急クリーンアップの前にノイズの多いコンテナを停止する

ブートドライブの空き容量が少ない場合は、最も速く増大しているコンテナを一時停止または停止します。容量を解放する前に、ログの末尾を一定量保存し、再起動回数、終了状態、イメージのバージョン、環境変数、マウント、最初に繰り返されたエラーを記録してください。

管理者は、サイズ制限が設定されていない場合、コンテナのJSONログが残りのディスク容量を消費することに気付くことがよくあります。長期間続いているStack Overflowの議論では、無制限のJSONログ増大が、イメージやボリュームのデータとは別の容量リスクとして説明されています。

Dockerがアクティブなログファイルを開いたままの状態で、ログファイルを無闇に削除しないでください。また、Dockerのメタデータツリーから任意のディレクトリを削除してはいけません。ログの生成元を停止した後、プラットフォームでサポートされているローテーションまたは切り詰めの手順だけを使用し、影響を受けたサービスを再起動する前に、解放されたブロックが確認できることを確かめてください。

長時間稼働する各サービスに上限付きローテーションを適用する

Composeのサービス設定またはコンテナ設定で、明示的なログドライバーと有限のローテーション制限を設定します。一般的なJSONドライバーでは、重要な設定は最大ファイルサイズと保持するファイル数の制限です。

Dockerコミュニティのローテーションに関するスレッドでは、max-sizeやmax-fileなどのオプションによって、1つのコンテナがローカルに保持する履歴の量を制限できると説明されています。運用上必要なのは、無期限に増大する1つのファイルではなく、有限のローテーションポリシーです。

インシデントを診断するまでに必要な時間と、ホストが安全に確保できるブートディスク容量に基づいて制限値を決めます。サービスを再作成して、実行中のコンテナに新しいログ設定を適用し、その有効な設定を確認したうえで、小規模な制御テストを実行して、想定どおりファイルがローテーションされることを確認してください。

Featured

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

ZimaCube2

既存のコンテナが変更されるとは限らないことを前提に、今後のコンテナ用のデフォルトを設定する

新しく作成されるコンテナに対するデーモンまたはプラットフォームレベルのデフォルトを設定し、サービス側で設定を省略した場合に、ローカルログが無制限に戻らないようにします。診断上の要件が異なる重要なサービスでは、より厳しい個別設定を適用できるようにしておきます。

Dockerのログ設定のデフォルトを変更しても、既存のすべてのコンテナのホスト設定が遡って書き換えられるわけではありません。同じコミュニティガイダンスでは、デーモンのデフォルトと、コンテナごとの作成時設定が区別されています。そのため、既存のサービスは確認し、意図的に再作成する必要があります。

まず重要度の低いサービス1つに変更を適用します。ログの取得、監視、アラート、サポートのワークフローが引き続き機能することを確認してから、永続ボリュームを削除せず、残りのサービスを管理可能な単位で順番に再作成してください。

ログの大量出力を引き起こしている事象を修正する

ローテーション制限は被害を抑えますが、数秒ごとに再起動するコンテナ、到達できないデータベースへの再試行、すべてのヘルスチェックの記録、攻撃や大量リクエスト、トラブルシューティング後にデバッグモードのままになった設定を修復するものではありません。

あるDockerユーザーは、約80GBのJSONログの原因を過剰なデバッグ出力と特定しました。この事例は、ローテーションが当面の安全策であっても、デバッグレベルの出力がブートドライブを圧迫する可能性を示しています。

繰り返されるメッセージを頻度と最初の発生時刻でグループ化し、最初の根本エラーを修正します。接続、マウント、シークレット、準備状態の失敗によってログストームが発生している場合は、再起動ループの原因となる依存関係の特定に関するZimaSpaceのガイドが、次の診断に役立ちます。

Docker、journald、アプリケーション固有のログを分けて追跡する

コンテナは標準出力をDockerに送る一方で、バインドマウント内に独自のファイルを書き込むことがあります。また、Dockerサービス自体がデーモンのイベントをjournaldに送信する場合もあります。それぞれの保存先には異なる保持管理者が存在し、同じブートファイルシステムを独立して満杯にする可能性があります。

Dockerレベルのローテーションで抑制されるはずだと考えていたにもかかわらず、アプリケーションのログディレクトリが増大したという報告が、ホームサーバーの運用者から寄せられています。TrueNASコミュニティの事例は、制限を調整する前に、どのログ層が保持を管理しているかを特定する必要性を示しています。

修正後の基準値として、ブートディスクの使用量、最大のログファイル、ジャーナルサイズ、コンテナの再起動回数、1日あたりの増加量を記録します。すべてのアクティブな保存先に上限付きポリシーが設定され、ノイズの多いサービスが通常の負荷で安定し、意図的に再起動しても無制限のファイルが再生成されないことを確認して、初めて修復が完了したと判断できます。