Docker Compose 2026: マルチコンテナアプリケーション、ネットワーキング、DevOps面接質問集
Docker Composeでマルチコンテナアプリケーションを構築する方法を解説。ネットワーク設定、ボリューム管理、本番環境デプロイメントの実践的なパターンとDevOps面接で頻出の質問と回答を収録。

Docker Composeは2026年現在も、マルチコンテナDockerアプリケーションを定義・実行するための標準ツールとして広く使用されている。ローカル開発環境の構築からDevOps面接の準備まで、Composeのネットワーキング、サービス依存関係、本番環境向けパターンを理解することが、ジュニアエンジニアとシニアエンジニアを分ける重要な要素となる。
Docker Composeは宣言的なYAML形式を使用して、サービス、ネットワーク、ボリュームを単一のファイルで定義する。docker compose upコマンドを実行するだけで、分離されたネットワークと永続ストレージを備えたアプリケーションスタック全体が起動する。
Docker Composeのアーキテクチャを理解する
Docker Composeはシンプルな原則で動作する。アプリケーションのサービスをcompose.yamlファイル(従来のdocker-compose.ymlに代わる現代的な命名規則)で定義すると、Composeがコンテナの作成、ネットワーキング、ライフサイクル管理を処理する。
Docker Compose仕様は3つの主要な概念を定義している:
- サービス: イメージ、ビルドコンテキスト、環境変数、リソース制限を含むコンテナ設定
- ネットワーク: サービス間の分離された通信チャネル
- ボリューム: コンテナの再起動後も保持される永続データストレージ
# compose.yaml
services:
api:
build: ./api
ports:
- "3000:3000"
environment:
- DATABASE_URL=postgres://db:5432/app
depends_on:
db:
condition: service_healthy
networks:
- backend
db:
image: postgres:16
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
- POSTGRES_DB=app
- POSTGRES_PASSWORD_FILE=/run/secrets/db_password
secrets:
- db_password
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
networks:
- backend
networks:
backend:
driver: bridge
volumes:
postgres_data:
secrets:
db_password:
file: ./secrets/db_password.txtこの設定は、依存関係の順序付けのためのヘルスチェック、機密データ用のDockerシークレット、永続化のための名前付きボリューム、明示的なネットワーク定義など、本番環境向けの複数のパターンを示している。
Docker Composeネットワーキングの詳細
デフォルトでは、Composeはアプリケーション用の単一ネットワークを作成する。すべてのサービスがこのネットワークに参加し、サービス名をホスト名として使用して相互に通信できる。このネットワーキングモデルの理解は、後のKubernetesへの移行において基礎となる。
# compose.yaml
services:
frontend:
build: ./frontend
ports:
- "80:80"
networks:
- frontend-net
- backend-net
api:
build: ./api
networks:
- backend-net
cache:
image: redis:7-alpine
networks:
- backend-net
db:
image: postgres:16
networks:
- backend-net
networks:
frontend-net:
driver: bridge
backend-net:
driver: bridge
internal: trueinternal: trueフラグは、バックエンドネットワークが外部インターネットにアクセスすることを防ぐ。フロントエンドサービスは両方のネットワークをブリッジし、唯一のエントリポイントとして機能する。このネットワークセグメンテーションは、本番環境のセキュリティプラクティスを反映している。
Dockerの組み込みDNSサーバーは、サービス名を自動的に解決する。apiサービスは、手動でIPを設定することなく、db:5432でデータベースに接続できる。
Composeとマルチステージビルド
本番イメージは最小限であるべきである。マルチステージビルドとComposeプロファイルを組み合わせることで、開発と本番で異なる設定が可能になる。
# api/Dockerfile
# Stage 1: Build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Stage 2: Production
FROM node:22-alpine AS production
WORKDIR /app
COPY /app/dist ./dist
COPY /app/node_modules ./node_modules
COPY package*.json ./
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]
# Stage 3: Development
FROM node:22-alpine AS development
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
USER node
CMD ["npm", "run", "dev"]# compose.yaml
services:
api:
build:
context: ./api
target: ${BUILD_TARGET:-production}
volumes:
- ${API_VOLUMES:-./api/dist:/app/dist:ro}
profiles:
- ${COMPOSE_PROFILES:-prod}BUILD_TARGET=development COMPOSE_PROFILES=dev docker compose upを実行すると、ホットリロード機能付きの開発設定が起動する。
サービス依存関係とヘルスチェック
depends_onディレクティブは起動順序を制御するが、コンテナが起動してもサービスが準備完了とは限らない。ヘルスチェックがこのタイミングの問題を解決する。このパターンはDevOps面接で頻繁に質問される。
# compose.yaml
services:
api:
build: ./api
depends_on:
db:
condition: service_healthy
cache:
condition: service_started
migrations:
condition: service_completed_successfully
migrations:
build: ./api
command: npm run migrate
depends_on:
db:
condition: service_healthy
db:
image: postgres:16
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 3s
retries: 5
start_period: 10s
cache:
image: redis:7-alpine
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 33つの依存関係条件が存在する:
service_started: デフォルト、コンテナが起動した状態service_healthy: ヘルスチェックに合格した状態service_completed_successfully: コンテナが終了コード0で終了した状態(初期化コンテナ用)
DevOpsの面接対策はできていますか?
インタラクティブなシミュレーター、flashcards、技術テストで練習しましょう。
ローカル開発のためのDocker Compose
開発環境は、バインドマウント、環境変数のオーバーライド、デバッグツールの恩恵を受ける。compose.override.yamlファイルはcompose.yamlと自動的にマージされる。
# compose.yaml (基本設定)
services:
api:
build: ./api
environment:
- NODE_ENV=production
db:
image: postgres:16# compose.override.yaml (開発用オーバーライド)
services:
api:
build:
target: development
volumes:
- ./api:/app
- /app/node_modules
environment:
- NODE_ENV=development
- DEBUG=app:*
ports:
- "9229:9229"
db:
ports:
- "5432:5432"匿名ボリューム/app/node_modulesは、ホストのnode_modulesがコンテナにインストールされた依存関係を上書きすることを防ぐ。
本番環境デプロイメントパターン
Docker Composeは単一ホストの本番デプロイメントに適している。マルチホストオーケストレーションには、KubernetesとHelmがより良いスケーリングを提供するが、Composeは小規模なアプリケーションには引き続き有効である。
# compose.prod.yaml
services:
api:
image: registry.example.com/api:${VERSION:-latest}
deploy:
replicas: 3
resources:
limits:
cpus: "0.5"
memory: 512M
reservations:
cpus: "0.25"
memory: 256M
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
nginx:
image: nginx:alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- ./certs:/etc/nginx/certs:ro
depends_on:
- apideployキーは、リソース制限、レプリカ数、再起動ポリシーを設定する。docker compose -f compose.prod.yaml up -dを実行すると、本番スタックがデタッチモードで起動する。
環境変数とシークレット管理
機密性の高い設定には適切な取り扱いが必要である。Docker Composeは.envファイルからDockerシークレットまで、複数のアプローチをサポートしている。
# .env
POSTGRES_PASSWORD=dev_password_only
API_SECRET_KEY=local_dev_key# compose.yaml
services:
api:
environment:
- API_SECRET_KEY # シェルまたは.envから継承
- DATABASE_URL=postgres://user:${POSTGRES_PASSWORD}@db:5432/app
env_file:
- ./config/api.env本番環境では、Dockerシークレットが環境変数ではなくファイルとして機密データをマウントすることで、より良いセキュリティを提供する:
# compose.prod.yaml
services:
api:
secrets:
- api_key
- db_password
environment:
- API_KEY_FILE=/run/secrets/api_key
secrets:
api_key:
external: true
db_password:
file: ./secrets/db_password.txt本番シークレットを含む.envファイルをバージョン管理にコミットしてはならない。本番デプロイメントには、HashiCorp Vaultやクラウドプロバイダーのソリューションなど、外部のシークレット管理を使用すること。
Docker Composeに関するDevOps面接でよくある質問
面接官は、実践的なシナリオを通じてComposeの概念の理解度をテストする。以下の質問は、DevOpsやプラットフォームエンジニアリングの面接で頻繁に出題される。
Q: Composeネットワーク内のコンテナはどのように通信するか?
Dockerは各Composeプロジェクトに専用のブリッジネットワークを作成する。サービスはサービス名をホスト名として使用して通信する。組み込みのDNSサーバーがこれらの名前をコンテナIPアドレスに解決する。外部トラフィックは、明示的に公開されたポートを通じてのみサービスに到達する。
Q: 既存のコンテナがある状態でdocker compose upを実行するとどうなるか?
Composeは現在の設定を実行中のコンテナと比較する。変更されていないサービスは継続して実行される。変更されたサービスは新しい設定で再作成される。新しいサービスは新規に起動する。削除されたサービスは停止して削除される。
Q: Composeでデータベースマイグレーションをどのように処理するか?
2つのパターンが存在する。まず、service_completed_successfully依存関係を持つ初期化コンテナを使用する方法:
services:
migrate:
image: api:latest
command: npm run migrate
depends_on:
db:
condition: service_healthy
api:
depends_on:
migrate:
condition: service_completed_successfully次に、アプリケーション起動スクリプトにマイグレーションロジックを含め、トラフィックを受け入れる前に保留中のマイグレーションをチェック・適用する方法がある。
Q: ボリュームとバインドマウントの違いは何か?
名前付きボリュームはDockerが管理し、/var/lib/docker/volumesに保存され、ホスト間で移植可能である。バインドマウントはホストディレクトリをコンテナに直接マッピングし、開発には便利だが環境に依存する。ボリュームはNFSやクラウドブロックストレージなどのリモートストレージ用のドライバーをサポートしている。
Q: docker-composeとdocker composeの違いは何か?
ハイフン付きのdocker-composeは、現在非推奨となったPythonベースのV1スタンドアロンツールである。スペース区切りのdocker composeは、Docker CLIに統合されたGoベースのV2実装である。V2はより高速で、Compose仕様を完全にサポートし、アクティブに開発が行われている。
Composeアプリケーションのデバッグ
コンテナ化されたアプリケーションのトラブルシューティングには、特定のテクニックが必要である。以下のコマンドは、Composeスタック内で何が起こっているかを明らかにする:
# すべてのサービスのログを表示
docker compose logs -f
# タイムスタンプ付きで特定のサービスのログを表示
docker compose logs -f --timestamps api
# 実行中のコンテナでコマンドを実行
docker compose exec api sh
# 単発のコマンドを実行(新しいコンテナを起動)
docker compose run --rm api npm test
# リソース使用状況を表示
docker compose top
docker stats
# ネットワーク設定を調査
docker network inspect project_backend
# composeファイルを検証
docker compose configdocker compose configコマンドはすべてのcomposeファイルをマージし、最終的な設定を表示する。変数展開の問題をデバッグする際に非常に有用である。
まとめ
- Docker Composeは、サービス、ネットワーク、ボリュームを単一のYAMLファイルでマルチコンテナアプリケーションを定義する
- サービスは、デフォルトのブリッジネットワーク内でサービス名をホスト名として使用し、DNS経由で通信する
service_healthy条件付きヘルスチェックにより、適切な起動順序が保証される- バインドマウントやデバッグポートなどの開発固有の設定には
compose.override.yamlを使用する - 本番デプロイメントでは、リソース制限、再起動ポリシー、機密データ用のDockerシークレットが有益である
docker composeCLI(V2)は、より良いパフォーマンスと機能で非推奨のdocker-compose(V1)を置き換えている
今すぐ練習を始めましょう!
面接シミュレーターと技術テストで知識をテストしましょう。
共有
関連記事

Kubernetes Helm Charts 完全ガイド 2026:パッケージング、デプロイメント、面接対策
Helm 3を使用したKubernetesアプリケーションのパッケージングとデプロイメント手法を解説。チャート構造、テンプレート作成、依存関係管理、そして技術面接で頻出する質問と回答例を網羅的に紹介します。

Prometheus vs Grafana vs Datadog 2026年比較:モニタリングアーキテクチャとDevOps面接対策
Prometheus、Grafana、Datadogの2026年最新比較。アーキテクチャ、価格、アラート戦略の違いと、DevOps面接で頻出するオブザーバビリティ質問を体系的に解説します。

ArgoCD GitOps 完全ガイド 2026年版:Kubernetes 継続的デプロイメントと技術面接対策
ArgoCD 3.4 と GitOps による Kubernetes 継続的デプロイメントを解説。Application CRD、Sync Wave、マルチクラスター管理、Flux 比較、面接質問を網羅。