Dockerコンテナはデフォルトではサーバー再起動後に自動で起動しません。docker restart policy(再起動ポリシー)を正しく設定することで、Dockerデーモンが起動するたびにコンテナも自動で起動させることができます。
この記事では、restart policy の4種類と使い分け、docker-compose.yml での設定方法、systemd ユニットファイルによるコンテナ管理、そして本番環境での推奨設計パターンを段階的に解説します。RHEL 9.4 / Ubuntu 24.04 LTS + Docker 26.x で動作確認済みです。
この記事のポイント
・docker restart policy の unless-stopped がサーバー再起動後の自動起動に本番推奨
・4種類(no / on-failure / always / unless-stopped)を用途に応じて使い分ける
・docker-compose.yml の restart フィールドで複数コンテナに一括設定できる
・起動順序や依存関係の詳細制御が必要な場合は systemd ユニットファイルが有効
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
サーバー再起動後にコンテナが消える理由——restart policyとは
Dockerコンテナはデフォルトで--restart=no(再起動なし)の設定で作成されます。Dockerデーモン(dockerd)がシャットダウンすると起動中のコンテナは全て停止し、サーバーを再起動してdockerdが再起動しても、コンテナは自動では起動しません。restart policy とは、「Dockerデーモンが起動したとき(サーバー起動時)や、コンテナが停止したときにどう扱うか」をDockerに伝える設定です。コンテナごとに設定でき、
docker run の --restart フラグ、または Compose ファイルの restart フィールドで指定します。現在のコンテナに設定されている restart policy は次のコマンドで確認できます。
# コンテナの restart policy を確認する $ docker inspect --format='{{.HostConfig.RestartPolicy.Name}}' コンテナ名 no
no と表示された場合、そのコンテナはサーバー再起動後に自動起動しません。restart policyの4種類と使い分け
Docker が提供する restart policy は4種類です。それぞれの動作を正確に理解することが、サーバー運用の安定性につながります。1. no(デフォルト)
コンテナが停止しても、Dockerは自動で再起動しません。開発・テスト環境や、一時的な作業コンテナに適しています。本番サービスに使うと、サーバー再起動のたびに手動でコンテナを起動し直す必要があります。# restart policy を明示的に no に設定する(デフォルトと同じ動作) $ docker run --restart=no myapp:latest
2. on-failure[:最大再試行回数]
コンテナがゼロ以外の終了コード(異常終了)で停止した場合のみ再起動します。最大再試行回数を省略すると無制限に再起動します。バッチ処理やジョブ実行コンテナで「失敗したらリトライするが、正常終了したら再起動しない」場面に適しています。# 最大5回まで再起動する(5回失敗すると停止したままになる) $ docker run --restart=on-failure:5 myapp:latest
on-failure はサーバー再起動後の自動起動には対応していません。Dockerデーモン自体が再起動する場合は、後述の always か unless-stopped を使う必要があります。3. always
コンテナが停止した理由(正常終了・異常終了・手動停止)に関わらず、常に再起動します。Dockerデーモンの起動時にも自動でコンテナを起動するため、サーバー再起動後の自動起動が有効になります。$ docker run --restart=always myapp:latest
docker stop でコンテナを手動停止しても、Dockerデーモンを再起動すると再び起動してしまいます。「一時的にコンテナを停止したい」という場面では扱いにくい挙動です。4. unless-stopped(本番推奨)
本番環境で最も推奨される設定です。always と似ていますが、docker stop で手動停止したコンテナは、Dockerデーモン再起動後も停止したままになります。「意図的に止めたコンテナは止めたまま、意図せず落ちたコンテナは再起動する」という運用上の直感に沿った動作をします。$ docker run --restart=unless-stopped myapp:latest
| restart policy | 異常終了で再起動 | サーバー再起動後に自動起動 | 手動停止後にデーモン再起動で起動 |
|---|---|---|---|
| no | しない | しない | しない |
| on-failure | する(上限まで) | しない | しない |
| always | する | する | する |
| unless-stopped | する | する | しない |
docker runとdocker-compose.ymlでrestart policyを設定する
1. 既存コンテナのrestart policyを後から変更する
すでに起動中のコンテナに対してdocker update コマンドで restart policy を変更できます。コンテナを停止・削除して作り直す必要はありません。# 稼働中のコンテナの restart policy を unless-stopped に変更する $ docker update --restart=unless-stopped コンテナ名 # 複数のコンテナに一括で設定する $ docker update --restart=unless-stopped コンテナ名1 コンテナ名2 # 変更後に設定を確認する $ docker inspect --format='{{.HostConfig.RestartPolicy.Name}}' コンテナ名 unless-stopped
2. docker-compose.ymlでのrestart設定
Compose で複数コンテナを管理している場合は、各サービスにrestart フィールドを追加します。# docker-compose.yml の例(本番環境向け設定) services: web: image: nginx:latest restart: unless-stopped # 本番推奨 ports: - "80:80" app: image: myapp:latest restart: unless-stopped depends_on: - db db: image: postgres:16 restart: unless-stopped volumes: - db_data:/var/lib/postgresql/data volumes: db_data:
docker compose up -d で起動したコンテナには、Compose ファイルの restart 設定が自動で適用されます。Compose を使う場合、コンテナ起動順序の制御は depends_on と HEALTHCHECK の組み合わせで行います。restart policy と depends_on は異なる役割を担っているため、混同しないよう注意してください。systemdユニットファイルでDockerコンテナを管理する方法
docker restart policy よりも細かい制御が必要な場合——たとえば「NFS マウントが完了してからコンテナを起動したい」「起動失敗時に通知を送りたい」「起動タイムアウトを設けたい」——というときは、systemd ユニットファイルでコンテナを管理する方法が有効です。サーバー起動時間の内訳を確認したい場合は、systemd-analyze で起動時間計測を参照してください。各ユニットの起動所要時間を可視化できます。
1. systemdユニットファイルを作成する
/etc/systemd/system/ ディレクトリに .service ファイルを作成します。以下は Nginx コンテナを systemd で管理する例です。# /etc/systemd/system/docker-nginx.service の内容 [Unit] Description=Nginx Docker Container After=docker.service Requires=docker.service [Service] Type=simple Restart=always RestartSec=10s ExecStartPre=-/usr/bin/docker stop nginx-container ExecStartPre=-/usr/bin/docker rm nginx-container ExecStart=/usr/bin/docker run --name nginx-container --rm -p 80:80 nginx:latest ExecStop=/usr/bin/docker stop nginx-container [Install] WantedBy=multi-user.target
・After=docker.service / Requires=docker.service: Dockerデーモンが起動してからコンテナを起動する(依存関係の明示)
・Restart=always: プロセスが終了したら自動再起動する(systemd の Restart 設定。Dockerのrestart policyとは別物)
・RestartSec=10s: 再起動前に10秒待機する(再起動ループを防ぐためのバックオフ)
・ExecStartPre: 起動前に既存コンテナを停止・削除する(先頭の「-」でコマンド失敗を無視)
・ExecStart:
--rm オプション付きで起動する(コンテナ終了時に自動削除)2. systemdに登録して自動起動を有効にする
# デーモンをリロードして新しいユニットファイルを読み込む $ sudo systemctl daemon-reload # サービスを起動する $ sudo systemctl start docker-nginx.service # サーバー再起動後の自動起動を有効にする $ sudo systemctl enable docker-nginx.service Created symlink /etc/systemd/system/multi-user.target.wants/docker-nginx.service -> /etc/systemd/system/docker-nginx.service. # ステータスを確認する $ sudo systemctl status docker-nginx.service * docker-nginx.service - Nginx Docker Container Loaded: loaded (/etc/systemd/system/docker-nginx.service; enabled; preset: disabled) Active: active (running) since Wed 2026-07-16 10:23:45 JST; 5s ago Main PID: 3847 (docker)
enabled と表示されていれば、サーバー再起動後に自動起動します。
Dockerコンテナを本番環境で安定稼働させるには、restart policy だけでなく監視・ログ設計・セキュリティまで体系的な知識が必要です。現場で通用するDocker本番運用のノウハウを学びたい方は、以下のDocker講座をご覧ください。
→ Dockerマスター講座の詳細はこちら >>
restart policy vs systemd——どちらを選ぶべきか
restart policy と systemd 管理は、それぞれ長所と適切な使いどころが異なります。| 観点 | restart policy | systemd ユニットファイル |
|---|---|---|
| 設定の手軽さ | --restart フラグ一行で完結 | ユニットファイルの作成が必要 |
| 起動順序の制御 | Dockerデーモン依存のみ | After=/Requires= で細かく指定可能 |
| ログ管理 | docker logs で確認 | journalctl でシステムログと統合 |
| 失敗通知 | なし(別途監視が必要) | OnFailure= でアラート実行可能 |
| docker-compose との相性 | 最適(Compose に直接記述) | Compose との併用は複雑になりやすい |
| 主な用途 | アプリコンテナの常駐 | インフラ寄りのサービス管理 |
本番環境での推奨設計パターン
1. 単体コンテナを常駐デーモンとして運用する
単一のコンテナを常駐サービスとして動かす場合の最小構成です。-d(バックグラウンド実行)と --restart=unless-stopped を組み合わせます。# 本番用コンテナ起動の基本形 $ docker run -d --name myapp --restart=unless-stopped -p 8080:8080 -v /data/myapp:/app/data myapp:latest # restart policy の適用を確認する $ docker inspect --format='{{.HostConfig.RestartPolicy.Name}}' myapp unless-stopped
2. docker-compose.yml での本番構成
Compose を使う場合は、全サービスにrestart: unless-stopped を設定しておくのが基本です。開発環境と本番環境で設定を分離したい場合は docker-compose.override.yml を活用してください。# 本番用 docker-compose.yml の推奨構成 services: nginx: image: nginx:1.27 restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro app: image: myapp:1.5.0 # latest タグは本番では使わない restart: unless-stopped environment: - NODE_ENV=production depends_on: db: condition: service_healthy db: image: postgres:16 restart: unless-stopped environment: - POSTGRES_PASSWORD_FILE=/run/secrets/db_password volumes: - db_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 volumes: db_data:
3. Dockerデーモン自体の自動起動を確認する
restart policy はDockerデーモン(dockerd)が起動している前提で動作します。Dockerデーモン自体がサーバー再起動後に起動しない設定になっていると、restart policy も機能しません。次のコマンドでDockerデーモンの自動起動設定を確認してください。# Dockerデーモンの自動起動設定を確認する $ sudo systemctl is-enabled docker enabled # enabled でない場合は有効化する $ sudo systemctl enable docker
enabled でなければ sudo systemctl enable docker で有効化します。これは restart policy を設定する前に必ず確認してください。よくあるトラブルと対処法
1. コンテナが再起動ループに陥る(on-failure設定時)
on-failure を設定したコンテナが起動直後にエラー終了し、短時間で再起動を繰り返すことがあります。docker ps で Restarting ステータスが表示されている場合がこれに当たります。# コンテナのステータス確認 $ docker ps -a CONTAINER ID IMAGE COMMAND STATUS a1b2c3d4e5f6 myapp:latest "run" Restarting (1) 5 seconds ago # ログで原因を確認する $ docker logs --tail=50 コンテナ名 Error: Cannot connect to database at db:5432
docker stop コンテナ名 で再起動ループを止め、docker logs でエラーの原因を確認します。設定ファイルの誤りや依存サービスの未起動が原因であることが多いです。2. 「docker stop」後もコンテナが再起動する
restart policy がalways に設定されている場合、docker stop で停止しても Dockerデーモンを再起動すると再び起動します。意図的に停止した状態を維持したい場合は、unless-stopped に変更するか、コンテナ自体を削除してください。# always から unless-stopped に変更する $ docker update --restart=unless-stopped コンテナ名 # または完全に自動再起動を無効にする $ docker update --restart=no コンテナ名
本記事のまとめ
docker restart policy を正しく設定することで、サーバー再起動後のコンテナ自動起動が実現します。本番環境ではunless-stopped を基本として設定し、Dockerデーモン自体の systemctl enable docker も忘れずに確認してください。| やりたいこと | 設定 |
|---|---|
| サーバー再起動後にコンテナを自動起動する(本番推奨) | docker run --restart=unless-stopped |
| Composeで全サービスに一括設定する | 各サービスに restart: unless-stopped |
| 異常終了時のみ再起動・回数を制限する | docker run --restart=on-failure:5 |
| 既存コンテナのpolicyを変更する | docker update --restart=unless-stopped コンテナ名 |
| 現在のrestart policyを確認する | docker inspect --format='{{.HostConfig.RestartPolicy.Name}}' コンテナ名 |
| 起動順序・依存関係を細かく制御する | systemd ユニットファイル(After=/Requires=) |
| Dockerデーモン自体の自動起動を有効にする | sudo systemctl enable docker |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、docker restart policy の設定からコンテナ本番運用まで体系的に学べるDocker講座を用意しています。
→ Dockerマスター講座の詳細はこちら >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:プライベートDockerレジストリを構築する方法|registryコンテナの運用とDocker Hub rate limit対策
- 前のページへ:docker system pruneでディスク容量を管理する方法|overlay2肥大の原因調査と安全な削除手順
- この記事の属するカテゴリ:Dockerへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます