Dockerコンテナの停止・再起動・終了を徹底解説！コマンドとトラブル対応

Dockerコンテナ操作の全体像と最短コマンド

コンテナライフサイクルの理解と基本コマンド

Dockerコンテナを効果的に運用するためには、そのライフサイクルと各段階で用いる基本コマンドを理解することが不可欠です。コンテナは「起動・実行中 (Running)」、「停止 (Stopped/Exited)」、「再起動 (Restart)」、「削除 (Removed)」という主要な状態を遷移します。`docker run`で新規に起動し、`docker stop`で実行中のプロセスを停止させますが、この時点ではコンテナ自体はシステム上に残存します。一方、`docker rm`コマンドはコンテナの実体を完全に破棄するため、内部に書き込まれたデータも同時に失われます。適切なコンテナ管理は、リソースの最適化と運用コスト削減、そしてトラブルの未然防止に直結します。特に、開発環境では頻繁にコンテナの生成と破棄を行うため、これらのコマンド操作を習熟しておくことは基本中の基本と言えるでしょう。

`docker stop`で安全に停止する手順

実行中のDockerコンテナを安全に停止させるには、`docker stop`コマンドを使用します。このコマンドは、指定されたコンテナに対してまず終了シグナル（SIGTERM）を送信します。これにより、コンテナ内のアプリケーションは優雅な終了（Graceful Shutdown）を行う機会を得ることができます。例えば、開いているファイルを閉じたり、処理中のリクエストを完了させたりといった処理です。デフォルトでは、SIGTERM送信から10秒間、アプリケーションが自律的に終了するのを待ちます。この待機時間を過ぎてもコンテナが終了しない場合、強制終了シグナル（SIGKILL）が送信され、プロセスは強制的に停止されます。これにより、意図しないデータ破損や予期せぬ挙動を防ぎながらコンテナを停止できます。

具体的なコマンドは以下の通りです。

docker stop [コンテナIDまたはコンテナ名]

例えば、`my_web_app`という名前のコンテナを停止する場合、`docker stop my_web_app`と実行します。複数のコンテナを停止したい場合は、スペースで区切って記述することも可能です。

`docker restart`で迅速に再起動する方法

停止しているコンテナを再度実行状態に戻したり、実行中のコンテナを再起動したりする際には、`docker restart`コマンドが非常に便利です。このコマンドは、内部的に`docker stop`を実行し、その後すぐに`docker start`を実行するのと同じ効果を持ちます。つまり、コンテナのプロセスを一度終了させ、その状態を保持したまま再開させるため、設定変更の適用や軽微なトラブルからの復旧に役立ちます。

例えば、アプリケーションの設定ファイルをコンテナにマウントしている場合、設定ファイルを変更した後に`docker restart`を実行することで、変更を素早く反映させることができます。また、メモリリークなどの一時的な問題でコンテナの動作が不安定になった際にも、再起動は手軽な解決策となる場合があります。

docker restart [コンテナIDまたはコンテナ名]

このコマンドも`docker stop`と同様に、対象のコンテナIDやコンテナ名を指定して実行します。稼働中のサービスに影響が出ないよう、計画的に実行することが重要です。

基本的なコンテナ停止・再起動・削除の手順

実行中コンテナの一覧表示と特定

Dockerコンテナを操作する上で、現在どのようなコンテナが稼働しているのか、また過去にどのようなコンテナが作成されたのかを把握することは第一歩です。これには主に二つのコマンドを使用します。

• `docker ps`: 現在実行中のコンテナのみを表示します。これにより、アクティブなサービスをすぐに確認できます。
• `docker ps -a`または`docker ps –all`: 実行中・停止中に関わらず、すべてのコンテナを表示します。停止したまま放置されているコンテナや、予期せず終了してしまったコンテナを見つける際に役立ちます。

これらのコマンドを実行すると、コンテナID、イメージ名、コマンド、作成日時、ステータス、ポートマッピング、コンテナ名などの情報が表示されます。停止や削除を行いたいコンテナの「CONTAINER ID」または「NAMES」を確認し、次の操作に利用します。特に、コンテナ名が明確に設定されている場合は、IDよりも直感的に識別できるため、命名規則を設けることが推奨されます。

停止コマンドと強制停止の使い分け

コンテナを停止する際には、状況に応じて`docker stop`と`docker kill`の使い分けが重要になります。前述の通り、`docker stop`はSIGTERMシグナルを送信し、アプリケーションが安全にシャットダウンする機会を与えます（デフォルト10秒）。この方式は、データの一貫性を保ち、アプリケーションが正常に終了するために最も推奨される方法です。しかし、アプリケーションがSIGTERMに応答しない、あるいは非常に緊急な状況で即座にコンテナを停止する必要がある場合には、`docker kill`コマンドを使用します。

docker kill [コンテナIDまたはコンテナ名]

`docker kill`は、即座にSIGKILLシグナルを送信し、アプリケーションのプロセスを強制的に終了させます。これにより、待機時間なしでコンテナを停止できますが、アプリケーションによっては処理中のデータが失われたり、破損したりするリスクがあるため、最後の手段として利用することが望ましいです。特にデータベースなどの永続的なデータを扱うコンテナでは、データ損失のリスクを最小限に抑えるためにも、まずは`docker stop`を使用し、タイムアウトしても停止しない場合に限り`docker kill`を検討する姿勢が大切です。また、`docker stop`に`-t`オプションを付けて待機時間を短縮することも可能です（例: `docker stop -t 5 my_container`）。

コンテナ削除（`rm`）とデータ永続化の重要性

不要になったコンテナは、`docker rm`コマンドで削除できます。これにより、コンテナのファイルシステムやメタデータがシステムから完全に消去され、リソースの解放につながります。しかし、コンテナを削除すると、その内部に書き込まれたすべてのデータも一緒に削除されてしまう点に注意が必要です。例えば、Webサーバーのアクセスログやデータベースのデータ、アプリケーションの設定ファイルなどがこれに該当します。

docker rm [コンテナIDまたはコンテナ名]

このデータ損失を防ぐためには、Dockerのデータ永続化機能であるボリューム（Volumes）やバインドマウント（Bind Mounts）を積極的に活用することが不可欠です。これらの機能を用いることで、コンテナ内部の特定のディレクトリをホストOS上のディレクトリやDockerが管理する永続ストレージにマッピングし、コンテナが削除されてもデータが失われないようにできます。コンテナを削除する前に、必要なデータがボリュームやバインドマウントによってホスト側に保存されているか、必ず確認するようにしてください。これにより、コンテナはいつでも安全に削除・再作成できる「使い捨て」の原則に基づいた運用が可能になります。

全てのコンテナ操作と特定のコンテナ対処法

全ての実行中コンテナを一括停止する方法

複数のコンテナが同時に稼働している環境では、一つずつ停止コマンドを実行するのは手間がかかります。そのような場合、一度に全ての実行中コンテナを停止する便利な方法があります。これは、`docker ps -q`コマンドの出力を`docker stop`コマンドの引数として渡すことで実現できます。`docker ps -q`は、実行中のコンテナのIDのみをリスト形式で出力するため、これを活用します。

docker stop $(docker ps -q)

このコマンドを実行すると、現在稼働しているすべてのコンテナに対し、順次`docker stop`が適用されます。これにより、アプリケーションが安全にシャットダウンするための猶予が与えられ、意図しないデータ損失のリスクを低減できます。例えば、ホストマシンのメンテナンスを行う前や、Dockerデーモン自体を再起動する前など、一時的に全てのサービスを停止したい場合に非常に有効です。ただし、意図しない重要なコンテナまで停止してしまう可能性があるため、実行前には必ず`docker ps`で稼働中のコンテナを確認し、安全性を確認してください。

不要な停止中コンテナを一括削除するコマンド

開発やテストを繰り返していると、停止状態のコンテナが多数残り、ディスクスペースを圧迫したり、管理が煩雑になったりすることがあります。これらの不要な停止中コンテナを一括で削除し、システムをクリーンアップするためのコマンドも存在します。

docker container prune

このコマンドは、停止中のコンテナのみを全て削除します。実行すると確認メッセージが表示されるため、意図しないコンテナが削除されるリスクを軽減できます。もう一つの方法は、`docker ps -aq –filter status=exited`で停止中のコンテナIDを抽出し、`docker rm`で削除する方法です。

docker rm $(docker ps -aq --filter status=exited)

どちらの方法も効果的ですが、特に`docker container prune`はコンテナ以外の未使用リソース（イメージ、ボリューム、ネットワーク）も削除できる`docker system prune`の一部であり、システム全体のクリーンアップに役立ちます。定期的なクリーンアップは、ディスク容量の確保だけでなく、誤って古いコンテナを再利用してしまうといったミスを防ぐ上でも重要です。

特定のコンテナをターゲットにした柔軟な操作

Docker環境が複雑になるにつれて、特定の条件を満たすコンテナだけを操作したいというケースが増えてきます。Dockerコマンドの多くは、`–filter`オプションを使用することで、コンテナの名前、ラベル、ステータス、イメージなどに基づいて対象を絞り込むことができます。これにより、より柔軟かつ安全にコンテナを管理することが可能になります。

例えば、特定のプロジェクトに属するコンテナを一括で停止したい場合、そのプロジェクトを示すラベルが付与されているコンテナのみを抽出して操作できます。もし`project=my_project`というラベルを持つコンテナを停止したい場合は、以下のように実行します。

docker stop $(docker ps -q --filter "label=project=my_project")

また、特定の文字列を含む名前のコンテナを対象にすることも可能です。例えば、名前に`dev`を含む全てのコンテナを削除したい場合は、正規表現を用いたフィルタリングを利用できます。これにより、個々のコンテナIDを一つずつ指定する手間を省き、誤操作のリスクを減らしながら、管理対象を明確に定義して操作を行うことができます。フィルタリング機能を活用することで、大規模なDocker環境でも効率的かつ安全なコンテナ管理が実現できます。

停止・終了時のデータ損失とトラブル防止策

データ損失を防ぐボリュームとバインドマウントの活用

Dockerコンテナを削除すると、そのコンテナ内部に書き込まれたデータも一緒に失われます。このデータ損失を防ぐためには、Dockerが提供するデータ永続化のメカニズムであるボリューム（Volumes）とバインドマウント（Bind Mounts）を必ず活用してください。ボリュームはDockerが管理するファイルシステム上にデータを保存し、コンテナライフサイクルとは独立してデータを保持します。一方、バインドマウントはホストOS上の任意のディレクトリをコンテナ内にマウントするため、ホストから直接データにアクセスしやすいという特徴があります。

例えば、データベースのデータやアプリケーションのログ、設定ファイルなどは、コンテナの再作成やアップデート時に失われては困る重要な情報です。これらのデータをボリュームやバインドマウントで永続化することで、コンテナは一時的な存在となり、いつでも安全に破棄・再構築できるようになります。これにより、開発環境のセットアップが容易になり、本番環境での信頼性も向上します。

# ボリュームを使った例
docker run -d --name my_db -v db_data:/var/lib/mysql mysql

# バインドマウントを使った例
docker run -d --name my_app -v /path/to/host/config:/app/config my_app_image

ボリュームやバインドマウントは、コンテナ起動時に`-v`オプションを使用して指定します。この設定を適切に行うことで、コンテナを安心して停止・削除し、必要に応じて新しいコンテナを起動する「イミュータブルインフラストラクチャ」の原則に基づいた運用が可能になります。

コンテナは使い捨て設計！イミュータブルな運用思想

Dockerコンテナを運用する上で最も重要な考え方の一つが、「コンテナは使い捨てである」というイミュータブル（不変的）インフラストラクチャの思想です。これは、一度デプロイされたコンテナは変更せず、設定変更やアップデートが必要な場合は、既存のコンテナを削除し、新しいイメージから新しいコンテナを再作成して置き換えるというアプローチです。この原則に従うことで、環境の一貫性が保たれ、意図しない設定のズレや「この環境だけ動く」といった問題を回避できます。

既存のコンテナを停止・起動して使い回す運用は、コンテナ内部で手動で変更を加えることを誘発し、環境差異を生み出す原因となりがちです。新しいコンテナを常にクリーンな状態から作成することで、CI/CD（継続的インテグレーション/継続的デリバリー）プロセスとの親和性も高まり、再現性の高いデプロイが可能になります。この運用モデルは、トラブル発生時の原因特定を容易にし、迅速なロールバックを可能にするなど、多くのメリットをもたらします。一時的な停止や再起動は問題ありませんが、長期的な運用においては、設定変更時にコンテナを再作成する習慣を身につけることが推奨されます。

セキュリティを考慮したコンテナ管理のベストプラクティス

Dockerコンテナの停止や終了操作だけでなく、日々の管理においてセキュリティを意識することは非常に重要です。コンテナは分離された環境を提供しますが、適切な対策を講じなければ脆弱性が悪用される可能性があります。セキュリティ対策の第一歩として、信頼できるDockerイメージのみを使用することを徹底してください。公式イメージや検証済みのベンダーイメージを選択し、不明なソースからのイメージ利用は避けるべきです。

また、NIST SP800-190（アプリケーションコンテナセキュリティガイド）などの専門的なガイドラインを参照し、コンテナの脆弱性スキャンを定期的に実施することも不可欠です。これにより、既知の脆弱性を早期に発見し、修正パッチを適用したり、よりセキュアなイメージに置き換えたりする対応が可能になります。コンテナを停止・削除する際も、コンテナ内部に機密情報が残っていないか、ボリューム設定が適切であるかを確認し、情報漏洩のリスクを最小限に抑えるよう努めてください。これらの対策は、Dockerコンテナ環境全体のセキュリティレベルを向上させ、安心して運用するための基盤となります。

出典：NIST SP800-190 アプリケーションコンテナセキュリティガイド（IPA版）

【ケース】コンテナが立ち上がらない時の原因究明と解決

【架空のケース】Webサーバーコンテナが起動しない！

開発中のWebアプリケーションのDockerコンテナが、ある日突然起動しなくなったという架空のケースを想定してみましょう。`docker run`コマンドを実行してもすぐに終了してしまったり、`docker ps`で確認しても表示されなかったりします。ホストOSの再起動後や、新しい設定を適用しようとした際にこのような問題に遭遇することは少なくありません。一般的な原因としては、ポート競合、設定ファイルの誤り、必要な依存関係の欠如、イメージの破損などが考えられます。

この状況では、まず何が起こっているのかを正確に把握し、具体的なエラーメッセージや兆候を掴むことが重要です。闇雲にコマンドを試すのではなく、体系的なトラブルシューティングのプロセスを踏むことで、効率的に問題を解決へと導くことができます。コンテナが起動しない原因は多岐にわたるため、順を追って確認していくことが解決への近道となります。具体的なログの確認方法や、診断コマンドの活用が次のステップとなります。

エラーログの確認と対処法

コンテナが正常に起動しない場合の最初のステップは、エラーログを確認することです。`docker logs`コマンドは、停止してしまったコンテナであっても、そのコンテナの標準出力と標準エラー出力を表示してくれます。これにより、なぜコンテナが終了してしまったのか、具体的なエラーメッセージから原因を特定する手がかりを得られます。

docker logs [停止したコンテナIDまたはコンテナ名]

ログを確認する際には、以下のような一般的なエラーメッセージに注意してください。

• `port is already in use`: ホストOS上でコンテナが公開しようとしているポートが、既に他のプロセスによって使用されていることを示します。この場合、コンテナのポートマッピングを変更するか、ポートを占有しているプロセスを停止する必要があります。
• `invalid argument` / `cannot stat`: マウントしようとしているボリュームのパスが間違っているか、存在しない場合に発生します。ホストOS側のパスを正確に確認してください。
• `Error response from daemon`: Dockerデーモン自体に問題があるか、イメージのダウンロードに失敗している可能性があります。`docker pull`でイメージが正常に取得できるか確認したり、Dockerデーモンを再起動したりすることを検討します。

これらのエラーメッセージを基に、適切な対処を行うことで、コンテナが再び起動する可能性が高まります。ログはトラブルシューティングの「羅針盤」となるため、必ず確認する習慣をつけましょう。

起動オプションや設定を見直すトラブルシューティング

エラーログだけでは原因が特定できない場合や、より詳細な情報が必要な場合は、コンテナの起動オプションや設定自体を見直す必要があります。`docker inspect`コマンドは、コンテナの詳細な設定情報をJSON形式で出力します。これにより、ネットワーク設定、ボリュームマウント、環境変数、再起動ポリシーなど、コンテナのあらゆる側面を確認できます。

docker inspect [コンテナIDまたはコンテナ名]

特に確認すべき点としては、以下の項目が挙げられます。

• ポートマッピング (`PortBindings`): 意図したポートが正しく公開されているか。
• ボリューム設定 (`Mounts`): データが正しく永続化されるようにマウントされているか、パスに誤りはないか。
• 環境変数 (`Env`): アプリケーションが必要とする環境変数が正しく設定されているか。
• ネットワーク設定 (`Networks`): 他のコンテナとの通信に必要なネットワークに接続されているか。

また、元となるDockerイメージ自体に問題がないか、あるいはベースとなるOSやライブラリのバージョンが古いなどの問題も考えられます。一度、別の環境で同じイメージを起動してみて、問題が再現するかどうかを確認することも有効です。これらの詳細な設定を確認し、起動コマンド（`docker run`）のオプションやDockerfileの内容と照らし合わせることで、問題の原因を絞り込み、解決に導くことができるでしょう。必要であれば、コンテナを削除し、起動オプションを修正した上で再作成を試みることも有効な手段です。