Dockerコンテナを再起動！`docker restart` の基本と応用

By /

Dockerコンテナ再起動のすべて！docker restartコマンド完全ガイド – 基本から応用、トラブルシューティングまで

Dockerコンテナは、現代のアプリケーション開発や運用において不可欠な存在となっています。軽量で移植性が高く、開発環境と本番環境の差異を最小限に抑えることができるコンテナ技術は、多くの企業で採用されています。コンテナを運用する上で避けて通れないのが、コンテナのライフサイクル管理です。コンテナの起動、停止、そして再起動は、日常的な管理タスクの一部となります。

この記事では、Dockerコンテナを再起動するための主要なコマンドである docker restart に焦点を当て、その基本的な使い方から、知っておくべき詳細、応用例、そしてトラブルシューティングまでを網羅的に解説します。コンテナの再起動は単純な操作に見えますが、その背後には様々な仕組みや考慮すべき点があります。この記事を通じて、docker restart コマンドをマスターし、より堅牢で効率的なコンテナ運用を実現するための一助となれば幸いです。

1. はじめに：なぜコンテナを再起動するのか？

Dockerコンテナは、一度起動すれば基本的に指定されたプロセスが動き続けます。しかし、運用中にコンテナを再起動する必要が生じる場面は多々あります。主な理由としては以下のようなものが挙げられます。

  • 設定変更の適用: コンテナ内で動作するアプリケーションの設定ファイルを変更した場合、その変更を反映させるためにアプリケーションプロセスを再起動する必要があります。多くの場合、コンテナ自体を再起動するのが最も簡単で確実な方法です。
  • 一時的な問題からの回復: ネットワークの一時的な瞬断、外部サービスの一時的な障害、コンテナ内のリソース不足など、様々な理由でアプリケーションが異常な状態に陥ることがあります。多くの場合、コンテナを再起動することで問題が解決し、正常な状態に回復することが期待できます。
  • リソースの解放: 長時間稼働しているコンテナがメモリリークなどを起こし、リソースを過剰に消費することがあります。再起動によってコンテナ内のプロセスを終了させ、リソースを解放することで、システムの安定性を維持できます。
  • アプリケーションのデプロイ/アップデート: 新しいバージョンのアプリケーションイメージに置き換える際に、既存のコンテナを停止・削除し、新しいイメージでコンテナを再作成・起動するのが一般的ですが、設定変更などを伴わない軽微なアップデートであれば、単にコンテナを再起動することで新しい設定やパッチを適用できる場合もあります（ただし、これはイメージ自体を変更しない場合であり、通常は新しいイメージでコンテナを作り直します）。
  • 定期メンテナンス: システムの安定稼働のために、定期的にコンテナを再起動して状態をリフレッシュする運用を採用する場合もあります。

コンテナの再起動は、これらの問題を解決するための重要な手段の一つです。そして、Dockerでは docker restart という専用のコマンドが用意されています。

2. docker restart コマンドの基本

docker restart コマンドは、指定されたDockerコンテナを停止し、その後再び起動するコマンドです。非常にシンプルに使うことができます。

2.1. 基本構文

docker restart コマンドの基本的な構文は以下の通りです。

bash
docker restart [OPTIONS] CONTAINER [CONTAINER...]

  • [OPTIONS]: コマンドの動作を制御するためのオプションを指定します。主なオプションについては後述します。
  • CONTAINER: 再起動したいコンテナを指定します。コンテナは1つ以上指定できます。

2.2. コンテナの指定方法

CONTAINER を指定する方法はいくつかあります。

  • コンテナID: コンテナの一意なID（長い文字列）。IDの先頭の数文字だけでも、一意に特定できれば指定可能です。
    bash
    docker ps -a # コンテナIDを確認
    docker restart a3f # 例: IDがa3f...で始まるコンテナを再起動
  • コンテナ名: コンテナ作成時に --name オプションで指定した名前、またはDockerが自動生成した名前。
    bash
    docker restart my-web-server # 例: 'my-web-server' という名前のコンテナを再起動

どちらの方法でも指定できますが、通常は管理しやすいコンテナ名で指定することが多いでしょう。

2.3. 最もシンプルな使い方

単一のコンテナを再起動する場合、最もシンプルなコマンドは以下のようになります。

bash
docker restart <コンテナ名またはコンテナID>

実行例:

まず、テスト用のコンテナを起動します。

bash
docker run -d --name my-test-container alpine sh -c "while true; do echo hello world; sleep 1; done"

docker ps でコンテナが実行中であることを確認します。

bash
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
<container_id> alpine "sh -c 'while true; d…" About a minute ago Up About a minute my-test-container

次に、このコンテナを再起動します。

bash
docker restart my-test-container
my-test-container

コマンドを実行すると、指定したコンテナ名（またはID）が表示され、コマンドが成功したことを示します。再起動後、再び docker ps を実行すると、コンテナの STATUS が一度 Exited になり、すぐに Up に戻っていることが確認できます（ステータスの変化は非常に速いので、目視では難しい場合もあります）。CREATED からの時間もリセットされているか、再起動されたタイミングが反映されていることがわかります。

2.4. 複数のコンテナを一度に再起動

docker restart コマンドは、複数のコンテナを引数として指定することで、一度に複数のコンテナを再起動できます。

bash
docker restart <コンテナ名1> <コンテナ名2> <コンテナID3> ...

実行例:

テスト用のコンテナをもう一つ起動します。

bash
docker run -d --name another-container alpine sh -c "while true; do echo another; sleep 1; done"

docker ps で2つのコンテナが実行中であることを確認します。

bash
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
<id1> alpine "sh -c 'while true; d…" 2 minutes ago Up 2 minutes my-test-container
<id2> alpine "sh -c 'while true; d…" 5 seconds ago Up 4 seconds another-container

2つのコンテナを同時に再起動します。

bash
docker restart my-test-container another-container
my-test-container
another-container

2.5. すべての実行中のコンテナを再起動

Dockerホスト上で現在実行中のすべてのコンテナを再起動したい場合があります。これは、docker ps -q コマンドと組み合わせて実現できます。docker ps -q は、実行中のコンテナのIDのみをリストアップするコマンドです。

bash
docker restart $(docker ps -q)

このコマンドは、バッククォート（または $()）内の docker ps -q コマンドの出力（実行中のコンテナIDのリスト）を docker restart コマンドの引数として渡します。これにより、リストアップされたすべてのコンテナが再起動されます。

注意: docker ps -aq を使うと、停止中のコンテナも含め、すべてのコンテナのIDをリストアップします。docker restart は停止中のコンテナも起動させることができるため、意図せず停止中のコンテナが起動してしまう可能性があります。実行中のコンテナのみを対象とする場合は -q を、すべてのコンテナ（停止中も含む）を再起動/起動したい場合は -aq を使用してください。一般的には、実行中のコンテナのみを対象とすることが多いでしょう。

3. docker restart のオプション詳解

docker restart コマンドには、再起動の挙動を細かく制御するためのオプションがいくつかあります。最も重要なオプションは --time です。

3.1. -t, --time <seconds>

このオプションは、コンテナを停止する際に、Graceful Shutdown を試みるための「猶予期間（秒）」を指定します。

bash
docker restart --time <seconds> <container>

  • <seconds>: コンテナ内のメインプロセスに SIGTERM シグナル（終了要求）を送信してから、Dockerが強制終了（SIGKILL シグナル送信）を行うまでの待ち時間を秒単位で指定します。デフォルト値は 10秒 です。

仕組み:

docker restart コマンドは、内部的に以下のステップを実行します。

  1. 指定されたコンテナに対して、停止処理を開始します。
  2. コンテナ内のメインプロセスに SIGTERM シグナルを送信します。このシグナルは、アプリケーションに対して「終了する準備をしてください」と優しく伝えるためのものです。アプリケーションはこのシグナルを受け取って、現在処理中のタスクを完了させたり、開いているファイルを閉じたり、データベースへの接続を切断したりといった終了処理（Graceful Shutdown）を実行することが期待されます。
  3. 指定された --time の秒数だけ待ちます。
  4. 猶予期間が経過してもコンテナが停止しない場合、Dockerはコンテナ内のメインプロセスに SIGKILL シグナルを送信します。これは、アプリケーションに終了処理を行う機会を与えず、プロセスを強制的に終了させるシグナルです。

なぜ --time が重要なのか？

アプリケーションが Graceful Shutdown を適切に実行できるよう設計されている場合、SIGTERM を受け取ってから終了するまでの間に、データの一貫性を保ったり、進行中のリクエストを完了させたりすることができます。--time オプションで十分な猶予期間を与えることで、アプリケーションは安全に終了し、データの損失や破損を防ぐことができます。

逆に、--time が短すぎたり、アプリケーションが SIGTERM を適切に処理できない場合、指定時間が経過すると強制的に SIGKILL が送信され、アプリケーションが予期せぬ状態で終了する可能性があります。これは、データ損失や、再起動後のアプリケーションの不安定化につながる可能性があります。

--time 0 の意味:

--time 0 を指定すると、SIGTERM を送信せずに、即座に SIGKILL を送信してコンテナを強制終了させます。

bash
docker restart --time 0 my-container

これは、アプリケーションが SIGTERM を無視するか、ハングアップして正常に終了できない場合に、迅速にコンテナを停止させたい場合に有用です。ただし、アプリケーションが Graceful Shutdown のロジックを持っている場合は、データ損失のリスクがあるため注意が必要です。デバッグ目的や、データの永続性が不要な一時的なコンテナに対して使用することが多いでしょう。

適切な --time の設定:

適切な --time の値は、アプリケーションの Graceful Shutdown にかかる時間によって異なります。アプリケーションが終了処理に数秒かかる場合は、デフォルトの10秒で十分かもしれません。しかし、完了までに数分かかるような長時間タスクを処理している可能性がある場合は、より長い時間を設定する必要があります。理想的には、アプリケーションの終了処理に必要な最大時間を把握し、それに合わせて --time を設定します。

アプリケーションが SIGTERM シグナルをどのように扱うかは、コンテナの ENTRYPOINT または CMD で実行されるプロセスに依存します。シェルスクリプトで複数のプロセスを起動している場合など、シグナルが正しくメインプロセスに伝わらないことがあります。このような場合は、tini のような軽量なinitシステムをコンテナ内で使用することを検討すると良いでしょう。

3.2. その他のオプション

docker restart コマンドには、--time 以外の目立ったオプションはほとんどありません。シンプルさがこのコマンドの特徴です。

4. 再起動の仕組みと Graceful Shutdown

docker restart が単にコンテナを「再起動」しているのではなく、「停止してから起動し直している」ことを理解することが重要です。この「停止」のプロセスにおいて、Graceful Shutdown が重要な役割を果たします。

4.1. 再起動処理のステップ

docker restart <container>（デフォルトの --time 10 の場合）の内部処理は以下のようになります。

  1. Dockerデーモンは、指定された <container> に停止を指示します。
  2. Dockerデーモンは、コンテナ内のPID 1（通常は ENTRYPOINT または CMD で指定されたメインプロセス）に SIGTERM (シグナル番号 15) シグナルを送信します。
  3. Dockerデーモンは 10秒間 待ちます。この間に、アプリケーションはSIGTERMを受け取って終了処理を行います。
  4. 10秒以内にメインプロセスが終了した場合、コンテナは停止状態 (Exited) になります。停止処理は完了です。
  5. 10秒経過してもメインプロセスが終了しない場合、Dockerデーモンはコンテナ内のPID 1に SIGKILL (シグナル番号 9) シグナルを送信します。このシグナルは捕捉・無視できないため、プロセスは即座に強制終了されます。
  6. コンテナが停止状態になったら、Dockerデーモンはコンテナを起動する処理を開始します。
  7. コンテナは作成時の設定（イメージ、ポートマッピング、ボリュームなど）を使用して再起動され、ENTRYPOINT または CMD で指定されたコマンドが再び実行されます。

4.2. アプリケーションとシグナル処理

コンテナ化されたアプリケーションは、これらのシグナルを適切に処理するように設計されている必要があります。

  • SIGTERM (15): プロセスに安全なシャットダウンを促すためのシグナルです。多くのサーバーアプリケーションやフレームワークは、SIGTERM を受け取ると、新しい接続の受け付けを停止し、既存の接続の処理を完了させ、クリーンアップ処理を行ってから終了するように実装されています。アプリケーション開発者は、SIGTERM ハンドラを実装することで、この Graceful Shutdown のロジックを定義します。
  • SIGKILL (9): プロセスを即座に強制終了させるシグナルです。このシグナルは捕捉できないため、アプリケーションは SIGKILL に対して何も対処できません。突然の終了は、データ不整合やリソースリークの原因となる可能性があります。

デフォルトの docker restart は、まず SIGTERM で Graceful Shutdown を試み、それでも停止しない場合にのみ SIGKILL で強制終了するという、安全な方法を採用しています。したがって、コンテナ内で実行するアプリケーションが SIGTERM を適切に処理できるかどうかが、再起動の成功とデータの安全性にとって非常に重要になります。

Dockerfileで STOPSIGNAL 命令を使用すると、SIGTERM 以外のシグナルを Graceful Shutdown 用として指定できます。例えば、一部のアプリケーションは SIGINT (Ctrl+C で送信されるシグナル) で終了するのが一般的です。その場合、STOPSIGNAL SIGINT を Dockerfile に追加することで、docker stop や docker restart 実行時に SIGINT を送信するように変更できます。

5. 応用編

docker restart コマンド単体だけでなく、他のDocker機能やツールと組み合わせることで、より高度なコンテナ管理が可能になります。

5.1. 自動再起動ポリシー (Restart Policies)

Dockerには、コンテナが予期せず停止した場合や、Dockerデーモンが再起動した場合に、コンテナを自動的に再起動させるための「再起動ポリシー」という機能があります。これは docker run や docker create コマンドの --restart オプションで設定します。

docker restart コマンドは、この再起動ポリシーの設定に関わらず、明示的に指定されたコンテナを停止・起動し直すコマンドです。しかし、自動再起動ポリシーはコンテナの「期待される状態」を定義する上で重要なので、ここで併せて解説します。

--restart オプションの値:

  • no: (デフォルト) コンテナが停止しても、Dockerは自動的に再起動しません。
  • on-failure[:max-retries]: コンテナが非ゼロの終了コード（エラー終了）で停止した場合にのみ、コンテナを再起動します。オプションで再起動の最大試行回数を指定できます。
  • always: コンテナが停止した場合、常に自動的に再起動します。Dockerデーモンが起動した際にも、停止していたコンテナを起動します。
  • unless-stopped: コンテナが停止した場合、常に自動的に再起動します。ただし、ユーザーが明示的に docker stop または docker container stop コマンドで停止した場合は、Dockerデーモンが再起動してもコンテナは自動的に起動しません。ユーザーが明示的に docker start または docker container start コマンドで起動するまで停止したままになります。

例: docker run 時の再起動ポリシー設定

コンテナがエラー終了した場合に最大5回まで再起動を試みる設定でコンテナを起動する例:

bash
docker run -d --name my-app --restart on-failure:5 my-app-image

Dockerデーモンが起動した際に常に再起動する設定でコンテナを起動する例:

bash
docker run -d --name my-service --restart always my-service-image

既存のコンテナの再起動ポリシー変更:

docker update コマンドを使用すると、実行中のコンテナの再起動ポリシーを変更できます。

bash
docker update --restart unless-stopped my-app

docker restart と再起動ポリシーの関係:

docker restart コマンドを実行すると、コンテナは一旦停止し、その後起動されます。このプロセス自体は再起動ポリシーの影響を受けませんが、再起動ポリシーはコンテナが停止した 後 の挙動に影響を与えます。

例えば、--restart unless-stopped ポリシーを持つコンテナに対して docker restart を実行した場合：
1. docker restart がコンテナを停止します。この停止は明示的な停止 ではない と見なされます。
2. docker restart がコンテナを起動します。
3. コンテナが起動中に何らかの理由で停止した場合、ポリシーが unless-stopped なので自動的に再起動が試みられます。

一方、--restart unless-stopped ポリシーを持つコンテナに対して docker stop を実行した場合：
1. docker stop がコンテナを停止します。これは明示的な停止と見なされます。
2. コンテナは停止したままになります。
3. Dockerデーモンが再起動しても、このコンテナは自動的に起動しません。ユーザーが docker start するまで停止したままです。
4. この停止中のコンテナに対して docker restart を実行すると、コンテナは起動します。そして、もし次にこのコンテナがエラーなどで停止した場合、再び unless-stopped ポリシーに従って自動再起動が試みられます（ユーザーが明示的に停止したという状態がリセットされるため）。

このように、docker restart はポリシーに関わらず実行されますが、その後の自動再起動の挙動は設定されたポリシーに依存します。特に unless-stopped ポリシーを使用している場合は、docker stop と docker restart の挙動の違いを理解しておくことが重要です。

5.2. 特定の条件での再起動（スクリプトや監視ツール連携）

運用においては、特定の条件が満たされたときにコンテナを再起動したい場合があります。これはシェルスクリプトや監視ツールと docker restart コマンドを組み合わせることで実現できます。

例1: 停止中のコンテナがあれば再起動するシェルスクリプト

“`bash

!/bin/bash

再起動対象のコンテナ名をリストアップ

CONTAINERS=(“my-web-server” “my-database”)

for container in “${CONTAINERS[@]}”; do
# コンテナの状態を取得
STATUS=$(docker inspect –format ‘{{.State.Status}}’ “$container” 2>/dev/null)

# コンテナが存在しないか、状態が ‘running’ でない場合
if [ “$STATUS” != “running” ]; then
echo “$container is not running (status: $STATUS). Restarting…”
# 再起動を実行
docker restart “$container”
if [ $? -eq 0 ]; then
echo “$container restarted successfully.”
else
echo “Failed to restart $container.”
fi
else
echo “$container is running.”
fi
done
“`

このスクリプトは、指定されたコンテナのリストをチェックし、running 状態でない場合に docker restart を実行します。cronなどで定期的に実行することで、コンテナが停止した場合に自動的に再起動を試みることができます。ただし、これは最も単純な例であり、エラーハンドリングや再起動ループ防止などの考慮が必要です。本番環境では、Dockerの自動再起動ポリシーや、Kubernetesのようなオーケストレーションツールを利用する方が一般的です。

例2: ログ監視ツールとの連携

Fluentd, Logstash, Promtailなどのログ収集・監視ツールを使用している場合、特定の致命的なエラーログが出力されたことをトリガーとして、監視スクリプトやWebhookなどを介して docker restart コマンドを実行する仕組みを構築できます。

5.3. Docker Compose での再起動

Docker Compose を使用している場合、コンテナの再起動は Compose ファイルで定義されることが一般的です。Compose ファイルでは、各サービスの再起動ポリシーを restart ディレクティブで設定できます。

docker-compose.yml 例:

“`yaml
version: ‘3.8’
services:
web:
image: nginx:latest
ports:
– “80:80”
restart: always # このサービスは常に自動再起動する

app:
image: my-custom-app:latest
restart: on-failure:3 # このサービスはエラー終了した場合に最大3回再起動する
# … その他の設定
“`

Docker Compose CLI を使用してサービスを操作する場合、対応するコマンドは以下のようになります。

  • サービスの起動: docker compose up (コンテナが存在しない場合は作成・起動、既に存在する場合は起動)
  • サービスの停止: docker compose down (サービスに関連するコンテナやネットワークなどを削除) または docker compose stop <service_name> (サービスに関連するコンテナを停止)
  • サービスの再起動: docker compose restart [service_name...]

docker compose restart [service_name...] コマンドは、指定されたサービス（または何も指定しない場合はComposeファイル内のすべてのサービス）に関連付けられたコンテナに対して docker restart と同様の操作を行います。

bash
docker compose restart web # webサービスに関連するコンテナを再起動
docker compose restart # Composeファイル内のすべてのサービスに関連するコンテナを再起動

Docker Compose環境で個別のコンテナに対して docker restart <container_name> を直接実行することも可能ですが、Composeで管理しているサービスは docker compose restart を使用する方が、Composeファイルで定義された設定に基づいて操作されるため、より管理しやすいでしょう。

5.4. Kubernetes との比較

Docker単体でのコンテナ運用から、Kubernetesのようなコンテナオーケストレーションツールに移行することも多いでしょう。Kubernetesにおいても、Pod内のコンテナの再起動は重要な概念ですが、その管理方法はDockerとは異なります。

Kubernetesでは、Podの定義において restartPolicy を指定します。これはDockerの --restart オプションに相当しますが、適用される対象やタイミングが異なります。

Kubernetes Pod の restartPolicy:

  • Always: Pod内のコンテナが終了コードに関わらず終了した場合、kubeletがコンテナを再起動します。KubernetesでPodをデプロイする場合の一般的なポリシーです。
  • OnFailure: Pod内のコンテナが非ゼロの終了コードで終了した場合にのみ、kubeletがコンテナを再起動します。
  • Never: Pod内のコンテナが終了しても、kubeletは再起動しません。

restartPolicy はPod内のコンテナが「異常終了」した場合にkubeletが自動的に行う「回復処理」としての再起動を制御します。

Kubernetesで特定のPodやDeployment内のコンテナを明示的に再起動したい場合は、Dockerの docker restart のような直接的なコマンドは通常使用しません。代わりに、以下の方法が取られます。

  • Deployment のローリングアップデート: DeploymentのPodテンプレート（イメージバージョンなど）を変更し、ローリングアップデートを開始します。これにより、古いPodが新しいPodに順次置き換わっていき、結果的にすべてのPod内のコンテナが新しい設定で再起動（実質的には再作成）されます。
    bash
    kubectl rollout restart deployment/<deployment_name>
    このコマンドは、DeploymentのPodテンプレートにアノテーションを追加することで、意図的にPodテンプレートが変更されたとKubernetesに認識させ、ローリングアップデートをトリガーします。
  • Pod の削除: 対象のPodを削除します。DeploymentやReplicaSetによって管理されている場合、コントローラーが Pod の不足を検知し、同じ設定で新しい Pod を自動的に作成します。
    bash
    kubectl delete pod <pod_name>

このように、Kubernetesではコンテナ単体を直接操作するよりも、上位の概念（Pod, Deploymentなど）を操作し、Kubernetesコントローラーに意図した状態への遷移を任せるのが基本的な考え方です。Docker単体の docker restart はコンテナという単一のリソースに対する直接的な操作ですが、Kubernetesでは「望ましい状態（Desired State）」を宣言し、システムがその状態を維持しようとする仕組みの中で再起動が行われます。

6. docker restart の利用シナリオ詳細

docker restart コマンドが具体的にどのような場面で役立つのか、もう少し詳細なシナリオを考えてみましょう。

  • Webサーバーの設定変更: NginxやApacheなどのWebサーバーコンテナで設定ファイル（nginx.conf など）を変更した場合、通常は設定ファイルをリロードするか、プロセスを再起動する必要があります。多くの場合、設定ファイルはコンテナのボリュームとしてマウントされているか、新しいイメージでコンテナを作り直す必要がありますが、もし一時的に設定ファイルを手で編集した場合（非推奨）、その変更を反映させるためには docker restart が最も手っ速い方法となります。
  • データベース接続のリフレッシュ: アプリケーションが長時間稼働する中で、データベース接続プールに問題が発生したり、データベースサーバー側で接続が切断されたりすることがあります。アプリケーションによっては、コンテナを再起動することで新しい接続プールが再構築され、問題が解消されることがあります。
  • 開発環境での状態リセット: 開発中にアプリケーションの挙動がおかしくなった場合、コンテナを再起動することでクリーンな状態からやり直すことができます。これはデバッグの初期ステップとして非常に有効です。
  • 一時的なネットワーク問題からの回復: コンテナが外部のサービスと通信している際に、一時的なネットワーク障害が発生した場合、アプリケーションがその障害から回復できないことがあります。コンテナを再起動することで、ネットワークの状態が正常に戻っていれば、アプリケーションも正常に起動し直すことができます。
  • メモリリークやリソース枯渇の疑い: コンテナが徐々にメモリを消費していく（メモリリーク）などの問題を抱えている場合、定期的に再起動することで、システム全体のリソース枯渇を防ぐことができます。これは根本的な解決ではありませんが、一時的な対処としては有効です。

これらのシナリオでは、コンテナを完全に削除して再作成するよりも、docker restart を使用する方が手軽で迅速な場合があります。ただし、本番環境では、再起動だけで解決しない根深い問題（バグ、設定ミス、インフラ問題など）も多く存在するため、再起動をあくまで一時的な回避策とし、根本原因の特定と修正に努めることが重要です。

7. docker restart の注意点とトラブルシューティング

docker restart は強力で便利なコマンドですが、使用上の注意点や、再起動がうまくいかない場合の対処法を知っておく必要があります。

7.1. Graceful Shutdown の重要性と --time オプション

前述しましたが、コンテナ内のアプリケーションが Graceful Shutdown を適切に実行できるかどうかが非常に重要です。アプリケーションが SIGTERM を無視したり、終了処理に時間がかかりすぎる場合、--time で設定した猶予期間が経過すると強制終了（SIGKILL）されてしまいます。

トラブルシューティング: アプリケーションが Graceful Shutdown できない疑いがある場合：
* アプリケーションのログを確認し、SIGTERM を受け取った際の挙動や、終了処理中にエラーが発生していないかを確認します。
* アプリケーションのコードや設定を確認し、SIGTERM を捕捉して適切に終了処理を行うロジックが実装されているか確認します。
* --time オプションの値を増やしてみて、終了に十分な時間を確保できるか試します。
* コンテナ内で tini のようなinitシステムを使用することを検討します。

7.2. 再起動に失敗する場合

docker restart コマンドを実行してもコンテナが正常に再起動せず、停止状態のままになったり、起動してもすぐに終了してしまう場合があります。このような場合の一般的なトラブルシューティングの手順を以下に示します。

  1. コンテナの状態を確認: docker ps -a コマンドで対象のコンテナの状態（STATUS）を確認します。Exited (<Exit Code>) となっている場合、終了コードを確認します。非ゼロの終了コードはエラーが発生したことを示します。
  2. コンテナのログを確認: docker logs <container_id> コマンドでコンテナの標準出力と標準エラー出力を確認します。アプリケーションが起動時や実行中にエラーを出力していないかを確認します。これが原因特定に最も役立ちます。
  3. コンテナの詳細情報を確認: docker inspect <container_id> コマンドで、コンテナのすべての設定と現在の状態（State）を確認します。特に State セクションの ExitCode, Error, Status, Restarting などのフィールドがヒントになります。HostConfig の RestartPolicy が意図通りになっているかも確認できます。
  4. リソースの確認: Dockerホスト自体のCPU、メモリ、ディスク容量が不足していないか確認します。リソース不足が原因で新しいプロセスが起動できない場合があります。
  5. イメージの問題: 使用しているDockerイメージ自体に問題がある（例: 依存関係が欠けている、設定ファイルが不正など）可能性があります。別のイメージでコンテナを起動できるか試したり、イメージのビルド手順を見直したりします。
  6. 依存関係の問題: コンテナが起動する際に外部サービス（データベース、キャッシュなど）に接続できないと、起動プロセスが失敗することがあります。依存するサービスが正常に稼働しているか確認します。
  7. ボリュームのマウントの問題: ボリュームのマウント設定が間違っている、またはマウント先のディレクトリに適切な権限がない場合、コンテナ内のプロセスがファイルを読み書きできずに起動に失敗することがあります。
  8. Dockerデーモンの状態: Dockerデーモン自体に問題が発生している可能性もゼロではありません。systemctl status docker（Systemdを使用している場合）などでDockerデーモンの状態を確認し、必要に応じてDockerデーモンを再起動します（ただし、これは最後の手段としてください）。

多くの場合、原因はコンテナのログに出力されています。ログを確認するのがトラブルシューティングの最初のステップであり、最も重要なステップです。

7.3. 停止中のコンテナへの docker restart

docker restart コマンドは、既に停止しているコンテナに対しても実行できます。この場合、コマンドは単にコンテナを起動（docker start）します。

bash
docker stop my-container # コンテナを停止
docker ps -a # 状態が Exited になっていることを確認
docker restart my-container # 停止中のコンテナを起動
docker ps # 状態が Up になっていることを確認

このように、docker restart は実行中のコンテナを停止・起動し直すだけでなく、停止中のコンテナを起動する用途にも使えます。ただし、停止中のコンテナを単に起動したいだけであれば、docker start コマンドの方が意図が明確になります。

7.4. 再起動ポリシーとの連携における注意

unless-stopped ポリシーを持つコンテナに docker restart を実行した後、もしそのコンテナが予期せず停止した場合、Dockerはポリシーに従って自動的に再起動を試みます。これは docker stop を実行した場合の挙動（明示的な停止となり自動起動しない）とは異なる点です。

8. 関連コマンド

docker restart コマンドと関連性の高いコマンドをいくつか紹介します。これらのコマンドと組み合わせることで、コンテナのライフサイクル管理をより柔軟に行えます。

  • docker stop <container_id | container_name>: 指定されたコンテナを停止します。デフォルトでは SIGTERM を送信し、10秒後に SIGKILL を送信して強制終了します。--time オプションも使用できます。docker restart の最初のステップとほぼ同じです。
  • docker start <container_id | container_name>: 停止中の指定されたコンテナを起動します。docker restart の最後のステップです。停止中のコンテナを起動するだけであれば、docker start を使うのが適切です。
  • docker kill <container_id | container_name>: 指定されたコンテナにシグナルを送信します。デフォルトでは SIGKILL を送信し、強制的にコンテナを終了させます。Graceful Shutdown を試みずに即座に終了させたい場合に使いますが、通常は docker stop が推奨されます。特定のシグナルを送信したい場合は --signal オプションを使用します。
  • docker update <container_id | container_name>: 実行中のコンテナの設定（例: 再起動ポリシー --restart）を変更します。コンテナを再作成せずに設定を変更できる便利なコマンドです。
  • docker ps [-a]: 実行中のコンテナのリストを表示します (-a オプションで停止中のコンテナも含む)。再起動対象のコンテナの状態やID、名前を確認する際に必須のコマンドです。
  • docker logs <container_id | container_name>: コンテナのログ（標準出力および標準エラー出力）を表示します。再起動がうまくいかない場合のデバッグに最も重要なコマンドです。

これらのコマンドは、Dockerコンテナの運用において頻繁に使用される基本的なコマンドです。docker restart を効果的に使用するためにも、これらの関連コマンドの使い方も理解しておくことが推奨されます。

9. まとめ

この記事では、Dockerコンテナを再起動するための docker restart コマンドについて、その基本的な使い方から詳細な仕組み、応用、そしてトラブルシューティングまでを詳しく解説しました。

  • docker restart は、指定されたコンテナを停止し、その後再び起動するためのコマンドです。
  • コンテナIDまたはコンテナ名で対象を指定できます。複数のコンテナを一度に指定することも可能です。
  • 最も重要なオプションは --time であり、これは Graceful Shutdown のための猶予期間を設定します。デフォルトは10秒です。
  • 再起動処理は、まず SIGTERM シグナルによる Graceful Shutdown を試み、指定時間内に終了しない場合は SIGKILL で強制終了するという安全な手順で行われます。コンテナ内のアプリケーションが SIGTERM を適切に処理できることが重要です。
  • docker restart は Docker の自動再起動ポリシーとは独立して動作しますが、ポリシーは再起動 後 のコンテナの自動回復挙動に影響します。
  • スクリプトや監視ツール、Docker Compose と連携させることで、より自動化された再起動管理が可能です。
  • Kubernetes では、Podテンプレートの変更やPodの削除といった、より上位のリソース操作を通じて間接的にコンテナの再起動に相当する操作を行います。
  • 再起動が失敗した場合は、docker logs や docker inspect を使用して原因を特定することが重要です。

docker restart はシンプルでありながら、コンテナの状態をリフレッシュしたり、一時的な問題から回復させたりするための強力なツールです。しかし、その背後にある Graceful Shutdown の仕組みや、再起動ポリシー、関連コマンドとの連携を理解することで、より安全かつ効率的にコンテナを運用できるようになります。

日々のコンテナ管理において、この記事が docker restart コマンドを自信を持って使いこなし、問題発生時にも冷静に対処するための一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール