docker compose up オプション徹底解説｜必須コマンド一覧・便利テクニック・トラブル解決まで網羅

docker-compose-up-options その他
2025.08.04
記事内に広告が含まれています。

Docker Compose を使って開発環境を立ち上げるとき、多くの方が最初に使うのが docker compose up コマンドです。シンプルに実行するだけでもコンテナは起動しますが、実際の開発現場では「バックグラウンドで動かしたい」「特定のサービスだけ立ち上げたい」「キャッシュを無視してビルドし直したい」といったシーンが頻繁にあります。ところが、いざオプションを付けてみようとすると種類が多く、どの場面でどのオプションを選べばいいのか迷ってしまう方も少なくありません。

また、「docker compose up が終わらない」「キャッシュが残って正しく動かない」「複数の docker-compose.yml を切り替えたい」といったトラブルに直面することもあります。これらはオプションの理解が浅いと解決に時間がかかり、開発効率を大きく下げてしまう原因にもなります。

そこでこの記事では、現場でよく使われる基本的なオプションから、知っていると便利な実践テクニック、さらにはトラブルシューティングや環境ごとの使い分けまで体系的に整理しました。Docker Compose を日常的に使うエンジニアが、必要な情報を一つの記事でキャッチアップできる内容になっています。

この記事を読んでわかること

  • docker compose up の必須オプション（d や -build など）の意味と使いどころ
  • f やサービス名指定など、開発現場で役立つ実践的なオプション活用法
  • 環境を整理するための便利なオプション（-remove-orphans、-abort-on-container-exit など）
  • docker compose up が終わらないときの原因と解決方法
  • 開発・本番・CI それぞれの環境での最適なオプション選びと運用ルールの作り方
  • チームで効率的に Docker Compose を使いこなすためのベストプラクティス

「docker compose up オプション」を正しく理解すれば、開発効率は大幅にアップし、チーム内でも一歩リードできる存在になれるはずです。それでは、基本から応用まで順を追って見ていきましょう。

Docker Composeとdocker compose upの概要

Docker Composeは、複数のコンテナで構成されるアプリケーションを定義し、実行するためのツールです。YAMLファイルを使用して、アプリケーションのサービスを全て設定できるため、コマンドを一つ実行するだけで、定義したすべてのコンテナをまとめて起動、停止、再構築、管理できます。これにより、個々のコンテナを手動で管理する手間が省け、開発やテスト、本番環境の構築が大幅に効率化されます。

Docker Compose
Learn how to use Docker Compose to define and run multi-container applications with this detailed introduction to the tool.
docs.docker.com

Docker Composeの主な機能とメリット

Docker Composeが提供する主な機能は、単一のファイル（通常はdocker-compose.yml）に複数のコンテナサービスを記述できる点です。このファイルには、各サービスのDockerイメージ、ポート、ボリューム、ネットワーク、環境変数、そして他のサービスへの依存関係などを定義します。

このツールの最大のメリットは、以下のとおりです。

環境構築の簡素化

複雑なアプリケーション（例：Webサーバー、データベース、キャッシュサーバーなど）も、一つの設定ファイルで定義し、一つのコマンドで簡単に起動できます。これにより、チームメンバー間や異なる環境間での設定のばらつきを防ぎ、誰でも同じ開発環境を素早く構築できるようになります。

開発効率の向上

docker compose upコマンドを使えば、サービスの再構築や再起動を簡単に行えます。特に開発時には、--buildオプションと組み合わせることで、ソースコードの変更をコンテナに素早く反映させられます。

コンテナ間の連携

docker-compose.ymlファイル内でサービス間の依存関係（depends_on）やネットワークを簡単に定義できるため、サービス同士がスムーズに連携して動作するようになります。

DockerとDocker Composeの関係

DockerとDocker Composeは、密接に関連していますが役割が異なります。

Docker

個々のコンテナを作成、管理するツールです。Dockerfileを使って単一のコンテナイメージをビルドし、docker runコマンドでそれを実行します。

Docker Compose

複数のDockerコンテナをまとめて管理するためのオーケストレーションツールです。複数のコンテナを扱うアプリケーションでは、Docker単体で管理するよりもDocker Composeを使う方がはるかに効率的です。

単一のコンテナで動作するアプリケーションであればDockerだけで十分ですが、Webアプリケーションのバックエンド、データベース、フロントエンドをそれぞれ別のコンテナとして管理するような複雑な構成では、Docker Composeが不可欠なツールとなります。

docker compose up コマンドの概要

docker compose up は、Docker Compose の主要なコマンドの一つで、docker-compose.yml ファイルに定義されたすべてのサービスを起動するために使われます。このコマンドを実行すると、Docker Compose は以下の作業を自動的に行ってくれます。

サービスの定義を読み込む

まず、カレントディレクトリにある docker-compose.yml ファイルを読み込み、アプリケーションを構成するサービスやネットワーク、ボリュームなどの定義を確認します。

イメージの構築（必要な場合）

もし docker-compose.yml に build 命令が含まれていて、まだ Docker イメージが構築されていない場合、自動的にイメージを構築します。このとき、Dockerfile の内容に基づいてコンテナの実行環境が準備されます。

コンテナの作成と起動

定義されたサービスごとにコンテナを作成し、起動します。コンテナは指定されたポートや環境変数、ボリュームなどの設定に従って実行されます。

このコマンドの大きなメリットは、複数のコンテナをたった一つのコマンドでまとめて起動できる点です。これにより、個々のコンテナを手動で管理する手間が省け、開発環境やテスト環境の構築が非常に効率的になります。

docker compose upの基本オプション一覧と使い方

docker compose upコマンドは、単体で実行することも可能ですが、様々なオプションを組み合わせることで、開発効率を大幅に向上させることができます。このセクションでは、docker compose up オプションの中でも特に重要なものから、実践的な活用方法まで詳しく解説します。

まずはこれだけ！よく使う必須オプション5選

1. docker compose up -d：バックグラウンド実行（デタッチモード）

なぜバックグラウンドで起動したいのか？

d（-detach）オプションは、コンテナをバックグラウンドで実行するためのオプションです。このオプションを使用しない場合、ターミナルがコンテナのログ出力で占有されてしまい、他の作業ができなくなってしまいます。特に複数のサービスを起動する場合、各サービスのログが混在して読みにくくなるため、デタッチモードでの起動は開発現場では必須と言えます。

コード例：

# バックグラウンドでサービスを起動
docker compose up -d

# 起動後にログを確認したい場合
docker compose logs

# 特定のサービスのログのみを確認
docker compose logs web

# リアルタイムでログを追跡
docker compose logs -f

docker-compose.yml例：

version: '3.8'
services:
  web:
    build: .
    ports:
      - "3000:3000"
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: password

2. docker compose up --build：イメージの再ビルド

-buildが必要なのはどんな時か？

-buildオプションは、docker compose up実行前にDockerイメージを再ビルドするオプションです。以下のような場合に特に重要です：

  • Dockerfileやビルドコンテキストに変更を加えた場合
  • ソースコードを更新してコンテナに反映させたい場合
  • 依存関係（package.json、requirements.txtなど）を更新した場合

なお、docker compose buildコマンドとの違いは、--buildオプションはビルド後に自動的にコンテナを起動する点です。docker compose buildは単純にイメージをビルドするのみで、起動は別途docker compose upが必要です。

コード例：

# イメージを再ビルドしてからサービスを起動
docker compose up --build

# バックグラウンドで再ビルド＆起動
docker compose up -d --build

# 特定のサービスのみ再ビルド＆起動
docker compose up --build web

3. docker compose up --force-recreate：コンテナの強制再作成

なぜ再作成が必要なのか？

-force-recreateオプションは、既存のコンテナを削除してから新しいコンテナを作成するオプションです。以下のような場合に効果的です：

  • docker-compose.ymlの設定（環境変数、ボリューム設定など）を変更した場合
  • コンテナの内部状態をクリアにリセットしたい場合
  • 原因不明の問題が発生した際のトラブルシューティング

コード例：

# 全コンテナを強制的に再作成
docker compose up --force-recreate

# バックグラウンドで強制再作成
docker compose up -d --force-recreate

# 特定のサービスのみ強制再作成
docker compose up --force-recreate web

4. docker compose up --no-deps：依存関係を無視して起動

特定のサービスだけを起動したい場合に便利

-no-depsオプションは、docker-compose.ymlで定義されたdepends_onを無視して、指定されたサービスのみを起動するオプションです。開発中に特定のサービスだけをテストしたい場合や、依存関係のあるサービスがすでに起動している場合に便利です。

コード例：

# webサービスのみを起動（dbサービスは起動しない）
docker compose up --no-deps web

# バックグラウンドで依存関係を無視して起動
docker compose up -d --no-deps api

docker-compose.yml例：

version: '3.8'
services:
  web:
    build: .
    depends_on:
      - db  # 通常はdbサービスも起動されるが、--no-depsで無視される
    ports:
      - "3000:3000"
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: password

5. docker compose up [サービス名]：特定のサービスを起動

複数のサービスがある場合に特定のサービスだけを起動

サービス名を指定することで、docker-compose.ymlに定義された複数のサービスの中から、必要なサービスのみを選択的に起動できます。開発中に全てのサービスが不要な場合や、リソースを節約したい場合に有効です。

コード例：

# データベースサービスのみを起動
docker compose up mysql

# 複数のサービスを指定して起動
docker compose up web redis

# バックグラウンドで特定のサービスを起動
docker compose up -d api db

# 依存関係も含めて特定のサービスを起動（デフォルト動作）
docker compose up web  # depends_onで指定されたサービスも自動起動

docker-compose.yml例：

version: '3.8'
services:
  web:
    build: .
    depends_on:
      - db
      - redis
    ports:
      - "3000:3000"
  api:
    build: ./api
    ports:
      - "8000:8000"
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: password
  redis:
    image: redis:7-alpine

目的別！開発現場で役立つ実践オプション

-no-recreate：既存コンテナを再作成しない

既存のコンテナが存在する場合、それを再利用してサービスを起動します。開発中にデータベースの内容を保持したまま他のサービスだけを再起動したい場合に便利です。

開発シーン例： データベースに蓄積したテストデータを失いたくない場合

docker compose up --no-recreate

-quiet-pull：イメージ取得時のログを抑制

Dockerイメージをpullする際の進捗ログを非表示にします。CI/CDパイプラインでログを見やすくしたい場合や、ネットワーク帯域が狭い環境での実行時に有効です。

開発シーン例： CI/CDでの自動デプロイ時にログをスッキリさせたい場合

docker compose up -d --quiet-pull

-remove-orphans：docker-compose.ymlに定義されていない不要なコンテナを削除

現在のdocker-compose.ymlに定義されていない古いコンテナを自動的に削除します。プロジェクトの進行に伴ってサービス構成が変わった際に、環境をクリーンに保つことができます。

開発シーン例： サービス構成を変更して不要になったコンテナが残っている場合

docker compose up -d --remove-orphans

-abort-on-container-exit：いずれかのコンテナが停止したら、全てを停止

いずれか一つのコンテナが停止した時点で、全てのサービスを停止します。相互に依存関係の強いサービス群を管理する際や、一つのサービスの異常終了を早期に検知したい場合に有効です。

開発シーン例： マイクロサービス間の依存関係が強く、一つでも停止したら全体を停止させたい場合

docker compose up --abort-on-container-exit

-renew-anon-volumes：匿名ボリュームを新規作成

既存の匿名ボリュームを削除して新しいボリュームを作成します。データベースの初期化やキャッシュのクリアが必要な場合に使用します。

開発シーン例： データベースの初期データをリセットしてテストを行いたい場合

docker compose up --renew-anon-volumes

デバッグとトラブルシューティングに役立つコマンドオプション

開発中に問題が発生した際、以下のオプションを組み合わせることで効率的にトラブルシューティングを行うことができます：

基本的なトラブルシューティングフロー

  1. -force-recreate でコンテナを完全に再作成
  2. -build でイメージの再ビルドを強制
  3. -remove-orphans で不要なコンテナを削除
  4. d でバックグラウンド実行し、logs コマンドでログ確認
# 完全クリーンな状態で再起動（トラブルシューティングの基本）
docker compose up -d --build --force-recreate --remove-orphans

# 起動後、ログでエラーを確認
docker compose logs

# 特定のサービスに問題がある場合
docker compose logs web
docker compose logs -f db  # リアルタイム監視

よく使用される組み合わせパターン

# 開発中の標準的な再起動
docker compose up -d --build

# トラブル時の完全リセット
docker compose down && docker compose up -d --build --force-recreate --remove-orphans

# 特定のサービスのみ検証
docker compose up --no-deps --build api

これらのdocker compose up オプションをマスターすることで、開発効率が大幅に向上し、トラブル発生時の対応もスムーズになります。次のセクションでは、これらのオプションをより実践的に活用するテクニックについて詳しく解説していきます。

実践で使えるdocker compose upオプションテクニック

基本的なdocker compose up オプションをマスターしたら、次は実際の開発現場でより効率的に作業するための実践的なテクニックを身につけましょう。このセクションでは、複数の設定ファイルを使い分けたり、特定のサービスのみを起動したりする高度な活用方法について詳しく解説します。

fオプションで複数のdocker-compose.ymlファイルを指定する方法

開発環境と本番環境の設定を分ける実践的なアプローチ

実際の開発現場では、開発環境と本番環境で異なる設定が必要になることがほとんどです。-f（--file）オプションを活用することで、環境ごとに適切な設定を適用できます。

典型的なファイル構成：

project/
├── docker-compose.yml          # 基本設定
├── docker-compose.dev.yml      # 開発環境用設定
├── docker-compose.prod.yml     # 本番環境用設定
└── docker-compose.override.yml # ローカル開発用設定（自動読み込み）

基本的な使い方とコード例

docker-compose.yml（基本設定）：

version: '3.8'
services:
  web:
    build: .
    environment:
      - NODE_ENV=production
  db:
    image: postgres:13
    environment:
      - POSTGRES_DB=myapp

docker-compose.dev.yml（開発環境用）：

version: '3.8'
services:
  web:
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - DEBUG=true
    volumes:
      - .:/app  # ホットリロード用
  db:
    ports:
      - "5432:5432"  # デバッグ用にポート公開
    environment:
      - POSTGRES_PASSWORD=dev_password

docker-compose.prod.yml（本番環境用）：

version: '3.8'
services:
  web:
    environment:
      - NODE_ENV=production
    deploy:
      replicas: 3
  db:
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}  # 環境変数から取得
    volumes:
      - db_data:/var/lib/postgresql/data
volumes:
  db_data:

実践的なコマンド例

# 開発環境で起動
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d

# 本番環境で起動
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

# 複数ファイル指定でビルドも実行
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

# 特定のサービスのみを複数設定ファイルで起動
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d web

docker-compose.override.ymlの自動読み込み機能

Docker Composeは、docker-compose.ymlと同じディレクトリにdocker-compose.override.ymlがある場合、自動的に両方のファイルを読み込みます。個人の開発環境設定に最適です。

docker-compose.override.yml例：

version: '3.8'
services:
  web:
    ports:
      - "3001:3000"  # ポート番号を個人設定に変更
    environment:
      - DEBUG_LEVEL=verbose


# override.ymlがあれば自動的に適用される
docker compose up -d

# override.ymlを無視したい場合
docker compose -f docker-compose.yml up -d

特定サービスだけを起動する：サービス名指定のベストプラクティス

depends_onとの関係を理解する

docker compose upでサービス名を指定する際、depends_onで定義された依存関係が重要な役割を果たします。

docker-compose.yml例：

version: '3.8'
services:
  web:
    build: .
    depends_on:
      - db
      - redis
    ports:
      - "3000:3000"

  api:
    build: ./api
    depends_on:
      - db
    ports:
      - "8000:8000"

  worker:
    build: ./worker
    depends_on:
      - db
      - redis

  db:
    image: postgres:13
    environment:
      - POSTGRES_PASSWORD=password

  redis:
    image: redis:7-alpine

実践的なサービス起動パターン

# webサービスを起動（depends_onによりdbとredisも自動起動）
docker compose up -d web

# apiサービスのみを起動（dbも自動起動）
docker compose up -d api

# 複数のサービスを明示的に指定
docker compose up -d api worker

# 依存関係を無視してwebサービスのみ起動
docker compose up -d --no-deps web

# データベースとキャッシュだけを起動（バックエンドサービスは起動しない）
docker compose up -d db redis

開発フェーズ別の活用例

フロントエンド開発時：

# フロントエンド開発に必要な最小構成
docker compose up -d db redis
# 外部APIサーバーを使用する場合
docker compose up -d --no-deps web

API開発時：

# API開発に集中したい場合
docker compose up -d db redis api

データベース設計・検証時：

# データベースのみ起動してSQLクライアントで接続
docker compose up -d db

-remove-orphans・-abort-on-container-exitなど便利な制御オプションまとめ

-remove-orphansの詳細活用法

なぜ--remove-orphansが便利なのか？

プロジェクトの進行に伴い、docker-compose.ymlからサービスを削除したり、サービス名を変更したりすることがあります。この際、古いコンテナが残り続けてしまい、以下のような問題が発生します：

  • 不要なリソースの消費
  • ポート競合の発生
  • ログの混在による障害調査の困難化

実践的な使用例：

# サービス構成を変更した後のクリーンアップ
docker compose up -d --remove-orphans

# 完全なクリーンアップを行いたい場合
docker compose down --remove-orphans
docker compose up -d --build --remove-orphans

具体的なシナリオ例：

元のdocker-compose.yml:

services:
  web:
    build: .
  old-service:  # 後で削除予定のサービス
    image: nginx
  db:
    image: postgres:13

更新後のdocker-compose.yml:

services:
  web:
    build: .
  new-service:  # old-serviceを置き換え
    image: nginx
  db:
    image: postgres:13


# old-serviceコンテナが自動的に削除される
docker compose up -d --remove-orphans

-abort-on-container-exitの実践的活用

どんな場面で役立つか？

  • 一回限りのタスク実行：データ移行、テスト実行など
  • 相互依存の強いサービス群：一つでも停止したら全体を停止したい場合
  • CI/CDパイプライン：テスト完了後に全てのサービスを停止したい場合

コード例：

# テスト実行用のdocker-compose.test.yml
version: '3.8'
services:
  test-runner:
    build: .
    command: npm test
    depends_on:
      - db
      - redis

  db:
    image: postgres:13
    environment:
      - POSTGRES_PASSWORD=test_password

  redis:
    image: redis:7-alpine


# テスト完了後、自動的に全サービスが停止
docker compose -f docker-compose.test.yml up --abort-on-container-exit

# ログを確認しながら実行（非デタッチモード）
docker compose -f docker-compose.test.yml up --abort-on-container-exit

複数オプションの効果的な組み合わせ

# 開発環境の完全リセット
docker compose down --remove-orphans
docker compose up -d --build --force-recreate --remove-orphans

# CI/CD用の実行コマンド
docker compose -f docker-compose.yml -f docker-compose.ci.yml up \\
  --build --abort-on-container-exit --remove-orphans

# 特定サービスのトラブルシューティング
docker compose up --no-deps --force-recreate --build web

# 本番環境デプロイ時の慎重な起動
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d \\
  --quiet-pull --remove-orphans

エイリアス設定による効率化

よく使用するオプションの組み合わせは、シェルのエイリアスに登録することで作業効率を向上させることができます：

.bashrc または .zshrc に追加：

# 開発用
alias dcu='docker compose up -d'
alias dcub='docker compose up -d --build'
alias dcur='docker compose up -d --build --force-recreate --remove-orphans'

# 本番用
alias dcup='docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --quiet-pull --remove-orphans'

# デバッグ用
alias dcl='docker compose logs -f'
alias dcs='docker compose ps'

これらのdocker compose up オプションテクニックを活用することで、様々な開発シナリオに柔軟に対応でき、チーム開発での効率性も大幅に向上します。次のセクションでは、トラブルシューティングと環境別の最適化について詳しく解説していきます。

誰でも簡単に使える！WordPressテーマ『XWRITE(エックスライト)』

トラブルシューティングと環境別の最適化ノウハウ

docker compose upコマンドを実行する際に発生する様々な問題の解決方法と、開発環境・本番環境・CI/CDそれぞれに最適化されたオプションの使い分けについて詳しく解説します。実際の開発現場で遭遇しやすいトラブルと、その効率的な対処法をマスターしましょう。

upが終わらない／ハング時の原因と解決法

よくある原因と対処法の体系的アプローチ

docker compose upが終わらない、または途中でハングしてしまう問題は開発現場でよく発生します。以下の順序で原因を特定し、解決していきましょう。

1. ログの確認による問題特定

基本的な確認コマンド：

# 現在のコンテナ状態を確認
docker compose ps

# 全サービスのログを確認
docker compose logs

# 特定のサービスのログを確認
docker compose logs web

# リアルタイムでログを監視
docker compose logs -f --tail=50

# タイムスタンプ付きでログを確認
docker compose logs -t

ログ確認の実践例：

# エラーが発生しているサービスを特定
docker compose ps
# 出力例：
# NAME                COMMAND             SERVICE             STATUS              PORTS
# myapp-web-1        "npm start"         web                 Exited (1)
# myapp-db-1         "docker-entrypoint…" db                  Up 2 minutes        5432/tcp

# 異常終了したサービスのログを詳細確認
docker compose logs web
# エラー内容を基に対処方針を決定

2. ポート競合の確認と解決

ポート使用状況の確認：

# 使用中のポートを確認（Linux/Mac）
lsof -i :3000
netstat -tulpn | grep :3000

# Windows の場合
netstat -ano | findstr :3000

競合解決のコード例：

元のdocker-compose.yml（問題のある設定）:

services:
  web:
    build: .
    ports:
      - "3000:3000"  # 既に使用中のポート

修正後（ポート番号を変更）:

services:
  web:
    build: .
    ports:
      - "3001:3000"  # 空いているポートに変更

または環境変数を活用:

services:
  web:
    build: .
    ports:
      - "${WEB_PORT:-3000}:3000"


# 環境変数でポートを指定して起動
WEB_PORT=3001 docker compose up -d

3. 依存関係の問題と解決

depends_onの正しい設定例：

version: '3.8'
services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy  # ヘルスチェック完了を待機
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/myapp

  db:
    image: postgres:13
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=myapp
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d myapp"]
      interval: 10s
      timeout: 5s
      retries: 5

依存関係のトラブルシューティングコマンド：

# 依存関係を無視して個別に起動し、問題を特定
docker compose up -d --no-deps db
docker compose logs db

# データベース接続確認
docker compose exec db pg_isready -U user -d myapp

# 依存関係を含めて段階的に起動
docker compose up -d db
sleep 10
docker compose up -d web

4. メモリ・リソース不足の対処

リソース使用状況の確認：

# Docker リソース使用状況
docker stats

# システムリソース確認
free -h  # メモリ使用量
df -h    # ディスク使用量

docker-compose.ymlでリソース制限を設定：

services:
  web:
    build: .
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5'
        reservations:
          memory: 256M
          cpus: '0.25'

  db:
    image: postgres:13
    deploy:
      resources:
        limits:
          memory: 1G
          cpus: '1.0'

-remove-orphans・-abort-on-container-exit等トラブル対応用オプション

-remove-orphansによるクリーンアップ戦略

孤立コンテナが引き起こす問題：

# 現在のプロジェクトに関連する全コンテナを確認
docker compose ps -a

# 孤立コンテナも含めた全コンテナを確認
docker ps -a --filter "label=com.docker.compose.project=myapp"

段階的クリーンアップの実践例：

# ステップ1: 現在のサービスを停止
docker compose down

# ステップ2: 孤立コンテナも含めて完全削除
docker compose down --remove-orphans --volumes

# ステップ3: クリーンな状態で再起動
docker compose up -d --build --remove-orphans

# ステップ4: 起動確認
docker compose ps
docker compose logs --tail=20

-abort-on-container-exitを活用したテスト・デバッグ

テスト環境での活用例：

docker-compose.test.yml:

version: '3.8'
services:
  test-runner:
    build:
      context: .
      dockerfile: Dockerfile.test
    command: npm run test:integration
    depends_on:
      - db
      - redis
    environment:
      - NODE_ENV=test
      - DATABASE_URL=postgresql://test:test@db:5432/testdb

  db:
    image: postgres:13
    environment:
      - POSTGRES_USER=test
      - POSTGRES_PASSWORD=test
      - POSTGRES_DB=testdb
    tmpfs:
      - /var/lib/postgresql/data  # テスト用の一時的なデータ

  redis:
    image: redis:7-alpine

実践的なテスト実行コマンド：

# テスト実行（完了後に全サービス停止）
docker compose -f docker-compose.test.yml up --build --abort-on-container-exit

# テスト結果の確認
echo $?  # 終了コードを確認（0が成功）

# 失敗時のデバッグ情報取得
docker compose -f docker-compose.test.yml up --build --abort-on-container-exit || {
  echo "テストが失敗しました。ログを確認中..."
  docker compose -f docker-compose.test.yml logs
}

効果的なトラブルシューティングワークフロー

問題発生時の標準的な対処手順：

#!/bin/bash
# トラブルシューティング用スクリプト

echo "=== Docker Compose トラブルシューティング開始 ==="

# 1. 現在の状態確認
echo "1. 現在のコンテナ状態:"
docker compose ps

# 2. ログの確認
echo "2. 最新のログ:"
docker compose logs --tail=50

# 3. システムリソース確認
echo "3. システムリソース:"
docker stats --no-stream

# 4. クリーンな再起動を試行
echo "4. クリーンな再起動を実行中..."
docker compose down --remove-orphans
docker compose up -d --build --force-recreate --remove-orphans

# 5. 起動結果確認
sleep 10
echo "5. 再起動後の状態:"
docker compose ps

# 6. ヘルスチェック
echo "6. サービスヘルスチェック:"
for service in $(docker compose config --services); do
  echo "Checking $service..."
  docker compose exec -T $service echo "OK" 2>/dev/null || echo "$service: 接続できません"
done

echo "=== トラブルシューティング完了 ==="

開発・本番環境／CIでのベストプラクティス・運用ルール構築法

開発環境のベストプラクティス

開発環境用の推奨設定：

docker-compose.dev.yml:

version: '3.8'
services:
  web:
    build:
      context: .
      target: development  # マルチステージビルドの開発ターゲット
    volumes:
      - .:/app
      - /app/node_modules  # node_modulesを除外
    environment:
      - NODE_ENV=development
      - DEBUG=*
      - CHOKIDAR_USEPOLLING=true  # ファイル監視の設定
    command: npm run dev

  db:
    ports:
      - "5432:5432"  # 外部ツールでの接続用
    environment:
      - POSTGRES_PASSWORD=dev_password
    volumes:
      - postgres_data_dev:/var/lib/postgresql/data

volumes:
  postgres_data_dev:

開発環境での推奨コマンド：

# 日常的な開発作業用
alias dev-up='docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build'
alias dev-logs='docker compose -f docker-compose.yml -f docker-compose.dev.yml logs -f'
alias dev-down='docker compose -f docker-compose.yml -f docker-compose.dev.yml down'

# 開発環境のリセット（データを保持）
docker compose -f docker-compose.yml -f docker-compose.dev.yml down
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build --force-recreate

# 完全リセット（データも削除）
docker compose -f docker-compose.yml -f docker-compose.dev.yml down --volumes
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

本番環境のベストプラクティス

本番環境用の推奨設定：

docker-compose.prod.yml:

version: '3.8'
services:
  web:
    build:
      context: .
      target: production
    environment:
      - NODE_ENV=production
    deploy:
      replicas: 3
      resources:
        limits:
          memory: 512M
          cpus: '0.5'
      restart_policy:
        condition: on-failure
        max_attempts: 3
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

  db:
    environment:
      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - postgres_data_prod:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '1.0'

secrets:
  db_password:
    external: true

volumes:
  postgres_data_prod:
    external: true

本番環境での推奨デプロイフロー：

#!/bin/bash
# 本番環境デプロイスクリプト

set -e  # エラー時に停止

echo "=== 本番環境デプロイ開始 ==="

# 1. イメージの事前ビルド
docker compose -f docker-compose.yml -f docker-compose.prod.yml build

# 2. ヘルスチェック付きデプロイ
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d \\
  --remove-orphans --quiet-pull

# 3. デプロイ確認
sleep 30
if docker compose -f docker-compose.yml -f docker-compose.prod.yml ps | grep -q "unhealthy\\|exited"; then
  echo "デプロイに失敗しました。ロールバックします..."
  docker compose -f docker-compose.yml -f docker-compose.prod.yml logs
  exit 1
fi

echo "=== デプロイ完了 ==="

CI/CD環境のベストプラクティス

GitHubActions用の設定例：

.github/workflows/ci.yml:

name: CI/CD Pipeline

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2

    - name: Run tests
      run: |
        # テスト用の環境変数設定
        export DATABASE_URL=postgresql://test:test@localhost:5432/testdb

        # テスト実行（失敗時は自動停止）
        docker compose -f docker-compose.test.yml up \\
          --build --abort-on-container-exit --remove-orphans

        # 終了コードを保存
        TEST_EXIT_CODE=$?

        # ログの出力（デバッグ用）
        docker compose -f docker-compose.test.yml logs

        # クリーンアップ
        docker compose -f docker-compose.test.yml down --remove-orphans --volumes

        # テスト結果で判定
        exit $TEST_EXIT_CODE

CI/CD用のコマンド最適化：

# CI環境での高速化設定
export COMPOSE_DOCKER_CLI_BUILD=1
export DOCKER_BUILDKIT=1

# テスト実行（並列化とキャッシュ活用）
docker compose -f docker-compose.test.yml up \\
  --build --parallel --abort-on-container-exit \\
  --remove-orphans --quiet-pull

# 本番デプロイ（ダウンタイム最小化）
docker compose -f docker-compose.yml -f docker-compose.prod.yml pull
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d \\
  --no-deps --remove-orphans web  # webサービスのみ更新

チームでの運用ルール構築

Makefileを活用した標準化：

# Makefile
.PHONY: dev-up dev-down dev-logs test deploy

# 開発環境
dev-up:
	docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

dev-down:
	docker compose -f docker-compose.yml -f docker-compose.dev.yml down

dev-logs:
	docker compose -f docker-compose.yml -f docker-compose.dev.yml logs -f

dev-reset:
	docker compose -f docker-compose.yml -f docker-compose.dev.yml down --volumes
	docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

# テスト
test:
	docker compose -f docker-compose.test.yml up --build --abort-on-container-exit --remove-orphans
	docker compose -f docker-compose.test.yml down --remove-orphans --volumes

# 本番デプロイ
deploy:
	./scripts/deploy-prod.sh

使用方法：

# 開発環境起動
make dev-up

# テスト実行
make test

# 本番デプロイ
make deploy

これらのトラブルシューティング手法と環境別最適化を実践することで、docker compose up オプションを使った効率的で安定した開発・運用環境を構築できます。次のセクションでは、よくある質問について詳しく解説していきます。

よくある質問（FAQ)

docker compose upとdocker compose buildの違いは？

docker compose buildはイメージのビルドのみを行います。コンテナは作成も起動もされません。一方、docker compose upはイメージのビルド（--buildオプションがある場合）、コンテナの作成、そして起動までの一連の流れを自動的に行ってくれます。

up時にDockerfileの変更が反映されないのはなぜ？

docker compose upは、Dockerfileの変更を自動的に検知しません。変更を反映させるには、--buildオプションを付けてコマンドを実行する必要があります。docker compose upは、Dockerfileの変更を自動的に検知しません。変更を反映させるには、--buildオプションを付けてコマンドを実行する必要があります。

--force-recreateと--renew-anon-volumesの違いは？

--force-recreateはコンテナ自体を再作成します。これに対し、--renew-anon-volumesは匿名ボリュームを再作成し、既存のボリュームは無視して、新しいボリュームを紐づけます。

まとめ

この記事では、docker compose up オプションの基本から実践的な活用法まで幅広くご紹介しました。Docker Composeの基本知識はあっても、オプションを十分に活用できていなかった方も多いのではないでしょうか。

まず押さえておきたいのは、必須オプション5選です。-dでバックグラウンド実行、--buildでイメージ再ビルド、--force-recreateでコンテナ強制再作成、--no-depsで依存関係無視、そしてサービス名指定での部分起動。これらを使いこなすだけで、日々の開発作業が格段にスムーズになります。

さらに実践的なテクニックとして、-fオプションによる複数ファイル管理は特に重要です。開発環境と本番環境で設定を分けることで、環境固有の問題を大幅に減らせます。docker-compose.override.ymlの自動読み込み機能も併せて活用すれば、個人の開発環境も柔軟にカスタマイズできるでしょう。

トラブルシューティングについても体系的にアプローチすることが大切です。docker compose upがハングした時は、まずログ確認から始めて、ポート競合、依存関係、リソース不足の順で原因を特定していきます。--remove-orphansで不要なコンテナを削除し、--abort-on-container-exitでテスト環境を効率化するなど、状況に応じた使い分けがポイントです。

環境別の最適化では、開発環境ではホットリロードとデバッグを重視し、本番環境ではセキュリティとパフォーマンスを最優先にします。CI/CD環境では並列化とキャッシュ活用で処理時間を短縮することが重要です。

重要ポイント

  • 必須オプション5選：d、-build、-force-recreate、-no-deps、サービス名指定を最優先でマスターする
  • 複数ファイル管理：fオプションで開発・本番環境を効率的に管理し、docker-compose.override.ymlで個人設定をカスタマイズ
  • トラブルシューティング手順：ログ確認→ポート競合→依存関係→リソース不足の順で系統的に問題を特定
  • クリーンアップ戦略：-remove-orphansで孤立コンテナを削除し、環境をクリーンに保つ
  • 環境別最適化：開発環境は利便性、本番環境は安定性、CI/CDは効率性を重視したオプション選択
  • チーム運用：Makefileやシェルエイリアスでコマンドを標準化し、チーム全体の作業効率を向上

これらのdocker compose up オプションを適切に使い分けることで、開発効率は確実に向上し、トラブル発生時の対応もスピーディーになります。コンテナ環境での開発が当たり前となった今、これらのテクニックは必須スキルと言えるでしょう。

今日から早速、普段のコマンドにオプションを追加して、Docker Composeを使いこなしていきましょう。最初は基本的な-dや--buildから始めて、徐々に複数ファイル管理やトラブルシューティング手法も取り入れてみてください。きっと、これまで以上に快適な開発環境を構築できるはずです。

あわせて読みたい

【初心者必見】3分でできるViteの始め方！爆速開発環境を最短ステップで完全構築【2025年最新版】
【Vite入門決定版】初心者でも分かる正しい読み方から始め方まで徹底解説！React・Vue対応のインストール手順、高速開発の秘密、Webpackとの違いを説明。コマンド一つで環境構築からデプロイまで、つまずきポイントやvite.config.jsのカスタマイズ例や各種ホスティングサービスへの公開方法も詳しく紹介。
watashi.xyz
2025.04.24
タイトルとURLをコピーしました