2.3 Dockerコンテナのライフサイクル完全解説｜状態遷移・終了コード・再起動ポリシー

Dockerコンテナは「起動したら終わり」ではありません。created → running → paused → exited → deleted という明確な状態を持ち、各状態でできる操作・できない操作が決まっています。この仕組みを理解していないと、「コンテナが消えた」「ログが見えない」「起動したはずが動いていない」といったトラブルに悩まされます。

この記事ではコンテナのライフサイクルを状態マシンとして完全解説します。

目次

1. コンテナの5つの状態
2. シミュレータで状態遷移を体験する
3. created ── 作成済み・未起動
4. running ── 実行中
5. paused ── 一時停止
6. exited ── 停止済み
7. 終了コード（Exit Code）の読み方
8. コンテナの削除
9. 再起動ポリシー（–restart）
10. –rm フラグと docker container prune
11. OOM Killer ── メモリ超過による強制終了
12. まとめ

1. コンテナの5つの状態

Dockerコンテナは常に次のいずれかの状態にあります。

状態遷移の全体像をまず把握しましょう：

2. シミュレータで状態遷移を体験する

下のシミュレータで、コマンドボタンを押して実際に状態を遷移させてみましょう。左の図で現在の状態がハイライトされ、右パネルに詳細情報が表示されます。

3. created ── 作成済み・未起動

created 状態は、コンテナのファイルシステムと設定が準備されたが、メインプロセスがまだ起動していない状態です。

created になる操作

# docker create: コンテナを作成するが起動しない
docker create --name myapp nginx

# docker run はコンテナを作成 → 即座に起動するため、
# created 状態は一瞬しか続かない（通常は意識しない）

docker create は「コンテナを事前に準備しておき、必要なときに docker start する」用途に使います。Docker Compose が複数コンテナを一括で作成するときに内部的に使用しています。

4. running ── 実行中

running 状態は、メインプロセス（PID 1）が動作中の状態です。コンテナとして最も正常な状態であり、docker ps（-a 不要）で確認できます。

# running に移行するコマンド
docker run nginx                # イメージから起動（フォアグラウンド）
docker run -d nginx             # バックグラウンド起動
docker start mycontainer        # 停止中コンテナを再起動

# running 状態でできること
docker logs -f mycontainer      # ログ追跡
docker exec -it mycontainer sh  # コンテナ内でコマンド実行
docker stats mycontainer        # リソース使用量確認
docker top mycontainer          # コンテナ内プロセス一覧

running から他の状態に移行するトリガー

5. paused ── 一時停止

paused 状態は、Linux の cgroups freezer サブシステムによってコンテナ内の全プロセスが凍結された状態です（第1章 1-5 参照）。

# 一時停止
docker pause mycontainer

# 再開
docker unpause mycontainer

# 確認（STATUS 列が "Paused" になる）
docker ps

pause の特徴

一時停止は本番での高負荷時のリソース確保や、コンテナのスナップショット取得（チェックポイント）の前処理として使われます。通常の開発では多用しません。

6. exited ── 停止済み

exited 状態は、コンテナのメインプロセスが終了した後の状態です。コンテナ自体（書き込みレイヤー・ログ・メタデータ）はディスクに残っています。

# exited コンテナを確認
docker ps -a
# CONTAINER ID   IMAGE     ...   STATUS
# a1b2c3d4e5f6   nginx     ...   Exited (0) 5 minutes ago
# f6e5d4c3b2a1   ubuntu    ...   Exited (1) 2 hours ago

# exited コンテナのログはまだ確認できる
docker logs a1b2c3

# exited コンテナを再起動
docker start a1b2c3

# exited コンテナを削除
docker rm a1b2c3

溜まった exited コンテナはディスクを消費します。不要なら docker container prune で一括削除しましょう。

7. 終了コード（Exit Code）の読み方

コンテナが exited 状態になったとき、docker ps -a の STATUS 列に Exited (N) と終了コードが表示されます。この数値から何が原因で終了したかを判断できます。

# 終了コードを取得する方法
docker inspect --format='{{.State.ExitCode}}' <コンテナID>

# OOM（メモリ超過）による強制終了かどうかを確認
docker inspect --format='{{.State.OOMKilled}}' <コンテナID>
# true が返ればメモリ超過による SIGKILL

# 直前に終了したコンテナのコードを確認（シェルスクリプトで利用）
docker run --rm myapp
echo $?   # docker run コマンドの終了コード = コンテナの終了コード

8. コンテナの削除

コンテナを削除（docker rm）すると、そのコンテナの書き込みレイヤー・ログ・メタデータがすべて消去されます。イメージは残ります。

# 停止中コンテナを削除
docker rm mycontainer

# 実行中コンテナを強制削除（stop + rm の組み合わせ）
docker rm -f mycontainer

# 停止中コンテナを一括削除
docker container prune
# WARNING! This will remove all stopped containers.
# Are you sure you want to continue? [y/N]

# 確認なしで一括削除
docker container prune -f

# 特定フィルタで削除（1日より古い停止コンテナ）
docker container prune --filter "until=24h"

9. 再起動ポリシー（–restart）

コンテナが exited になったとき、Dockerデーモンに自動的に再起動させるかどうかを制御するのが再起動ポリシーです。

docker run --restart=<ポリシー> イメージ名

# 本番 nginx: デーモン起動時に自動起動し、意図的な停止は維持
docker run -d --restart=unless-stopped --name web nginx

# 最大5回までリトライするバッチ処理
docker run --restart=on-failure:5 myjob

# 既存コンテナのポリシーを変更（Docker 1.13以降）
docker update --restart=always mycontainer

再起動のバックオフ

再起動ポリシーが設定されているコンテナが繰り返し失敗すると、Dockerは指数バックオフ（100ms → 200ms → 400ms → … 最大5分）で再起動間隔を延ばします。これにより、クラッシュループが起きてもシステム全体に影響しません。

10. –rm フラグと docker container prune

--rm フラグを付けて docker run すると、コンテナが exited になった瞬間に自動的に削除されます。

# 実行後に自動削除（一時的な作業に最適）
docker run --rm alpine echo "hello"
docker run --rm ubuntu:22.04 bash -c "uname -a"

# ビルド作業（現在のディレクトリをマウント）
docker run --rm -v "$(pwd)":/work -w /work node:20 npm test

# ツールとして使う（ホストにツールをインストールしたくないとき）
docker run --rm python:3.12 python -c "import this"

定期的なクリーンアップ

# 停止コンテナ・未使用イメージ・ネットワーク・ビルドキャッシュを一括削除
docker system prune

# ディスク使用量の内訳を確認
docker system df

# 出力例:
# TYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLE
# Images          12      3        2.34GB    1.89GB (80%)
# Containers      8       2        142MB     138MB (97%)
# Local Volumes   4       2        1.2GB     0B (0%)
# Build Cache     23      0        892MB     892MB

11. OOM Killer ── メモリ超過による強制終了

コンテナのメモリ使用量がホストの利用可能メモリを超えると、Linuxカーネルの OOM（Out of Memory）Killer がコンテナのプロセスを SIGKILL で強制終了します。結果として終了コードは 137、OOMKilled: true になります。

# メモリ上限を設定して起動（メモリ超過を防ぐ）
docker run --memory=256m --memory-swap=256m myapp

# OOM Killer で終了したか確認
docker inspect --format='{{.State.OOMKilled}}' mycontainer
# true → OOM Killerによる強制終了

# メモリ使用量をリアルタイム確認
docker stats mycontainer

cgroup によるメモリ制限の仕組みはシミュレータで体験できます：

12. まとめ

再起動ポリシー早見表

参考リンク

• 再起動ポリシーのリファレンス（公式） — –restart オプションの詳細仕様
• Start containers automatically（公式） — 自動起動の設定ガイド
• docker container prune（公式） — 停止コンテナの一括削除
• Runtime resource constraints（公式） — メモリ・CPU 制限の詳細（OOM 含む）

Dockerの基礎を動画で体系的に学びませんか？

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

クーポン割引で講座を見る →