Docker Composeのprofilesで開発・本番・デバッグ用サービスを切り替える方法|--profileオプションとCOMPOSE_PROFILESの実践設計

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Docker > Docker Composeのprofilesで開発・本番・デバッグ用サービスを切り替える方法|--profileオプションとCOMPOSE_PROFILESの実践設計
「docker-compose.yml に開発環境だけで使うサービスを書きたい。でも同じファイルを本番でも使いたいから、丸ごと削除するわけにもいかない。毎回コメントアウトするのは運用ミスの元だ。」
こんな悩みを持つエンジニアは多いです。

Docker Compose v1.28 以降には profiles(プロファイル)という機能があります。サービスに名前を付けておくと、その名前を指定した時だけ起動します。これで「開発ツールは本番では起動しない」を compose.yml 1 つで実現できます。

この記事では、profiles の書き方から --profile オプション・COMPOSE_PROFILES 環境変数の使い分け、実務でよく使うパターンまでを実機の出力例付きで解説します。
動作確認環境:Docker 26.1.4(Docker Compose v2.27)、Ubuntu 24.04 LTS / Rocky Linux 9.4

この記事のポイント

・profilesキーを持つサービスは--profileで指定した時だけ起動する
・profilesなしのサービスは常に起動するコアサービスとして機能する
・COMPOSE_PROFILES環境変数で.envに書けばコマンドを変えずに切り替えられる
・depends_onの参照先がprofiles付きの場合は参照元にも同じprofileを付ける


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Docker Compose profilesはなぜ必要か

サービスの数が増えてくると、開発環境でしか使わないサービスが増えてきます。

・開発中のメール送信をモックする MailHog
・DB の中身を手軽に確認する Adminer や pgAdmin
・ローカルでのみ使う Prometheus / Grafana の監視スタック

これらを compose.yml に書くと、docker compose up で本番環境でも起動してしまいます。かといって本番用・開発用でファイルを分割すると、サービス定義の二重管理になります。

Docker Compose の profiles 機能はこの問題を解決します。サービスに名前(プロファイル名)を付けておき、そのプロファイルを指定した時だけ起動させます。compose.yml は 1 つのまま、環境によって起動するサービスを切り替えられます。

profiles は Docker Compose v1.28.0(2021 年 1 月リリース)から利用可能です。現在主流の Compose V2(docker compose コマンド)では標準でサポートされています。

profilesの基本的な書き方

サービス定義に profiles: キーを追加します。値は文字列の配列です。

# compose.yml services: app: image: myapp:latest ports: - "8080:8080" depends_on: - db # profilesなし → 常に起動するコアサービス db: image: postgres:16 environment: POSTGRES_PASSWORD: secret volumes: - db_data:/var/lib/postgresql/data # profilesなし → 常に起動するコアサービス mailhog: image: mailhog/mailhog:v1.0.1 profiles: - dev # devプロファイル時のみ起動 ports: - "8025:8025" pgadmin: image: dpage/pgadmin4:8 profiles: - dev # devプロファイル時のみ起動 - debug # debugプロファイル時にも起動 environment: PGADMIN_DEFAULT_EMAIL: admin@example.com PGADMIN_DEFAULT_PASSWORD: admin ports: - "5050:80" volumes: db_data:

ルールは 2 つだけです。

・profilesなし:どの起動方法でも常に起動するコアサービス(app, db)
・profilesあり:そのプロファイルが指定された時だけ起動するオプションサービス(mailhog, pgadmin)

pgadmin のように複数のプロファイル名を並べると、どちらかが指定されれば起動します。

--profileオプションで選択起動する実践手順

1. プロファイルなしで起動(コアサービスのみ)

docker compose up -d

実行結果:

[+] Running 3/3 ✔ Network myproject_default Created 0.1s ✔ Container myproject-db-1 Started 0.4s ✔ Container myproject-app-1 Started 0.7s

mailhog と pgadmin は起動していません。profiles が付いているためデフォルトでは除外されます。

2. devプロファイルを指定して起動

docker compose --profile dev up -d

実行結果:

[+] Running 5/5 ✔ Network myproject_default Created 0.1s ✔ Container myproject-db-1 Started 0.4s ✔ Container myproject-app-1 Started 0.7s ✔ Container myproject-mailhog-1 Started 0.8s ✔ Container myproject-pgadmin-1 Started 0.9s

dev プロファイルを持つ mailhog と pgadmin が追加起動しています。

3. 複数プロファイルを同時に指定する

docker compose --profile dev --profile monitoring up -d

--profile は複数回指定できます。dev と monitoring 両方のサービスが起動します。

4. 起動中のスタックにプロファイルサービスを追加する

すでにコアサービスが起動している状態から、後でデバッグツールだけ追加起動したい場合:

# すでに起動中のスタックに pgadmin だけ追加 docker compose --profile debug up -d pgadmin

プロファイルを指定しつつサービス名を指定すると、そのサービスだけ追加できます。

COMPOSE_PROFILES環境変数で環境を固定する設計

--profile をコマンドのたびに入力するのは手間です。環境ごとに固定するには COMPOSE_PROFILES 環境変数を使います。

1. シェルの環境変数に設定する

export COMPOSE_PROFILES=dev # 以降は --profile dev を省略できる docker compose up -d

2. .envファイルに書いて自動適用する

compose.yml と同じディレクトリに .env ファイルを置くと、Compose が自動で読み込みます。

# .env(開発環境用) COMPOSE_PROFILES=dev POSTGRES_PASSWORD=localpassword

複数プロファイルはカンマ区切りで並べます。

COMPOSE_PROFILES=dev,monitoring

本番サーバーには .env を置かないか、COMPOSE_PROFILES=(空)にしておくと、コアサービスだけが起動します。

優先順位:シェルの環境変数 > .env ファイル。どちらも設定されている場合はシェルの値が使われます。

実務でよく使う3つのパターン

Docker Compose profiles を使った本番・開発環境の設計について体系的に学びたい方は、Dockerハンズオン講座(docker.linuxmaster.jp)も参考にしてみてください。

パターン1:dev(開発ツール一式)

services: mailhog: image: mailhog/mailhog:v1.0.1 profiles: [dev] ports: - "8025:8025" # Web UI( http://localhost:8025 ) adminer: image: adminer:4.8 profiles: [dev] ports: - "8080:8080" environment: ADMINER_DEFAULT_SERVER: db redis-commander: image: ghcr.io/joeferner/redis-commander:latest profiles: [dev] ports: - "8081:8081" environment: REDIS_HOSTS: "local:redis:6379"

メールモック、DB 管理ツール、Redis 確認ツールを dev プロファイルにまとめる定番構成です。

パターン2:debug(一時的なデバッグ用)

services: jaeger: image: jaegertracing/all-in-one:1.57 profiles: [debug] ports: - "16686:16686" # Jaeger UI - "4317:4317" # OTLP/gRPC

分散トレースの Jaeger などを debug プロファイルに入れておき、問題調査の時だけ起動します。

パターン3:monitoring(監視スタック)

services: prometheus: image: prom/prometheus:v2.52.0 profiles: [monitoring] ports: - "9090:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml grafana: image: grafana/grafana:10.4.2 profiles: [monitoring] ports: - "3000:3000" depends_on: - prometheus

Prometheus + Grafana を monitoring プロファイルにまとめておき、ステージング環境でのみ起動する使い方が実務では多いです。

depends_onとprofilesを組み合わせる時の注意点

profiles を使う際に最もつまずきやすいのが depends_on との組み合わせです。

NG(エラーになる):

services: app: image: myapp:latest # profilesなし depends_on: - redis-debug # profiles付きサービスへの依存 → エラー redis-debug: image: redis:7 profiles: [debug]

この構成では docker compose up(プロファイルなし)時に app が起動しようとして redis-debug が見つからずエラーになります。

OK(同じprofileを揃える):

services: app: image: myapp:latest # profilesなし → コアサービス。profilesなしのサービスにだけ depends_on する app-debug: image: myapp:debug profiles: [debug] depends_on: - redis-debug # 同じ debug プロファイルを持つサービスへの依存はOK redis-debug: image: redis:7 profiles: [debug]

ルール:profilesなしのサービス(app)は、profilesありのサービスに depends_on してはいけません。profilesありのサービスは同じプロファイルを持つサービスに depends_on してよいです。

トラブルシュートと確認方法

1. どのサービスがどのprofileに属しているか確認する

# コアサービス(profilesなし)だけ表示 docker compose config --services

app db

# dev プロファイル有効時のサービス一覧 docker compose --profile dev config --services

app db mailhog pgadmin

2. 「No such service: xxx」が出た時

profiles が付いたサービスを直接指定しようとして、プロファイルを省略した場合に発生します。

# NG: プロファイルなしで profiles 付きサービスを指定 docker compose up mailhog # OK: プロファイルも一緒に指定する docker compose --profile dev up mailhog

3. COMPOSE_PROFILESを設定したのに効かない

.env ファイルのパスが正しいか確認します。compose.yml と同じディレクトリに置く必要があります。
シェルの環境変数で上書きされていないかも確認します。

# Compose が認識しているプロファイル設定を確認 docker compose config | grep -A3 "profiles:" # シェルの環境変数を確認 echo $COMPOSE_PROFILES

本記事のまとめ

Docker Compose profiles を使うと、1 つの compose.yml で環境別のサービス起動を管理できます。
やりたいこと コマンド・設定
サービスにプロファイルを設定する profiles: [dev](compose.yml内)
プロファイルを指定して起動する docker compose --profile dev up -d
複数プロファイルを同時に有効化する docker compose --profile dev --profile debug up -d
環境変数でプロファイルを固定する COMPOSE_PROFILES=dev(.envに記載)
有効なサービス一覧を確認する docker compose --profile dev config --services
本番では開発ツールを起動しない .envを置かないか、COMPOSE_PROFILES=(空)にする
profiles を使えば「本番はコアサービスだけ、開発は --profile dev を追加」という運用が 1 ファイルで完結します。毎回コメントアウトで対応するミスや、ファイルを 2 つに分けた二重管理から解放されます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Docker Composeを使った本番・開発環境設計のハンズオンも開催しています。コンテナ設計でつまずきやすいポイントを20年以上の現場経験をもとに解説します。
>> Dockerハンズオン講座の詳細はこちら

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。