Docker Run マスターガイド：必須コマンドオプション解説

docker run はイメージから新しいコンテナを作成し、起動します。一見シンプルに見えますが、オプションによってコンテナのネットワーク接続、データ保存、設定受け渡し、再起動後の動作が決まります。

このガイドは、実行したいイメージはわかっているが、実用的なセットアップに適したフラグが必要な場合に使用してください。

基本構文

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

IMAGE はイメージ名（例：nginx や postgres:16）です。COMMAND と ARG... はオプションで、イメージのデフォルトコマンドを上書きまたは拡張します。

簡単なフォアグラウンドテストの場合：

docker run hello-world

実際のサービスでは、通常オプションを追加します。

バックグラウンド実行（-d）

デフォルトでは、Dockerはターミナルをコンテナの出力にアタッチします。デタッチドモードではコンテナをバックグラウンドで実行します：

docker run -d nginx

Dockerは新しいコンテナIDを表示し、プロンプトを返します。確認するには：

docker ps

デタッチドコンテナのログを読むには：

docker logs <container_id_or_name>

ポートの公開（-p）

コンテナは独自のネットワーク名前空間を持ちます。コンテナ内でサービスが待機している場合、ホストからアクセスできるようにポートを公開します：

docker run -d -p 8080:80 nginx

これにより、ホストポート 8080 がコンテナポート 80 にマッピングされ、http://localhost:8080 でNginxにアクセスできます。

複数のポートを公開することも可能：

docker run -d -p 8080:80 -p 8443:443 nginx

ホストのlocalhostのみにバインドするには、ホストIPを含めます：

docker run -d -p 127.0.0.1:8080:80 nginx

これは、すべてのホストインターフェースに公開したくないローカルツールに便利です。

ボリュームでデータを永続化

コンテナの書き込み可能レイヤーは永続データに適していません。特定のホストパスをコンテナにマウントしたい場合はバインドマウントを使用します：

docker run -d -p 8080:80 -v "$PWD/html:/usr/share/nginx/html:ro" nginx

これにより、ローカルの html ディレクトリからファイルが提供されます。:ro サフィックスにより、マウントがコンテナ内で読み取り専用になります。

Dockerにストレージ場所を管理させる場合は名前付きボリュームを使用します：

docker run -d --name postgres -v pgdata:/var/lib/postgresql/data postgres:16

pgdata が存在しない場合、Dockerが作成します。ボリュームを確認するには：

docker volume ls

新しい作業では、Dockerの --mount 構文の方が冗長ですが明確です：

docker run -d --mount type=volume,src=pgdata,dst=/var/lib/postgresql/data postgres:16

設定の受け渡し（-e と --env-file）

環境変数はコンテナ化されたアプリを設定する一般的な方法です：

docker run -d -e APP_ENV=production my-custom-app:latest

複数の変数には -e を複数回使用：

docker run -d -e DB_HOST=database.example.com -e DB_USER=app my-app:latest

変数が多い場合はenvファイルを使用：

docker run -d --env-file ./app.env my-app:latest

機密情報はコミットされた .env ファイルに保存しないでください。環境変数はホストや十分なアクセス権を持つプロセスから簡単に確認できるため、本番環境の機密値にはプラットフォームのシークレットマネージャーを使用してください。

コンテナに名前を付ける（--name）

Dockerは名前を生成できますが、明確な名前を付けると後続のコマンドが簡単になります：

docker run -d --name web -p 8080:80 nginx

その後、次のように使用できます：

docker logs web
docker stop web
docker exec -it web sh

コンテナ名は一意である必要があります。web が既に存在する場合は、名前を再利用する前に古いコンテナを削除するか名前を変更してください。

インタラクティブモード（-it）

シェルやトラブルシューティングセッションでは、インタラクティブモードと疑似TTYを組み合わせます：

docker run -it ubuntu bash

シェルを終了するとコンテナは停止します。使い捨てセッションには --rm を追加：

docker run --rm -it alpine sh

再起動ポリシーの選択

再起動ポリシーは、コンテナが終了したときにDockerが何をするかを指定します：

docker run -d --name web --restart unless-stopped -p 8080:80 nginx

一般的なポリシー：

• no：自動的に再起動しない。これがデフォルトです。
• on-failure[:max-retries]：ゼロ以外の終了コードの場合のみ再起動。
• always：コンテナが停止するたびに再起動（Dockerデーモンの再起動後も含む）。
• unless-stopped：明示的にコンテナを停止した場合を除き再起動。

長時間実行するローカルサービスでは、unless-stopped が always より適していることが多いです。手動で停止した場合、その状態が尊重されるためです。

使い捨てコンテナの削除（--rm）

停止したコンテナは削除するまでディスクに残ります。1回限りのコマンドでは、--rm でコンテナ終了後に自動削除：

docker run --rm ubuntu echo "一時コンテナからのメッセージ"

停止状態を後で確認する必要があるコンテナには --rm を使用しないでください。

実践例

このコマンドは、安定した名前、公開ポート、バインドマウントされたログディレクトリ、環境変数、再起動ポリシーを持つWebアプリを実行します：

docker run -d \
  --name my-app \
  --restart on-failure \
  -p 3000:80 \
  -v "$PWD/logs:/app/logs" \
  -e NODE_ENV=production \
  my-node-app:1.0

起動後、コンテナを確認してログをチェック：

docker ps
docker logs my-app

まとめ

まず最小限の docker run コマンドで動作させ、必要な動作に応じてオプションを追加します：バックグラウンドサービスには -d、アクセスには -p、データには -v または --mount、設定には -e、操作には --name、耐障害性には --restart、一時的な実行には --rm を使用します。