6.3 docker compose 主要コマンド完全ガイド|up/down/ps/logs/exec/buildの使い方

Docker Compose

docker compose 主要コマンド完全ガイド|up/down/ps/logs/exec/build の使い方

6-2 で compose.yml の書き方を押さえました。今回はそれを動かすコマンド群。日常使うのはせいぜい8個です。

💡 この記事のゴール
up/down の安全なオプション使い分け
② ログ・実行・ビルド・再起動の日常操作
configls などの便利コマンド
④ プロジェクト名の扱いと -p の使い方

目次

  1. 主要コマンド一覧
  2. up / down
  3. ps / logs
  4. exec / run
  5. build / pull
  6. start / stop / restart
  7. config / ls
  8. プロジェクト名と -p
  9. まとめ

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
⚠️ 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が起動するまでアプリを待たせる」真面目なやり方を学びます。これまで曖昧だった起動順の問題に決着をつけます。

参考リンク


Dockerの基礎を動画で体系的に学びませんか?

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

Udemy Docker入門講座 クーポン割引で講座を見る →

コメント

タイトルとURLをコピーしました