Docker の隠れたデフォルトによりシステム メモリが消耗されます。これを修正します。

Docker を使用すると、実行中のソフトウェアが軽量に感じられますが、その利便性のおかげで、コストのかかるデフォルトが隠されています。コンテナーはメモリや CPU の上限なしで開始されるため、忘れられた 1 つのサービスが 24 時間静かにマシンのリソースを消費する可能性があります。この問題が発生する理由と、それに対して何ができるかを説明します。

問題: デフォルトではリソース制限がない

コンテナは必要なものを必要なときにいつでも取り出すことができます

プレーンな docker run コマンドでコンテナーを実行すると、Docker はメモリや CPU の制限をまったく適用しません。コンテナーは、カーネルが許可する限りホストのリソースを使用できます。これは、使い始めるには賢明なデフォルトですが、何週間も稼働し続けるものとしては貧弱です。コンテナーは使い捨てのように感じられるため、多くの人がデータベース、テスト API、またはセルフホスト アプリを起動し、ターミナルを閉じて、その存在を忘れてしまいます。バックグラウンドで実行され続け、メモリを保持し、スケジュールされたタスク、ヘルス チェック、またはポーリング ループごとに CPU を起動します。

アイドル状態のコンテナが劇的に見えることはほとんどないため、危険性は微妙です。忘れられたサービスが使用するのは数百メガバイトだけかもしれませんが、そのうちのいくつかが合計され、単一のメモリ リークが他のすべてを枯渇させるまで増大する可能性があります。 Linux では、ホストのメモリが不足すると、カーネルのメモリ不足キラーがプロセスの終了を開始しますが、常に不正な動作をしているコンテナを選択するとは限りません。データベース、SSH セッション、または Docker デーモン自体を簡単にダウンさせる可能性があります。

この状況は Windows と macOS ではさらに顕著です。 Docker Desktop は仮想マシン内でコンテナを実行し、コンテナが必要とするかどうかに関係なく、その VM が RAM のチャンクを予約します。 WSL2 を搭載した Windows では、vmmem プロセスは、それを要求したワークロードが停止した後も長時間にわたってギガバイトのメモリを保持する可能性があります。そのため、ラップトップの動作が遅くなり、明らかな理由もなくファンが回転し始めるのです。

そして、Docker はこれについて何も警告しません。コンテナーがどのくらいのメモリを取得する必要があるかを尋ねるプロンプトはなく、何かが 3 か月間実行されても通知はありません。意図的に docker 統計情報を確認したり、Docker Desktop ダッシュボードを開いたりしない限り、症状はマシンが必要以上に遅く感じることだけであり、バックグラウンドで静かに実行されているコンテナーに明確な原因があるわけではありません。

修正方法

制限を設定し、クリーンアップし、実行中のものを監視する

考えすぎないでください。コンテナーをセットアップするときに制限を設定します。 –memory フラグは使用できる RAM の量を制限し、–cpus フラグは受け取るプロセッサ時間を制限します。メモリを 512 MB に設定し、CPU を 1.5 に設定するコマンドにより、暴走プロセスが抑制されます。コンテナーがメモリの上限を超えると、Docker はホストを引きずらずにコンテナーを停止します。また、メモリが不足した場合にのみ適用されるソフト制限として機能するメモリ予約や、プロセスが無限に子プロセスを生成するのを防ぐ PID 制限を設定することもできます。

Docker Compose を使用する場合、同じコントロールが構成ファイル内に存在します。サービスのデプロイ セクションでは、リソース ブロックは CPU とメモリの両方の制限を受け入れ、Compose の現在のバージョンは Swarm を必要とせずにこれらの値を尊重します。それらを一度定義すると、誰かがフラグを覚えていることに依存するのではなく、すべてのチームメイトとすべてのデプロイメントが同じ境界線を取得することになります。

制限は、適切な数値がどのようなものかを知っている場合にのみ役立つため、最初に監視してください。 docker stats を実行すると、すべてのコンテナーのライブ CPU とメモリ使用量が表示され、数日間観察すると、各サービスが実際にどれだけ必要かを知ることができます。通常のスパイクによって再起動が引き起こされないように、観察されたピークよりも若干高い値に制限を設定します。

最後に、使わなくなったものを片付けます。 docker ps コマンドは実行中のものをリストし、docker stop は不要なものをすべてシャットダウンします。 docker system prune を実行すると、停止したコンテナー、未使用のネットワーク、未解決のイメージ、ビルド キャッシュがクリアされ、ボリューム オプションを追加すると、孤立したボリュームも削除されます。これを 1 回限りの修正ではなく習慣として扱い、マシンが徐々にいっぱいにならないように数週間ごとに見直してください。

その他の軽微な問題

ログ、再起動ポリシー、デスクトップ設定の合計

変更する価値があるデフォルトはリソース制限だけではありません。 Docker の標準の json ファイル ログ ドライバーはログをローテーションしません。つまり、おしゃべりなコンテナーは、ギガバイトのディスク領域を消費するまで単一のログ ファイルに書き込むことができます。これを修正するには、デーモン構成ファイルで max-size オプションと max-file オプションをコンテナごとに、またはグローバルに設定します。通常、3 つのファイルで 10 MB の制限は、家庭用セットアップや小規模サーバーには十分です。

再起動ポリシーは、より静かな問題を引き起こす可能性があります。コンテナーを常に再起動するように設定すると、意図的に停止した場合でも、再起動するたびに、またクラッシュするたびにコンテナーが戻ってくることになります。壊れたコンテナは無限ループし、失敗して再び起動するときに CPU を消費する可能性もあります。停止しない場合のポリシーは手動シャットダウンを尊重しますが、最大再試行回数による失敗時は無限のクラッシュ ループを防ぎます。

健康診断も一見の価値があります。数秒ごとに実行されるチェック、特にスクリプトの起動やデータベースへのクエリのチェックでは、継続的なバックグラウンド アクティビティが作成されます。間隔を 30 秒以上に伸ばすと、ほとんどのサービスで十分であり、オーバーヘッドが大幅に削減されます。

Docker Desktop では、設定メニューで仮想マシンが要求できるメモリ、CPU、ディスクの量を制限できますが、これらの値は必要以上に大きく設定されることがよくあります。 WSL2 を実行している Windows ユーザーは、ユーザー フォルダーに .wslconfig ファイルを作成して、サブシステム全体のメモリとプロセッサを制限し、次のコマンドで再起動できます。 wsl --shutdown。ラップトップでは、小さな調整でも目に見える違いが生じます。

最後に、画像サイズは時間の経過とともに重要になります。スリムまたは Alpine ベースのイメージは、使用するディスク容量が少なく、ダウンロードが速く、多くの場合バックグラウンド プロセスが少ない状態で出荷されるため、すべてが軽量になります。

今すぐ制限を設定して、サイレントなリソースの消耗を停止します。

Docker のデフォルトでは、効率よりも利便性が優先され、コンテナーは無制限にリソースを自由に消費できます。メモリと CPU の制限を設定し、ログをローテーションし、賢明な再起動ポリシーを選択し、定期的にプルーニングすることで、マシンの応答性を維持し、管理されていないコンテナーが引き起こす追跡が困難な低速の速度低下を回避できます。