Docker Compose 2026: マルチコンテナアプリケーション、ネットワーキング、DevOps面接質問集

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

Docker Compose 2026: マルチコンテナアプリケーション、ネットワーキング、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つの主要な概念を定義している:

  • サービス: イメージ、ビルドコンテキスト、環境変数、リソース制限を含むコンテナ設定
  • ネットワーク: サービス間の分離された通信チャネル
  • ボリューム: コンテナの再起動後も保持される永続データストレージ
yaml
# 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への移行において基礎となる。

yaml
# 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: true

internal: trueフラグは、バックエンドネットワークが外部インターネットにアクセスすることを防ぐ。フロントエンドサービスは両方のネットワークをブリッジし、唯一のエントリポイントとして機能する。このネットワークセグメンテーションは、本番環境のセキュリティプラクティスを反映している。

DNS解決

Dockerの組み込みDNSサーバーは、サービス名を自動的に解決する。apiサービスは、手動でIPを設定することなく、db:5432でデータベースに接続できる。

Composeとマルチステージビルド

本番イメージは最小限であるべきである。マルチステージビルドとComposeプロファイルを組み合わせることで、開発と本番で異なる設定が可能になる。

dockerfile
# 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 --from=builder /app/dist ./dist
COPY --from=builder /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"]
yaml
# 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面接で頻繁に質問される。

yaml
# 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: 3

3つの依存関係条件が存在する:

  • service_started: デフォルト、コンテナが起動した状態
  • service_healthy: ヘルスチェックに合格した状態
  • service_completed_successfully: コンテナが終了コード0で終了した状態(初期化コンテナ用)

DevOpsの面接対策はできていますか?

インタラクティブなシミュレーター、flashcards、技術テストで練習しましょう。

ローカル開発のためのDocker Compose

開発環境は、バインドマウント、環境変数のオーバーライド、デバッグツールの恩恵を受ける。compose.override.yamlファイルはcompose.yamlと自動的にマージされる。

yaml
# compose.yaml (基本設定)
services:
  api:
    build: ./api
    environment:
      - NODE_ENV=production

  db:
    image: postgres:16
yaml
# 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は小規模なアプリケーションには引き続き有効である。

yaml
# 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:
      - api

deployキーは、リソース制限、レプリカ数、再起動ポリシーを設定する。docker compose -f compose.prod.yaml up -dを実行すると、本番スタックがデタッチモードで起動する。

環境変数とシークレット管理

機密性の高い設定には適切な取り扱いが必要である。Docker Composeは.envファイルからDockerシークレットまで、複数のアプローチをサポートしている。

bash
# .env
POSTGRES_PASSWORD=dev_password_only
API_SECRET_KEY=local_dev_key
yaml
# compose.yaml
services:
  api:
    environment:
      - API_SECRET_KEY  # シェルまたは.envから継承
      - DATABASE_URL=postgres://user:${POSTGRES_PASSWORD}@db:5432/app
    env_file:
      - ./config/api.env

本番環境では、Dockerシークレットが環境変数ではなくファイルとして機密データをマウントすることで、より良いセキュリティを提供する:

yaml
# 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依存関係を持つ初期化コンテナを使用する方法:

yaml
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-composedocker composeの違いは何か?

ハイフン付きのdocker-composeは、現在非推奨となったPythonベースのV1スタンドアロンツールである。スペース区切りのdocker composeは、Docker CLIに統合されたGoベースのV2実装である。V2はより高速で、Compose仕様を完全にサポートし、アクティブに開発が行われている。

Composeアプリケーションのデバッグ

コンテナ化されたアプリケーションのトラブルシューティングには、特定のテクニックが必要である。以下のコマンドは、Composeスタック内で何が起こっているかを明らかにする:

bash
# すべてのサービスのログを表示
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 config

docker compose configコマンドはすべてのcomposeファイルをマージし、最終的な設定を表示する。変数展開の問題をデバッグする際に非常に有用である。

まとめ

  • Docker Composeは、サービス、ネットワーク、ボリュームを単一のYAMLファイルでマルチコンテナアプリケーションを定義する
  • サービスは、デフォルトのブリッジネットワーク内でサービス名をホスト名として使用し、DNS経由で通信する
  • service_healthy条件付きヘルスチェックにより、適切な起動順序が保証される
  • バインドマウントやデバッグポートなどの開発固有の設定にはcompose.override.yamlを使用する
  • 本番デプロイメントでは、リソース制限、再起動ポリシー、機密データ用のDockerシークレットが有益である
  • docker compose CLI(V2)は、より良いパフォーマンスと機能で非推奨のdocker-compose(V1)を置き換えている

今すぐ練習を始めましょう!

面接シミュレーターと技術テストで知識をテストしましょう。

共有

関連記事