docker compose 主要コマンド完全ガイド|up/down/ps/logs/exec/build の使い方
6-2 で compose.yml の書き方を押さえました。今回はそれを動かすコマンド群。日常使うのはせいぜい8個です。
💡 この記事のゴール
①
② ログ・実行・ビルド・再起動の日常操作
③
④ プロジェクト名の扱いと
①
up/down の安全なオプション使い分け② ログ・実行・ビルド・再起動の日常操作
③
config・ls などの便利コマンド④ プロジェクト名の扱いと
-p の使い方
目次
- 主要コマンド一覧
up/downps/logsexec/runbuild/pullstart/stop/restartconfig/ls- プロジェクト名と
-p - まとめ
1. 主要コマンド一覧
| コマンド | 役割 | 頻度 |
|---|---|---|
docker compose up |
サービスを一括起動(ネットワーク・ボリュームも) | ★★★ |
docker compose down |
全サービスを停止+削除 | ★★★ |
docker compose ps |
サービス一覧 | ★★★ |
docker compose logs |
全サービスのログ | ★★★ |
docker compose exec |
起動中コンテナでコマンド実行 | ★★★ |
docker compose run |
新しいコンテナで1回だけコマンド実行 | ★★ |
docker compose build |
Dockerfileをビルド | ★★ |
docker compose pull |
image を全部取得 | ★★ |
docker compose restart |
サービス再起動 | ★★ |
docker compose config |
YAMLの検証 + 合成結果表示 | ★ |
2. up / down
2-1. up の定番オプション
# 前景(ログが画面に流れる、Ctrl+Cで停止)
docker compose up
# バックグラウンド(実務ほぼ常にこれ)
docker compose up -d
# ビルドも強制
docker compose up -d --build
# 特定のサービスだけ起動
docker compose up -d web cache
# 変更のあったコンテナだけ再作成
docker compose up -d --force-recreate
# スケール(同じサービスを N 個起動)
docker compose up -d --scale web=3
2-2. down の危険ゾーン
# 基本:コンテナとネットワークを削除(ボリュームは残る)
docker compose down
# 危険:ボリュームも一緒に削除(DBデータが消える!)
docker compose down -v
# イメージも削除
docker compose down --rmi local
docker compose down --rmi all
⚠️
このオプションはプロジェクトで定義された Named Volume を削除します。DB データごと消えるので、本番環境では絶対に使わないこと。開発でクリーンに作り直したい時だけに限定。
docker compose down -v は要注意このオプションはプロジェクトで定義された Named Volume を削除します。DB データごと消えるので、本番環境では絶対に使わないこと。開発でクリーンに作り直したい時だけに限定。
3. ps / logs
# 起動中サービスの一覧
$ docker compose ps
NAME IMAGE STATUS PORTS
myapp-db-1 postgres:16 Up 1 minute 5432/tcp
myapp-web-1 nginx Up 1 minute 0.0.0.0:8080->80/tcp
# 停止中も含めて表示
docker compose ps -a
# 全サービスのログを時系列表示
docker compose logs
# リアルタイム追跡(重要!)
docker compose logs -f
# 特定サービスだけ
docker compose logs -f web
# 直近100行だけ
docker compose logs --tail=100 web
💡
複数サービスのログが混ざっても、サービス名が色分けされるので「どのコンテナから出ているログか」が一目で分かります。エラー調査の最初の一手。
logs -f はサービス名の色分け表示複数サービスのログが混ざっても、サービス名が色分けされるので「どのコンテナから出ているログか」が一目で分かります。エラー調査の最初の一手。
4. exec / run — 違いを理解する
exec |
run |
|
|---|---|---|
| 対象 | 既に起動中のコンテナに入る | 新しいコンテナを起動してコマンド実行 |
| 使いどころ | DB接続・ログ確認・中身探検 | 単発タスク(マイグレーション・テスト等) |
| 元コンテナは? | 影響なし | 関係なし(新規なので) |
# 稼働中 db コンテナに psql で入る
docker compose exec db psql -U postgres
# 新コンテナを1つ立てて単発コマンド(終了後は自動削除しない)
docker compose run --rm app python manage.py migrate
# 新コンテナで対話シェル
docker compose run --rm app bash
💡
run は --rm が定番run は新コンテナを作るので、そのままだと停止中コンテナが増えます。単発処理には --rm で自動削除させるのが慣例。
5. build / pull
# 全サービスのイメージをビルド
docker compose build
# キャッシュを使わずに完全ビルド
docker compose build --no-cache
# 特定サービスだけビルド
docker compose build app
# 全イメージを最新に更新
docker compose pull
# 特定サービスのイメージだけ更新
docker compose pull db
6. start / stop / restart
# 停止(コンテナは残る)
docker compose stop
# 停止していたものを再開(up と違い、新規作成はしない)
docker compose start
# 再起動
docker compose restart
# 特定サービスのみ
docker compose restart app
| コマンド | コンテナを新規作成? | 停止コンテナ削除? |
|---|---|---|
up |
必要なら作る | しない(既存維持) |
start |
作らない(既存を起動) | しない |
stop |
N/A | しない(停止するだけ) |
down |
N/A | する |
restart |
しない | しない |
7. config / ls
config:YAMLの検証+合成結果
# 構文エラー確認+環境変数展開済みの最終形を表示
docker compose config
# サービス名だけ一覧
docker compose config --services
# 環境変数一覧
docker compose config --environment
💡 CI で最初にやるべき一手
docker compose config -q は YAML の静的検証に使えます(-q で出力なし、exit code でエラー判定)。CIパイプラインの最初に入れておくと、YAMLミスで全工程が無駄になる事故を防げます。
ls:全プロジェクト一覧
$ docker compose ls
NAME STATUS CONFIG FILES
myapp running(3) /home/me/myapp/compose.yml
another running(2) /home/me/another/compose.yml
8. プロジェクト名と -p
Compose はカレントディレクトリ名をプロジェクト名(コンテナ名・ネットワーク名の接頭辞)として自動で使います。これを明示的に変更したいときは -p:
# デフォルト: ディレクトリ名「myapp」
$ docker compose up -d
# → コンテナ名は myapp-web-1 等
# 明示指定
$ docker compose -p production up -d
# → コンテナ名は production-web-1 等
# 環境変数 COMPOSE_PROJECT_NAME でもOK
$ export COMPOSE_PROJECT_NAME=staging
$ docker compose up -d
💡 同じディレクトリで複数環境を並行運用
同じ
同じ
compose.yml を使って開発・ステージング・テストを並行起動したいときに -p が便利。プロジェクト名が違えば Docker 的には別リソース扱いになり、名前衝突しません。
9. まとめ
| 日常の流れ | コマンド |
|---|---|
| 起動 | docker compose up -d |
| 状態確認 | docker compose ps |
| ログ追跡 | docker compose logs -f [サービス] |
| 中に入る | docker compose exec [サービス] bash |
| 単発タスク | docker compose run --rm [サービス] [cmd] |
| 再ビルド | docker compose up -d --build |
| 停止 | docker compose down(ボリュームは残る) |
| 完全掃除 | docker compose down -v(DB消える注意) |
✅ 次のステップ
6-4 depends_on と healthcheckで、「DBが起動するまでアプリを待たせる」真面目なやり方を学びます。これまで曖昧だった起動順の問題に決着をつけます。
6-4 depends_on と healthcheckで、「DBが起動するまでアプリを待たせる」真面目なやり方を学びます。これまで曖昧だった起動順の問題に決着をつけます。
参考リンク
- docker compose CLI reference(公式) — 全サブコマンドの一次情報源。



コメント