6.2 compose.yml 完全ガイド|services/networks/volumes/configs/secretsの書き方

Docker Compose

compose.yml 完全ガイド|services / networks / volumes / configs / secrets の書き方

6-1 で Compose の全体像と最小例を押さえました。ここでは compose.yml構造そのものを、主要キー別に整理します。「どこに何を書けばいいか」を一望できる辞書記事です。

💡 この記事のゴール
① トップレベル5キー(servicesnetworksvolumesconfigssecrets)の役割
services 配下の主要プロパティを網羅的に
③ ネットワーク・ボリュームを明示定義するパターン
④ ファイル名と自動検索のルール

目次

  1. ファイル名と自動検索
  2. トップレベル5つのキー
  3. services の基本プロパティ
  4. build vs image
  5. networks を明示する
  6. volumes を明示する
  7. configs / secrets
  8. フル機能例
  9. まとめ

1. ファイル名と自動検索

docker compose up はカレントディレクトリから以下の順でファイルを探します。

優先度 ファイル名 備考
1 compose.yaml 推奨(Compose V2 以降)
2 compose.yml 同上(.yaml / .yml どちらも可)
3 docker-compose.yaml 旧名
4 docker-compose.yml 旧名
# 明示的にファイルを指定
docker compose -f my-compose.yml up

# 複数ファイルの合成(後から指定したものが上書き)
docker compose -f compose.yml -f compose.override.yml up
💡 compose.override.yml は自動マージ
compose.yml に加えて compose.override.yml が同じディレクトリにあれば、自動で両方を合成して読み込みます。開発用の追加設定(bind mount でコード反映など)を override に書くパターンが定石。

2. トップレベル5つのキー

# compose.yml の全体構造(全てが同じファイル内)
services:    # コンテナ定義(必須)
  ...
networks:    # カスタムネットワーク定義(任意)
  ...
volumes:     # Named Volume 定義(任意)
  ...
configs:     # 設定ファイル配布(任意)
  ...
secrets:     # 機密情報配布(任意)
  ...
キー 役割 省略時
services 各コンテナの定義 必須
networks カスタムネットワーク 自動で default ブリッジが作られる
volumes Named Volume 使わなければ省略可
configs 設定ファイルを複数サービスで共有 使わなければ省略可
secrets パスワード等の機密情報配布 同上
⚠️ version: は書かない
昔の Compose V1 では version: "3.9" などの記述が必須でしたが、V2 以降は無視される(むしろ非推奨)。最新仕様で解釈されます。古いテンプレをコピーしたときは削除推奨。

3. services の基本プロパティ

services:
  web:
    image: nginx:1.27                 # 使うイメージ
    container_name: myweb             # コンテナ名(省略可:自動で <project>-web-1 等)
    ports:                            # -p 相当
      - "8080:80"
    volumes:                          # -v 相当
      - ./html:/usr/share/nginx/html:ro
    environment:                      # -e 相当(dict または list)
      ENV: production
      LOG_LEVEL: info
    env_file:                         # ファイルから環境変数を読み込む
      - .env
    depends_on:                       # 起動順(6-4 で深掘り)
      - db
    restart: unless-stopped           # 停止時の再起動ポリシー
    networks:                         # 参加ネットワーク
      - app-net
    command: ["nginx", "-g", "daemon off;"]   # デフォルトコマンドを上書き
    healthcheck:                      # ヘルスチェック(6-4)
      test: ["CMD", "curl", "-f", "http://localhost/"]
      interval: 30s
      timeout: 3s
      retries: 3
プロパティ docker run 換算
image イメージ名の部分
ports -p
volumes -v
environment -e
env_file docker run 単独にない・シェルで sourceする相当)
networks --network
restart --restart
command イメージ末尾の引数
user -u
working_dir -w

4. build vs image

image: は既存イメージを引いてくるだけですが、build: を使うとCompose 起動時に Dockerfile からビルドできます。

# シンプル:Dockerfile がカレントにある
services:
  app:
    build: .

# 詳細指定
services:
  app:
    build:
      context: ./app          # Dockerfile のあるディレクトリ
      dockerfile: Dockerfile   # ファイル名(デフォルトは Dockerfile)
      args:                    # ビルド時変数
        VERSION: "1.2.3"
      target: production       # マルチステージの対象ステージ

# build と image を併用(ビルド結果に名前を付ける)
services:
  app:
    build: .
    image: myapp:latest
💡 docker compose build で明示ビルド
up 時に自動ビルドもされますが、--build を付けないと既存イメージがあればそれが使われます(ソース変更を反映したいときは docker compose up --build)。

5. networks を明示する

services:
  app:
    networks:
      - frontend
      - backend
  db:
    networks:
      - backend       # db は backend のみに参加(app→db は通るが、proxy→db は通らない)
  proxy:
    networks:
      - frontend

networks:
  frontend:           # シンプル定義(デフォルトは bridge)
  backend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

省略した場合、Compose はプロジェクト名_default という名前のカスタムブリッジを自動作成し、すべてのサービスを参加させます。単純な構成なら何も書かなくて大丈夫。


6. volumes を明示する

services:
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data      # Named Volume
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro  # Bind Mount

volumes:
  pgdata:               # ここに書けば Named Volume として宣言される
  # 外部で作成済みのものを参照
  # shared-vol:
  #   external: true

トップレベルの volumes: に書いた名前は、Compose が自動で <プロジェクト名>_pgdata として作成します。


7. configs / secrets

設定ファイル・機密情報を複数サービスで安全に共有するための仕組みです。bind mount と似ていますが、より構造化された管理が可能。

services:
  app:
    configs:
      - source: app_config
        target: /etc/app/config.yml
    secrets:
      - db_password

configs:
  app_config:
    file: ./config.yml

secrets:
  db_password:
    file: ./secrets/db_password.txt   # コンテナ内 /run/secrets/db_password として読める
💡 機密情報は secrets を使う
DB パスワードなどを environment: に書くと docker inspect で丸見えになります。secrets を使うとコンテナ内のファイル(/run/secrets/経由で安全に渡せます。第8章セキュリティで詳しく扱います。

8. フル機能例

これまでの要素を盛り込んだ、実戦に近いサンプル:

services:
  proxy:
    image: nginx:1.27
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - app
    networks:
      - frontend

  app:
    build:
      context: ./app
      target: production
    environment:
      DATABASE_URL: postgres://postgres:${DB_PASSWORD}@db:5432/postgres
      REDIS_URL: redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    networks:
      - frontend
      - backend

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10
    networks:
      - backend

  cache:
    image: redis:7-alpine
    networks:
      - backend

volumes:
  pgdata:

networks:
  frontend:
  backend:
✅ ここまでで書けるようになった構成
リバースプロキシ + アプリ + DB + キャッシュの4サービス構成・ネットワーク2段分離・ヘルスチェック連携・環境変数のプロジェクト変数展開。これがコンテナ開発の「定型」です。

9. まとめ

キー 何を書くか
services 各コンテナ(image/build/ports/volumes/environment/depends_on/networks…)
networks カスタムネットワークの命名と設定(省略可)
volumes Named Volume の宣言
configs 設定ファイルを複数サービスへ配布
secrets 機密情報をファイル経由で配布
✅ 次のステップ
6-3 docker compose 主要コマンド完全ガイドで、書いたYAMLを実際に動かす up/down/ps/logs/exec/build などを体系的に扱います。

参考リンク


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

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

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

コメント

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