Dockerコンテナが存在する理由を知る方法は？

1G RAMのホストで実行されているDockerコンテナーがあります（同じホストで実行されている他のコンテナーもあります）。このDockerコンテナー内のアプリケーションは、メモリを大量に消費する可能性があるいくつかのイメージをデコードします。

時々、このコンテナは終了します。メモリ不足のせいではないかと思いますが、よくわかりません。根本的な原因を見つける方法が必要です。それで、このコンテナの死に何が起こったかを知る方法はありますか？

他の人はdocker logs $container_id、アプリケーションの出力を表示することについて言及しました。これは常に最初に確認することです。

次に、a docker inspect $container_idを実行して状態の詳細を表示できます。例：

    "State": {
        "Status": "exited",
        "Running": false,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 0,
        "ExitCode": 2,
        "Error": "",
        "StartedAt": "2016-06-28T21:26:53.477229071Z",
        "FinishedAt": "2016-06-28T21:26:53.478066987Z"
    },

重要な行は「OOMKilled」です。これは、コンテナーのメモリ制限を超え、Dockerがアプリを強制終了した場合に当てはまります。また、終了コードを検索して、アプリによる終了の原因が特定されているかどうかを確認することもできます。

これは、Docker自体がプロセスを強制終了するかどうかを示すだけであり、コンテナにメモリ制限を設定している必要があることに注意してください。dockerの外では、ホスト自体のメモリが不足すると、Linuxカーネルがプロセスを無効にする可能性があります。これが発生すると、Linuxは/ var / logのログに書き込むことがよくあります。WindowsおよびMac上のDockerデスクトップでは、Docker設定で組み込みLinux VMに割り当てられたメモリを調整できます。

ログを読むことで、コンテナー内のプロセスがOOMkilledであったかどうかを確認できます。OOMkillはカーネルによって開始されるため、発生するたびにに一連の行があります。/var/log/kern.log次に例を示します。

python invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=995
oom_kill_process+0x22e/0x450
Memory cgroup out of memory: Kill process 31204 (python) score 1994 or sacrifice child
Killed process 31204 (python) total-vm:7350860kB, anon-rss:4182920kB, file-rss:2356kB, shmem-rss:0kB

受け入れられた回答が最良の選択肢ですが、ホストからジャーナルの内容を検査することも役立つ場合があります（Linuxの場合）。

これを行うには、次のように入力します。

sudo journalctl -u docker

またはそれをテーリング

sudo journalctl -u docker -f

または、出力がターミナルバッファに対して長すぎる場合は、出力をlessにパイプします。

journalctl -xn -u docker | less