サービスの拡張と Compose ファイル

Compose は２つのファイルを共有方法をサポートしています。

  1. Compose ファイル全体を 複数の Compose ファイルを使って 拡張する。
  2. 個々のサービスを `extends` フィールド で拡張する。

複数の Compose ファイル

デフォルトでは、Compose は２つのファイルを読み込みます。 docker-compose.yml と、オプションで docker-compose.override.yml （上書き）ファイルです。慣例として、docker-compose.yml に基本設定を含みます。上書きファイルとは、その名前が暗に示しているように、既存のサービスを新しいサービスに全て置き換えるものです。

もし両方のファイルにサービスが定義されていると、Compose は extends フィールド（ 設定の追加と上書き をご覧ください ）と同じルールを使って設定を統合（マージ）します。ただし、１つだけ例外があります。サービスに link か volumes_from を含んでいる場合、元のサービスのあらゆる箇所の値がコピー・上書きされるだけでなく、同様に単一の値のフィールドもコピーされます。

複数の上書きファイルを使いたい場合や、違った名前で上書きしたい場合は、 -f オプションでファイルの一覧を指定可能です。Compose はコマンドライン上で指定した順番で、ファイルを統合します。詳細は docker-compose コマンド・リファレンス の -f に関する情報をご覧ください。

複数の設定ファイルを使う場合、全てのパスはベースになる Compose ファイル（ -f で一番目に指定したファイル）からの相対パスである必要があります。この指定が必要なのは、上書き用のファイルが適切な Compose ファイル形式でなくても構わないからです。上書きファイルは設定の一部だけでも問題ありません。相対パスで指定されたサービス断片の追跡は、難しく、混乱しがちです。そのため、パスが簡単に分かるようにするため、全てのパスの定義を、ベースファイルからの相対パスにする必要があります。

使用例

このセクションでは、複数の Compose ファイルを使う２つの例をとりあげます。環境の違いにより、構成するアプリを変更する方法。それと、Compose で実行したアプリケーションに対し、管理上のタスクを実行する方法です。

異なった環境

複数のファイルを使う一般的な使用例は、開発環境のアプリ構成を、プロダクション風の環境（プロダクションかもしれませんし、ステージングや CI かもしれません）に変更することです。環境の違いをサポートするには、Compose 設定を複数のファイルに分割します。

まず、サービスを正しく定義するベースファイルは次の通りです。

docker-compose.yml
web:
  image: example/my_web_app:latest
  links:
    - db
    - cache

db:
  image: postgres:latest

cache:
  image: redis:latest

例として、開発環境用の設定に、ホスト上の同じポートを使用し、コードをボリュームとしてマウントし、web イメージを構築するものとします。

docker-compose.override.yml
web:
  build: .
  volumes:
    - '.:/code'
  ports:
    - 8883:80
  environment:
    DEBUG: 'true'

db:
  command: '-d'
  ports:
    - 5432:5432

cache:
  ports:
    - 6379:6379

docker-compose up を実行すると、この上書きファイルを自動的に読み込みます。

次は、Compose を使ったアプリケーションをプロダクション環境で使えるようにします。そのために別の上書きファイルを作成します（このファイルは、異なる git レポジトリに保管されているか、あるいは異なるチームによって管理されているかもしれません）。

docker-compose.prod.yml
web:
  ports:
    - 80:80
  environment:
    PRODUCTION: 'true'

cache:
  environment:
    TTL: '500'

このプロダクション向け Compose ファイルを使ってデプロイするには、次のように実行します。

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

３つの全サービスがデプロイに使う設定が docker-compose.yml と docker-compose.prod.yml に含まれています（ docker-compose.overide.yaml に含まれる開発環境はありません）。

Compose をプロダクションで使うための詳細情報は プロダクション をご覧ください。

管理タスク

他の一般的な使い方は、アドホックの実行や、構成アプリの１つまたは複数のサービスに対する管理タスクの実行です。ここでの例は、データベースのバックアップ実行をデモするものです。

docker-compose.yml を次のようにします。

web:
  image: example/my_web_app:latest
  links:
    - db

db:
  image: postgres:latest

docker-compose.admin.yml に、データベースをエクスポートかバックアップする新しいサービスを追加します。

dbadmin:
  build: database_admin/
  links:
    - db

通常の環境を開始するには docker-compose up -d を実行します。データベースのバックアップを行うには、docker-compose.admin.yml も使います。

docker-compose -f docker-compose.yml -f docker-compose.admin.yml \
    run dbadmin db-backup

サービスの拡張

Docker Compose の extends （拡張）キーワードは、異なったファイル間で設定を共有できるだけでなく、異なったプロジェクトでも利用可能です。拡張サービスは複数のサービスを持っている場合、一般的な設定オプションの再利用に便利です。 extends を使えば、１箇所だけでなく、どこでも利用可能なサービス・オプションの共通セットを定義できます。

注釈

links と volumes_form は extends を使ってもサービスを共有しません。詳細は 設定の追加と上書き をご覧ください。

extends 設定の理解

docker-compose.yml で定義したあらゆるサービスは、次のようにして他のサービスからの拡張（extend）を宣言を宣言できます。

web:
  extends:
    file: common-services.yml
    service: webapp

これは common-services.yml ファイルで定義した webapp サービスの設定を、Compose に再利用するよう命令しています。ここでの common-services.yaml は、次のようなものと仮定します。

webapp:
  build: .
  ports:
    - "8000:8000"
  volumes:
    - "/data"

この例のように、同様の docker-compose.yaml の記述を行えば、web サービスに対する build 、 ports 、 volumes 設定が常に同じになります。

さらに docker-compose.yml でローカル環境の設定（再設定）も行えます。

web:
  extends:
    file: common-services.yml
    service: webapp
  environment:
    - DEBUG=1
  cpu_shares: 5

important_web:
  extends: web
  cpu_shares: 10

あるいは、他のサービスから web サービスにリンクも可能です。

web:
  extends:
    file: common-services.yml
    service: webapp
  environment:
    - DEBUG=1
  cpu_shares: 5
  links:
    - db
db:
  image: postgres

使用例

個々のサービス拡張は、複数のサービスが共通の設定を持っている場合に役立ちます。以下の例では、Compose アプリはウェブ・アプリケーションとキュー・ワーカー（queue worker）の、２つのサービスを持ちます。いずれのサービスも同じコードベースを使い、多くの設定オプションを共有します。

common.yml ファイルでは、共通設定を定義します。

app:
  build: .
  environment:
    CONFIG_FILE_PATH: /code/config
    API_KEY: xxxyyy
  cpu_shares: 5

docker-compose.yml では、共通設定を用いる具体的なサービスを定義します。

webapp:
  extends:
    file: common.yml
    service: app
  command: /code/run_web_app
  ports:
    - 8080:8080
  links:
    - queue
    - db

queue_worker:
  extends:
    file: common.yml
    service: app
  command: /code/run_worker
  links:
    - queue

設定の追加と上書き

Compose は本来のサービス設定を、（訳者注：extends を使う時や、複数ファイルの読み込み時に）各所に対してコピー（引き継ぎ）します。ただし、link と volumes_form は 除外 します。この例外は依存性の衝突を避けるためです。例えば、常に link と volumes_form をローカルで定義していたとします。これはサービス間でファイルを読み込む依存性がある場合、間違いなく（ファイルを）見えるようにします。ローカルにおける定義であれば、参照しているファイルを変更しても、表示上の問題は出ないでしょう。

もしも、設定オプションが元のサービスと、ローカル（直近の設定）のサービスの両方で定義された場合、ローカルの値は置き換えられるか、元の値を拡張します。

image 、command 、 mem_limit のような単一の値のオプションは、古い値が新しい値に置き換わります。

# 元のサービス
command: python app.py

# ローカルのサービス
command: python otherapp.py

# 結果
command: python otherapp.py

build と image の場合、ローカルでサービスの指定があれば、Compose は一方を破棄します。一方がオリジナルのサービスとして定義されている場合でもです。

image が build を置き換える例：

# 元のサービス
build: .

# ローカルのサービス
image: redis

# 結果
image: redis

build がイメージを置き換える例：

# 元のサービス
image: redis

# ローカルのサービス
build: .

# 結果
build: .

複数の値を持つオプショーン、ports 、 expose 、 external_links 、 dns 、 dns_search の場合、Compose は両方の値を連結します。

# 元のサービス
expose:
  - "3000"

# ローカルのサービス
expose:
  - "4000"
  - "5000"

# 結果
expose:
  - "3000"
  - "4000"
  - "5000"

environment 、 label 、volumes 、 devices の場合、Compose はローカルで定義している値を優先して統合します。

# 元のサービス
environment:
  - FOO=original
  - BAR=original

# ローカルのサービス
environment:
  - BAR=local
  - BAZ=local

# 結果
environment:
  - FOO=original
  - BAR=local
  - BAZ=local

Compose のドキュメント

  • ユーザガイド
  • </compose/gettingstarted>
  • </compose/django>
  • </compose/rails>
  • </compose/wordpress>
  • </compose/reference>
  • </compose/compose-file>