Compose Specification（仕様）¶
Compose ファイルとは、Docker アプリケーション用のサービス、ネットワーク、ボリュームを定義した YAML ファイル です。最新かつ推奨される Compose ファイル形式のバージョンは、 Compose Specification で定義されています。Compose の仕様は、古いバージョン 2.x と 3.x を１つにまとめ、各フォーマット間が
この文章の状態¶
このドキュメントで定めるのは、複数コンテナのアプリケーションを定義するために使う Compose ファイル形式についての仕様です。このドキュメントの配布に制限はありません。
このドキュメントにおけるキーワード「
動作条件とオプションの属性¶
Compose 仕様には、Linux カーネル固有で設定オプションを公開するような、ローカルの OCI コンテナ ランタイムを対象に設計された
私たちが認識しているのは、 全ての 属性をサポートする Compose の実装は一切期待されておらず、また、いくつかの属性はプラットフォームに依存し、実行時にのみ確認できることです。バージョン化された枠組みの定義とは、 Compose ファイル形式が設計された docker-compose ツールによって確立されたもので、 Compose ファイル内でサポートしている属性を制御するためでした。そのため、エンドユーザに属する実装が、実際に行えるかどうかを保証しません。
この仕様が定義するのは、想定している設定情報の構文と挙動ですが、特に注記がなければ、これらをサポートするかどうかは
Compose の実装では、Compose ファイルで
デフォルト：サポート外の属性はユーザに警告するが、それらを無視
厳密 ：サポート外の属性をユーザに警告し、compose ファイルを拒否 緩い ：サポート外および未知の属性を無視する（未知の属性とは、仕様で定義されていない実装によって作成された場合）
Compose のアプリケーション モデル¶
Compose の
アプリケーションの
サービスは ネットワーク（networks） を通して相互に通信します。この仕様では、ネットワークとは
サービスは ボリューム（volumes） 内に
いくつかのサービスは、ランタイムやプラットフォームに依存する
機微情報（secrets） は、セキュリティの考慮なしに公開
volumes、configs、secret 内を区別すると、サービスレベルでも同等の抽象化された実装が行えますが、プラットフォーム固有のリソースにおける明確なデータ仕様用途に対しては、その（固有のリソースに）特化した設定で扱います。
プロジェクト（project） は、個々のアプリケーション仕様をプラットフォーム上に展開したものです。プロジェクトの名前は、リソースを一緒に扱うグループのために使われたり、他のアプリケーションとは分離されたり、同じ Compose 仕様のアプリケーションでありながら、特定のパラメータを持つ他のものをインストールします。プラットフォーム上の Compose 実装は、プロジェクトごとにリソース名を前につけ、ラベル com.docker.compose.project を
プロジェクト名は、トップレベルの name 属性で明示できます。Compose 実装では、ユーザが任意のプロジェクト名の指定と、この名前を上書きできるように compose.yaml ファイルを元にしながら、変更のない同じ構造を２つデプロイできます。
説明例¶
以下の例では、具体的なアプリケーション例を使い Compose 仕様の概要を説明します。この例は規範的ではありません。
フロントエンド ウェブアプリケーションとバックエンド サービスに分かれたアプリケーションを考えます。
フロントエンドは、基盤によって管理されている HTTP 設定ファイルを使い、実行時に設定をします。設定とは、外部でのドメイン名と、プラットフォームの安全な
バックエンドは
どちらのサービスも隔離された後方ネットワーク上で互いに通信します。一方、フロントエンドも前方ネットワークに接続し、外部から使うためにポート 443 を公開します。
このアプリケーション例では、以下のパーツを組み込んでいます。
2つのサービス、 Docker イメージを元にしている：
webappとdatabase1つの機微情報（HTTPS 証明書）、フロントエンドに投入
1つの設定情報（HTTP）、フロントエンドに投入
1つの持続型ボリューム、バックエンドに
取り付け 2つのネットワーク
services:
frontend:
image: awesome/webapp
ports:
- "443:8043"
networks:
- front-tier
- back-tier
configs:
- httpd-config
secrets:
- server-certificate
backend:
image: awesome/database
volumes:
- db-data:/etc/data
networks:
- back-tier
volumes:
db-data:
driver: flocker
driver_opts:
size: "10GiB"
configs:
httpd-config:
external: true
secrets:
server-certificate:
external: true
networks:
# これらオブジェクトを定義するには、存在するだけで十分
front-tier: {}
back-tier: {}
この例では、 volumes 、 configs 、 secrets 間の違いを示します。これらはすべて、サービス用コンテナに対してファイルやディレクトリをマウントしているように見えますが、ボリュームのみ読み込みと書き込みの作業ができます。secrets と configs は読み込み専用です。実際の基盤にしたがってボリューム管理を調整するには、ボリュームの設定情報によって、ボリュームドライバを選択したり、ドライバにオプションを渡せたりします。configs と secrets はプラットフォーム上のサービスに依存します。また、これらはアプリケーションのライフサイクルとして管理されないため、 external と宣言します。つまり、 Compose の実装では、プラットフォーム固有の
Compose ファイル¶
Compose ファイルとは YAML ファイルであり、 version （非推奨）、 services （必須）、 networks 、 volumes 、 configs 、 secrets を定義します。作業ディレクトリ内での、Compose ファイルのデフォルトのパスは compose.yaml （推奨）か compose.yml です。Compose 実装は、下位互換性のために docker-compose.yaml と docker-compose.yml もサポート compose.yaml を優先
アプリケーション モデルを定義するために、複数の Compose ファイルを一緒に組み合わせられます。YAML ファイルの結合にあたっては、ユーザによって指定された Compose ファイルの順番に基づき、 YAML 要素の追加と上書きを実装
いくつかの Compose ファイル要素は、単一文字列か複雑なオブジェクトとして表記できるため、統合する場合は拡張形式を適用
profiles¶
profiles によって、様々な用途や環境にあわせて Compose アプリケーション モデルを調整できます。Compose 実装は、ユーザがアクティブな profiles のセットを定義できるように
サービスのトップレベル要素は、 profiles 属性をサポートし、 profiles 名の一覧を定義します。 profiles 属性セットの無いサービスは、常に有効に profiles に一致するアクティブな profiles が存在しなければ、サービスがコマンドで対象を明示されていない限り、サービスは Compose 実装によって無視
他のサービスへの参照（ links 、 extends 、共有リソース構文 service:xxx ）は、アクティブな profiles によって無視されたコンポーネントを自動的に有効化
説明例¶
services:
foo:
image: foo
bar:
image: bar
profiles:
- test
baz:
image: baz
depends_on:
- bar
profiles:
- test
zot:
image: zot
depends_on:
- bar
profiles:
- debug
profiles を有効にしないで構文解析された Compose アプリケーション モデルには、
fooサービスしか含みません。
profiles で
testを有効化する場合、モデルに含まれるサービスはtestprofile によって有効化されるbarとbazのサービスと、サービスfooは常に有効です。
profiles で
debugを有効化する場合、モデルに含まれるサービスはfooとzotの両方ですが、barとbazやzotのdepends_on条件があるようなモデルも無効です。
profiles
debugとtestを有効化する場合、モデルには全てのサービスを含みます。つまり、foo、bar、baz、zotです。
barを起動するサービスとして明示して Compose 実装を実行する場合、「ユーザによって」testprofile を有効にしていない場合でも、barとtstをサービスとして実行します。
bazを起動するサービスとして明示して Compose 実装を実行する場合、サービスbazとtestprofile が有効になり、depends_on強制によってbarも実行されます。
zotを起動するサービスとして明示して Compose 実装を実行する場合、zotとbarに共通するprofilesが一覧にないため、zotのdepends_on強制についてのモデルは無効になります。
zotを起動するサービスとして明示し、 profiletestを有効にして Compose 実装を実行する場合、profiledebugが自動的に有効になり、サービスzotとbarの両方は依存関係があるため、barが実行されます。
version トップレベル要素¶
トップレベルの version 属性は、下位互換性のために仕様で定義されていますが、情報を参考にするためだけです。
Compose 実装は、 Compose ファイルの検証にあたり、正確なスキームを選ぶためにこの version を使う
Compose 実装は Compose ファイルを完全に構文解析できるかどうかを検証
name トップレベル要素¶
トップレベルの name 属性は、ユーザが明示的に設定しない場合に使われる、プロジェクト名として仕様で定義されています。Compose 実装では、ユーザこの名前を上書きする方法を提供 name 要素が設定されない場合、デフォルトのプロジェクト名を
トップレベルの name や何らかの特別な仕組みによってプロジェクト名が定義される場合は、ただちに 補完 で変数展開したり、環境変数 COMPOSE_PROJECT_NAME として解決できるように
services:
foo:
image: busybox
environment:
- COMPOSE_PROJECT_NAME
command: echo "I'm running ${COMPOSE_PROJECT_NAME}"
services トップレベル要素¶
Compose ファイルでは、 services ルート要素を宣言する
各サービスには build セクションも
build のサポートは、 Compose 仕様において
各サービスは、サービスを実行する deploy セクションは、これらの制約をグループ化できます。さらに、プラットフォームは利用可能なリソースと、コンテナが必要なリソースを一致させるよう、
deploy のサポートは Compose 仕様において
build¶
build 、はソースからコンテナ イメージを作成するための
blkio_config¶
blkio_config が定義するのは、サービスに対するブロック IO を制限するオプション設定の集まりです。
services:
foo:
image: busybox
blkio_config:
weight: 300
weight_device:
- path: /dev/sda
weight: 400
device_read_bps:
- path: /dev/sdb
rate: '12mb'
device_read_iops:
- path: /dev/sdb
rate: 120
device_write_bps:
- path: /dev/sdb
rate: '1024k'
device_write_iops:
- path: /dev/sdb
rate: 30
device_read_bps、 device_write_bps¶
特定のデバイス上で、読み書き処理に対する制限を、1秒あたりのバイト数で指定します。リスト内の各項目は、2つのキーを持つ
path：影響があるデバイスへのシンボリック パスを定義rate：バイト数を表す整数値、あるいは、バイト値を表現する文字列のどちらか
device_read_iops、 device_write_iops¶
特定のデバイス上で、読み書きに対する制限を、1秒あたりの処理回数で指定します。リストの各項目は、2つのキーを持つ
path：影響があるデバイスへのシンボリック パスを定義rate：1秒あたりに許可する処理回数を、整数値で示す
weight¶
他のサービスと比較し、このサービスに割り当てる帯域の比率を調整します。 10 から 1000 までの整数値をとり、デフォルトは 500 になります。
weight_device¶
デバイスに対する帯域を微調整します。各アイテムの値は2つのキーを持つ必要があります。リストの各項目は、2つのキーを持つ
path：影響があるデバイスへのシンボリック パスを定義weight： 10 から 1000 までの整数値
cpu_percent¶
利用可能な CPU で使用する割合を定義します。
cpu_period¶
プラットフォームが Linux カーネルを基盤としている場合、 cpu_period は CPU CFS ( Complete Fair Scheduler , 完全公平スケジューラ ) 期間の設定を Compose 実装が行えるようにします。
cpu_quota¶
プラットフォームが Linux カーネルを基盤としている場合、 cpu_period は CPU CFS ( Complete Fair Scheduler , 完全公平スケジューラ ) クォータの設定を Compose 実装が行えるようにします。
cpu_rt_runtime¶
cpu_rt_runtime は、リアルタイム スケジューラをサポートするプラットフォームに対し、 CPU 割り当てパラメータを設定します。マイクロ秒の単位を整数値で指定するか、 期間 のどちらかで指定します。
cpu_rt_runtime: '400ms'
cpu_rt_runtime: 95000`
cpu_rt_period¶
cpu_rt_period は、リアルタイム スケジューラをサポートするプラットフォームに対し、 CPU 割り当てパラメータを設定します。マイクロ秒の単位を整数値で指定するか、 期間 のどちらかで指定します。
cpu_rt_period: '1400us'
cpu_rt_period: 11000`
command¶
command はコンテナ イメージによって宣言済み（例： Dockerfile の CMD ）のデフォルト コマンドを上書きします。
command: bundle exec thin -p 3000
コマンドはリストにもでき、 Dockerfile の書き方に似ています。
command: [ "bundle", "exec", "thin", "-p", "3000" ]
configs¶
configs は、サービスごとの configs
Compose の実装は、プラットフォーム上に configs セクションで定義されていなければ、エラーを
configs を定義する構文は2つあります。この実装に従い続ける限り、実装は両方の構文をサポート
短い構文¶
/<設定名> としてマウントします。ソース名とマウントポイント先は、どちらも
以下の例では短い構文を使い、 redis サービスに対して my_config と my_other_config 設定情報へのアクセスを許可します。 my_config の値は ./my_config.txt ファイルの中に設定されます。そして、 my_other_config は外部リソースとして定義されており、つまり、既にプラットフォーム内で定義済みを意味します。外部の設定情報が存在しなければ、デプロイは
services:
redis:
image: redis:latest
configs:
- my_config
configs:
my_config:
file: ./my_config.txt
my_other_config:
external: true
長い構文¶
長い構文により、より詳細な
source：プラットフォーム内に存在する設定情報の名前target：サービス用タスクコンテナ内にマウントする、ファイルのパスと名前uidとgid：サービス用タスクコンテナ内にマウントする、設定ファイルを所有する UID か GID を示す整数mode：サービス用タスクコンテナ内にマウントする、ファイルに対する パーミッション を8進数で指定。デフォルト値は誰でも読み込み可能（0444）。書き込み可能なビットは無視しなければいけません 。実行可能ビットは設定できます。
以下の例は my_config という名前の設定情報をコンテナ内の redis_config に設定し、モードを 0440 （グループ読み込み可能）とし、ユーザとグループを 103 に設定します。この redis サービスは、 my_other_config 設定に対してアクセスできない。
services:
redis:
image: redis:latest
configs:
- source: my_config
target: /redis_config
uid: "103"
gid: "103"
mode: 0440
configs:
my_config:
external: true
my_other_config:
external: true
サービスに対し、複数の設定情報へのアクセスを許可できます。また、長い形式と短い形式を混在できます。
container_name¶
container_name は、デフォルトで生成される名前ではなく、任意のコンテナ名を指定する文字列です。
container_name: my-web-container
Compose ファイルで container_name を指定している場合、Compose 実装は、コンテナ1つよりも多くにサービスをスケール
指定するには、 container_name は正規表現の形式 [a-zA-Z0-9][a-zA-Z0-9_.-]+ に
credential_spec¶
credential_spec は、マネージド サービス アカウント用の
Windows コンテナーを使うサービスをサポートする Compose 実装では、credential_spec のために file: と registry: プロトコルのサポートが
credential_spec は file://<ファイル名> か registry://<値の名前> の形式にする必要があります。
credential_spec:
file: my-credential-spec.json
registry: を使う場合、 デーモンのホスト上にある Windows レジストリから、
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs
以下の例は、レジストリ内の my-credential-spec という名前の値から、
credential_spec:
registry: my-credential-spec
gMSA 設定情報の例¶
サービスに対して gMSA 認証情報を設定する場合、必要なのは以下の例にあるように、 config で認証情報仕様を指定するだけです。
services:
myservice:
image: myimage:latest
credential_spec:
config: my_credential_spec
configs:
my_credentials_spec:
file: ./my-credential-spec.json|
depends_on¶
depends_on はサービス間の起動順番と終了順番の依存関係を表します。
短い構文¶
短い構文の形式は、依存関係があるサービス名のみ指定します。サービスの依存関係によって、次の挙動をもたらします。
Compose 実装は、依存関係のある順番でサービスを作成する
必要があります 。以下の例では、webの前にdbとredisが作成されます。Compose 実装は、依存関係のある順番でサービスを削除する
必要があります 。以下の例では、dbとredisの前にwebが削除されます。
簡単な例：
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres
Compose 実装は、依存先のサービスが起動する前に、依存元のサービスを確実に
長い構文¶
長い構文の形式は、短い形式では指定できない追加のフィールドも設定可能になります。
condition：依存関係を満たしているとみなす状態service_started：前述の短い構文のものと同等service_healthy：依存先のサービスを起動する前に、依存元のサービスが「正常 」（ healthcheck で示す）な状態を指定service_completed_successfully：依存先のサービスを起動する前に、依存元のサービスは正常に実行済みの状態を指定
サービスの依存関係は、次のような挙動になります。
Compose 実装は、依存関係のある順番でサービスを作成する
必要があります 。以下の例では、webの前にdbとredisが作成されます。Compose 実装は、依存元のサービスが
service_healthyで示すヘルスチェックを通過するまで待つ必要があります 。以下の例では、dbが 「正常 」な状態になった後、webが作成されます。Compose 実装は、依存関係のある順番でサービスを削除する
必要があります 。以下の例では、dbとredisの前にwebが削除されます。
簡単な例：
services:
web:
build: .
depends_on:
db:
condition: service_healthy
redis:
condition: service_started
redis:
image: redis
db:
image: postgres
Compose 実装は、依存元のサービスが起動する前に、依存先のサービスを確実に起動する service_healthy （サービス正常性）が確実に「
device_cgroup_rules¶
device_cgroup_rules は、このコンテナに対するデバイス cgroup ルールの一覧を定義します。書式は Control Groups Device Whitelist Controller にある Linux カーネルが指定する書式と同じです。
device_cgroup_rules:
- 'c 1:3 mr'
- 'a 7:* rmw'
devices¶
devices は、作成したコンテナにマッピングするデバイスの一覧を HOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS] の形式で定義します。
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/sda:/dev/xvda:rwm"
dns_search¶
dns_search は、コンテナのネットワーク インタフェース設定に、任意の DNS 検索ドメインを定義します。単一の値、もしくはリストで設定できます。
dns_search: example.com
dns_search:
- dc1.example.com
- dc2.example.com
domainname¶
domainname では、サービス用コンテナが使う任意のドメイン名を宣言します。これは有効な RFC 1123 ホスト名の
entrypoint¶
entrypoint は Docker イメージのデフォルト entrypoint （つまり、 Dockerfile の ENTRYPOINT 設定）を上書きします。Compose 実装は、 Docker イメージ内のあらゆるデフォルトコマンドを除去する ENTRYPOINT と CMD の両命令であり、 Compose ファイルでは entrypoint で設定します。もしも command が設定されている場合、これが Docker イメージの CMD を置き換え、 entrypoint のパラメータとして使われます。
entrypoint: /code/entrypoint.sh
entrypoint はリストにもでき、書き方は Dockerfile と似ています。
entrypoint:
- php
- -d
- zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
- -d
- memory_limit=-1
- vendor/bin/phpunit
env_file¶
env_file はファイルの内容をもとに、コンテナへ環境変数を追加します。
env_file: .env
env_file はリストにもできます。ファイル内のリストは、上から下へと処理する
env_file:
- ./a.env
- ./b.env
相対パス、は Compose ファイルの親フォルダを基準に解決する env_file に絶対パスが使われていれば、
environment セクションで宣言された環境変数は、これらの値を上書き env_file を使って定義された変数の値が、空白もしくは未定義だとしても、保持し続けます。
env_file 形式¶
env_file の各行は 変数[=[値]] の形式である # で始まる行は無視する
値 の値は、そのままの文字列として使われ、加工は一切行われません。値が引用符で囲まれた場合（通常、シェル変数を扱う場合）、Compose 実装によって作成されるコンテナに対し、引用符を 含めて 渡す
値 は省略する =値 は省略する
# Rails/Rack 環境変数を設定
RACK_ENV=development
VAR="quoted"
environment¶
environment は、コンテナ内での環境変数を定義します。 environment は配列とマップのどちらかを使えます。あらゆるブール値、true、false、yes、no は、YAML パーサによって True や False に変換されないようにするため、引用符で囲むように
環境変数の値は、1つのキーで宣言
マップ形式の構文：
environment:
RACK_ENV: development
SHOW: "true"
USER_INPUT:
配列形式の構文：
environment:
- RACK_ENV=development
- SHOW=true
- USER_INPUT
サービスに対して env_file と environment の両方がある場合、 environment の値が優先されます。
expose¶
expose では、 Compose 実装がコンテナから公開
expose:
- "3000"
- "8000"
extends¶
現在のファイルや他のファイルからサービスを extends を使えます。 extends の値はマップで定義する service キーは必須で、 file キーはオプションです。
extends:
file: common.yml
service: webapp
Compose 実装がサポートする場合は、以下の方法で extends を処理する
serviceベース（元になるもの）として参照されるサービスの名前を定義します。たとえばwebやdatabaseです。fileは対象サービス向けの Compose 設定情報ファイルの場所です。
制限事項¶
参照されるサービスには、以下の制限が適用されます。
他のサービスと依存関係を持つサービスは、他のサービスからのベースとして使えません。つまり、他のサービスに依存しているキーは、
extendsと互換性がありません。このようなキーの網羅的ではない一覧：links、volumes_from、containerモード（ipd、pid、network_mode、net）、serviceモード（ipc、pid、network_mode、depends_on）。
サービスは
extendsで循環参照 できません。
Compose 実装は、これ以外のケースでエラーを返す
参照されているサービスを探す¶
file の値とは：
存在しない場合。これは同じ Compose ファイル内の別のサービスが参照されているのを示します。
以下どちらかのファイルパスです。
相対パス。このパスはメインの Compose がある場所からの相対パスとみなします。
絶対パス。
service によって示すサービスは、参照用として指定された Compose ファイルに存在する
serviceで示されたサービスが見つからないfileで示された Compose ファイルが見つからない
サービス定義の統合¶
2つのサービス定義（1つは main で現在の Compose ファイル、もう1つは extends で指定した referenced として参照されるもの）は、以下の方法で統合する
マッピング ： main サービス定義のマッピング内のキーは、 referenced サービス定義のマッピング内のキーを上書きします。上書きされないキーは、そのまま含まれたままです（残ったままです）。シーケンス ：アイテムは結合され、新しいシーケンスになります。要素の順番は、 referenced アイテムが最初で、次に main アイテムが続きます。スカラー ： main サービス内の定義は、 referenced サービス定義内のキーよりも優先されます。
マッピング ¶
次のキーがマッピングとして扱われるでしょう： build.args 、 build.labels 、 build.extra_hosts 、 deploy.labels 、 deploy.update_config 、 deploy.rollback_config 、 deploy.restart_policy 、 deploy.resources.limits 、 environment 、 healthcheck 、 labels 、 logging.options 、 sysctls 、 storage_opt 、 extra_hosts 、 ulimits. 。
healthcheck に対しては例外が適用されます。 referenced マッピングで disable: true を指定しない限り、 main マッピングでも disable: true を指定できません。Compose 実装は、このような場合にエラーを返す
たとえば、以下のような入力があります。
services:
common:
image: busybox
environment:
TZ: utc
PORT: 80
cli:
extends:
service: common
environment:
PORT: 8080
以下の設定で cli サービスを生成します。配列形式を使うと、同じ出力が生成されます。
environment:
PORT: 8080
TZ: utc
image: busybox
blkio_config.device_read_bps 、 blkio_config.device_read_iops 、 blkio_config.device_write_bps 、 blkio_config.device_write_iops 、 devices and volumes 以下のアイテムも、キーとしてコンテナ内のパスが対象にあれば、マッピングとして扱われます。
たとえば、以下のような入力があります。
services:
common:
image: busybox
volumes:
- common-volume:/var/lib/backup/data:rw
cli:
extends:
service: common
volumes:
- cli-volume:/var/lib/backup/data:ro
以下の設定で cli サービスを生成します。注意点として、マウントされたパスは新しいボリューム名を指し示し、 ro フラグが適用されます。
image: busybox
volumes:
- cli-volume:/var/lib/backup/data:ro
referenced サービスの定義が extends マッピングを含む場合は、新しい統合された定義に対し、アイテム以下がシンプルにコピーされます。統合の処理は extends キーが存在しなくなるまで、繰り返し行われます。
たとえば、以下のような入力があります。
services:
base:
image: busybox
user: root
common:
image: busybox
extends:
service: base
cli:
extends:
service: common
以下の設定で cli サービスを生成します。ここでは、 cli サービスは common サービスから user キーを取得します。サービスは base サービスからこのキーを取得します。
image: busybox
user: root
シーケンス ¶
以下のキーはシーケンスとして扱われるべきです：cap_add 、 cap_drop 、 configs 、 deploy.placement.constraints 、 deploy.placement.preferences 、 deploy.reservations.generic_resources 、 device_cgroup_rules 、 expose 、 external_links 、 ports 、 secrets 、 security_opt 。統合の結果、重複した結果は削除されるため、シーケンスに含まれるのはユニークな（重複しない）要素のみです。
たとえば、以下のような入力があります。
services:
common:
image: busybox
security_opt:
- label:role:ROLE
cli:
extends:
service: common
security_opt:
- label:user:USER
以下の設定で cli サービスを生成します。
image: busybox
security_opt:
- label:role:ROLE
- label:user:USER
リスト形式を使う場合、以下のキーはシーケンスとしても扱われるべきです： dns 、 dns_search 、 env_file 、 tmpfs 。先述したシーケンスのフィールドとは異なり、統合の結果、重複したものは削除されます。
スカラー ¶
その他のサービス内で許可されたキーは、スカラーとして扱われるべきです。
external_links¶
external_links は、この Compose アプリケーションの外で管理されているサービスと、サービスコンテナを external_links で定義するのは、プラットフォームの検索機能を使って受け取る、既存のサービス名です。 サービス:別名 形式で
external_links:
- redis
- database:mysql
- database:postgresql
extra_hosts¶
extra_hosts はコンテナのネットワーク インタフェース設定（ Linux は /etc/hosts ）に対して、ホスト名のマッピングを追加します。値には、ホスト名と IP アドレスを ホスト名:IP の形式で指定する
extra_hosts:
- "somehost:162.242.195.82"
- "otherhost:50.31.209.229"
Compose 実装は、コンテナのネットワーク設定内に IP アドレスとホスト名に一致するエントリを /etc/hosts に次のような行が追加されるのを意味します。
162.242.195.82 somehost
50.31.209.229 otherhost
group_add¶
group_add は、コンテナイアのユーザが所属する
便利な例は、共有ボリューム上の同じファイルを（異なるユーザとして実行している）複数のコンテナから読み書きする場合です。対象のファイルを所有するのは、全てのコンテナ内で共通しているグループと、 group_add で指定されたグループです。
services:
myservice:
image: alpine
group_add:
- mail
作成されたコンテナ内で id を実行すると、ユーザは mail グループとして group_add で宣言されていない場合は、このようになりません。
healthcheck¶
healthcheck で定義するのは、このサービスが「
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 1m30s
timeout: 10s
retries: 3
start_period: 40s
interval 、 timeout 、 start_period は 期間を指定 します。
test で定義するコマンドのは、 Compose 実装がコンテナが正常かどうかを確認するために実行するものです。コマンドは文字列もしくはリストです。リストの場合、1番目の項目は NONE 、 CMD 、 CMD-SHELL のどちらかである必要があります。文字列の場合は CMD-SHELL を指定したのと同じになり、以降に文字列が続きます。
# ローカルのウェブアプリをたたく
test: ["CMD", "curl", "-f", "http://localhost"]
CMD-SHELL を使うと、コンテナのデフォルトシェル（ Linux の場合は /bin/sh ）を使い、文字をコマンドとして扱い実行します。以下はどちらも同じ処理内容です。
test: ["CMD-SHELL", "curl -f http://localhost || exit 1"]
test: curl -f https://localhost || exit 1
NONE はヘルスチェックを無効にします。多くの場合、イメージによって設定されているヘルスチェックの無効化に役立ちます。あるいは、 disable: true の設定によっても、イメージのヘルスチェックを無効化できます。
healthcheck:
disable: true
image¶
image は、コンテナの元になるイメージを指定します。イメージは [<registry>/][<project>/]<image>[:<tag>|@<digest>] です。
image: redis
image: redis:5
image: redis@sha256:0ed5d5928d4737458944eb604cc8509e245c3e19d02ad83935398bc4b991aac7
image: library/redis
image: docker.io/library/redis
image: my_private.registry:5000/redis
もしもイメージがプラットフォーム上に存在しなければ、 Compose 実装は pull_policy をもとに
Compose ファイルで build セクションを宣言する場合、 image は image がなければ失敗
init¶
init はコンテナ内で init プロセス（ PID 1 ）として実行するものです。これは（コンテナが受け取った）シグナルを転送し、プロセスとして処理できるようにします。サービスでこの機能を有効かするには、オプションで true に設定します。
services:
web:
image: alpine:latest
init: true
この init バイナリは、プラットフォームが指定のものを使います。
ipc¶
ipc はサービス用コンテナによって設定される IPC isolation モードを設定します。利用できる値はプラットフォーム固有ですが、 Compose 仕様では、サポートする場合は以下どちらかの手段によって値を決めるよう定義しなければいけません。
shareableはコンテナ自身のプライベート IPC 名前空間に与えますが、他のコンテナからも共有できる可能性があります。service:{name}のコンテナには、他の（共有可能な）コンテナの IP 名前空間から接続できます。
ipc: "shareable"
ipc: "service:[service name]"
labels¶
labels はコンテナにメタデータを追加します。
使っているソフトウェアと他のソフトウェアの衝突を避けるため、逆引き DNS 記法の使用を推奨します。
labels:
com.example.description: "Accounting webapp"
com.example.department: "Finance"
com.example.label-with-empty-value: ""
labels:
- "com.example.description=Accounting webapp"
- "com.example.department=Finance"
- "com.example.label-with-empty-value"
Compose 実装は、作成するコンテナが、
com.docker.compose.projectCompose 実装によって作成された全てのリソースを、ユーザ プロジェクト名 に設定する。com.docker.compose.serviceサービス用コンテナを、 Compose ファイルで定義されたサービス名を使って設定する。
com.docker.compose ラベルのプレフィクスは予約済みです。Compose ファイルにこのプレフィクスがあれば、結果ランタイムエラーとする
links¶
links は、他のサービス内にあるコンテナへのネットワーク サービス:別名 ）するか、サービス名のみ指定します。
web:
links:
- db
- db:database
- redis
リンクされたサービスのコンテナは、別名と同じホスト名で、あるいは別名の指定が無い場合はサービス名で到達可能に
サービス間で通信できるようにするためには、 links は必須ではありません。たとえば、ネットワーク設定の指定が無くても、あらゆるサービスは、 default ネットワーク上では、サービス名を使って他のサービスに到達できるように links でネットワーク設定を上書き
また、 links は depends_on と同じように、サービス間での暗黙的な依存関係を表しますので、サービスの起動順番を決めます。
logging¶
logging はサービスの
logging:
driver: syslog
options:
syslog-address: "tcp://192.168.0.42:123"
driver 名は、サービス用コンテナのログ記録ドライバを指定します。デフォルトかつ利用可能な値は、プラットフォーム固有です。ドライバ固有のオプションは、 options にキーバリューのペアで指定できます。
network_mode¶
network_mode は、サービス コンテナのネットワーク モードを設定します。利用可能な値はプラットフォーム固有ですが、サポートする場合、 Compose 仕様では以下のように値を実装
none全てのコンテナ ネットワーク機能を無効化hostコンテナはホスト側のネットワーク インタフェースに直接アクセスできるようにするservice:{名前}コンテナを特定のサービスのみ接続できるようにする
network_mode: "host"
network_mode: "none"
network_mode: "service:[service name]"
networks¶
networks はサービス コンテナを
services:
some-service:
networks:
- some-network
- other-network
aliases¶
aliases は、このサービスに対してサービス上で別のホスト名を宣言します。同じネットワーク上にある他のコンテナは、サービス名か、この
aliases は
注釈
一般的な形式は、以下の通りです：
services:
some-service:
networks:
some-network:
aliases:
- alias1
- alias3
other-network:
aliases:
- alias2
次の例では、サービス frontend は、 back-tier ネットワーク上にある、ホスト名 backend か database で backend サービスに対して到達可能です。また、サービス monitoring は、同じ admin ネットワーク上にある backend サービスに対して、 backend か mysql で到達可能です
services:
frontend:
image: awesome/webapp
networks:
- front-tier
- back-tier
monitoring:
image: awesome/monitoring
networks:
- admin
backend:
image: awesome/backend
networks:
back-tier:
aliases:
- database
admin:
aliases:
- mysql
networks:
front-tier:
back-tier:
admin:
ipv4_address 、 ipv6_address¶
このサービスがネットワークに接続する時、コンテナに対する固定 IP アドレスを指定します。
トップレベルの networks セクション 内にある ipam ブロックで、各固定アドレスを扱うサブネット設定が必要です。
services:
frontend:
image: awesome/webapp
networks:
front-tier:
ipv4_address: 172.16.238.10
ipv6_address: 2001:3984:3989::10
networks:
front-tier:
ipam:
driver: default
config:
- subnet: "172.16.238.0/24"
- subnet: "2001:3984:3989::/64"
link_local_ips¶
link_local_ips はリンクローカル IP アドレスのリストを指定します。リンクローカル IP アドレスとは、既知のサブネットに所属し、作業者によって純粋に管理される特別な IP アドレスで、通常はデプロイされるアーキテクチャに依存します。実装はプラットフォーム固有のものです。
例：
services:
app:
image: busybox
command: top
networks:
app_net:
link_local_ips:
- 57.123.22.11
- 57.123.22.13
networks:
app_net:
driver: bridge
priority¶
priority は、 Compose 実装がサービス用コンテナをネットワークに接続
以下の例では、app サービスは第一に接続するのは、高い優先度を持つ app_net_1 です。それから app_net_3 に接続し、さらにデフォルト優先度の値 0 を使う app_net_2 に接続します。
services:
app:
image: busybox
command: top
networks:
app_net_1:
priority: 1000
app_net_2:
app_net_3:
priority: 100
networks:
app_net_1:
app_net_2:
app_net_3:
mac_address¶
mac_address はサービス コンテナに MAC アドレスを設定します。
mem_limit¶
非推奨： deploy.limits.memory を使います。
mem_reservation¶
非推奨： deploy.reservations.memory を使います。
mem_swappiness¶
mem_swappiness は、ホスト kernel がコンテナで使用される
0 の値は、無名メモリ ページ のスワップを無効にする
100 の値は、全ての無名メモリ ページをスワップ可能にする
デフォルトの値はプラットフォーム固有のものです。
memswap_limit¶
memswap_limit は、ディスクへのスワップを許可するコンテナのメモリ容量を定義します。これは memory も設定されている場合のみ変更可能な属性です。スワップを使うと、コンテナが利用可能な全てのメモリを使い尽くした時、コンテナは要求されない余分なメモリをディスクに書き込めます。ディスクに対するスワップメモリが頻発するアプリケーションは、パフォーマンスが低下します。
memswap_limitに整数値を設定する場合、memoryとmemswap_limitの両方を設定 しなくてはいけません。 。memswap_limitは利用可能な全メモリ容量とスワップを表し、memoryはスワップしないで使うメモリ容量を制御します。そのため、memoryが 300m とmemswap_limitが 1g の場合、コンテナは 300m のメモリと 700m（1g - 300m）のスワップを利用できます。memswap_limitを 0 に設定する場合、設定は無視しなければいけません 。そして値は未定義 として扱われます。memswap_limitをmemoryと同じ値に設定する場合かつmemoryを整数値に設定する場合、コンテナはスワップにアクセスしません。 コンテナがスワップをしないようにする をご覧ください。memswap_limitが未定義で、かつ、memoryが設定されている場合、ホスト コンテナにスワップメモリが設定されていれば、コンテナはmemory設定と同じ容量のスワップを利用できます。たとえば、memoryが 300m でmemswap_limitが設定されていなければ、コンテナはメモリとスワップで合計 600m 利用できます。memswap_limitを -1 に明示すると、ホストシステム上で利用可能な上限まで、コンテナが無制限にスワップを利用できます。
oom_kill_disable¶
oom_kill_disable を設定する場合、 Compose 実装は、メモリ不足が発生してもコンテナを
oom_score_adj¶
oom_score_adj はメモリ不足が発生した場合、プラットフォームによって
pids_limit¶
非推奨： deploy.reservations.pids を使います。
pids_limit はコンテナの PID の上限を調整します。-1 に設定すると、PID を無制限にします。
pids_limit: 10
platform¶
platform は、このサービスを実行するための os[/arch[/variant]] 構文を使います。Compose 実装は、どのバージョンのイメージを取得するかを決める場合や、どのプラットフォームでサービスの構築を実行するかを決める場合に、宣言時にこの属性を使う
platform: osx
platform: windows/amd64
platform: linux/arm64/v8
ports¶
コンテナのポートを network_mode: host を使う場合は、ポートマッピングを
短い形式¶
短い形式はコロン記号で区切られた文字列で、ホスト IP 、ホスト側ポート、コンテナ側ポートを [ホスト:]コンテナ[/プロトコル] の形式で設定します。
ホストは[IP:](ポート番号|範囲)コンテナはポート番号|範囲プロトコルは指定したプロトコルにポートを制限します。仕様ではtcpとudpの値が定義されており、 Compose 実装ではプラットフォーム固有のプロトコル名をサポートする場合があります 。
ホスト IP の指定がなければ、全てのネットワークインタフェースを
両方のポート（ ホスト:コンテナ ）を指定するか、コンテナのポートだけを指定するかのどちらかです。後者の場合、Compose 実装は自動的に未割り当てのホスト側ポートを割り当てる ホスト:コンテナ の場合、 yaml base-60 float との衝突を避けるため、常に（引用符で囲まれた）文字列で
例：
ports:
- "3000"
- "3000-3005"
- "8000:8000"
- "9090-9091:8080-8081"
- "49100:22"
- "127.0.0.1:8001:8001"
- "127.0.0.1:5000-5010:5000-5010"
- "6060:6060/udp"
注釈
ホスト IP の
長い形式¶
長い形式の構文は、短い形式では表現できない追加フィールドで調整をできるようにします。
target：コンテナ側ポートpublished：パブリックに公開される ポート。構文start-endを使って範囲を指定できます。実際のポートは、この利用可能なポート範囲にもとづいて割り当てられるべきです 。host_ip：ホスト IP を割り当て。未指定は全てのネットワークインタフェース（0.0.0.0）を意味するprotocol：ポートのプロトコル（tcpかudp）。未定義はあらゆるプロトコルを意味するmode：hostは各ノード上のホスト側ポートで公開。または、ingressは負荷分散されたポートで公開。
ports:
- target: 80
host_ip: 127.0.0.1
published: 8080
protocol: tcp
mode: host
- target: 80
host_ip: 127.0.0.1
published: 8000-9000
protocol: tcp
mode: host
privileged¶
privileged 設定は、昇格した権限でサービスコンテナを実行します。サポートおよび実際の影響は、プラットフォーム固有です。
profiles¶
profiles は、サービスが有効な状態にするための、名前付き profile のリストを定義します。設定がなければ、サービスは常に有効です。
存在する場合は、 profiles は正規表現の形式 [a-zA-Z0-9][a-zA-Z0-9_.-]+ に
pull_policy¶
pull_policy は、 Compose 実装がイメージ取得を開始する時の挙動を定義します。有効な値は次の通りです。
always：Compose 実装は、常にレジストリからイメージを取得すべき です。never：Compose 実装は、常にレジストリからイメージを取得すべきではありません 。そして、プラットフォームでキャッシュされたイメージに頼るべき です。もしもキャッシュされたイメージがなければ、失敗を報告する必要があります 。missing：Compose 実装は、プラットフォームのキャッシュからイメージを利用できない場合のみ、取得すべきです 。これは、構築をサポートしていない Compose 実装では、デフォルトのオプションとすべきです 。if_not_presentは、この値が後方互換性のための別名と考えるべきです 。build：Compose 実装がイメージを構築 すべきです 。Compose 実装は、イメージが既に存在していても再構築すべきです 。
もしも pull_policy と build の両方がある場合、 Compose 実装はデフォルトでイメージを構築
restart¶
restart は、コンテナの終了時に、プラットフォームが適用するポリシーを定義します。
no：デフォルトの再起動ポリシーです。どのような状況下でも、コンテナを再起動しません。always：コンテナを削除するまで、常に再起動するポリシーです。on-failure：コンテナの終了コードがエラーを示す場合、コンテナを再起動するポリシーです。unless-stopped：コンテナの終了コードにかかわらず再起動しますが、サービスが停止もしくは削除する場合は再起動処理を行いません。
restart: "no"
restart: always
restart: on-failure
restart: unless-stopped
runtime¶
runtime はサービス用コンテナに使うランタイムを指定します。
runtime の値は、実装を指定します。たとえば、 runtime の値には、 "runc" のような OCI ランタイム仕様（OCI Runtime Spec）を実装 する名前です。
web:
image: busybox:latest
command: true
runtime: runc
secrets¶
secrets は、サービス単位を元にする シークレット（secrets） によって定義する機微データ（
プラットフォーム上にシークレットが存在しない場合、あるいは、この Compose ファイルの secrets セクション内での定義がない場合、Compose 実装はエラーを報告する
短い形式¶
短い形式の記述では、シークレット名のみ指定します。これは、コンテナに対してシークレットに対するアクセスを許可し、コンテナ内の /run/secrets/<シークレット名> を読み込み専用としてマウントします。ソース名とマウントポイント先は、どちらもシークレット名で設定されます。
以下の例は、短い構文を使い、 frontend サービスに対して server-certificate シークレットに対するアクセスを許可します。 server-certificate の値は ./server.cert ファイルの内容を設定します。
services:
frontend:
image: awesome/webapp
secrets:
- server-certificate
secrets:
server-certificate:
file: ./server.cert
長い形式¶
長い形式は、サービスコンテナ内で作成されるシークレットをどのように作成するか、より細かく指定します。
source：プラットフォームに存在するシークレット名です。target：サービス用タスク コンテナ内の、/run/secrets/にマウントするファイル名です。uidとgid：サービス用タスク コンテナ内の、/run/secrets/内のファイルを所有する UID や GID の整数値です。mode： サービス用タスク コンテナ内の、/run/secretsにマウントするファイルの https://web.archive.org/web/20220310140126/http://permissions-calculator.org/ を8進数で指定します。もしも書き込み可能なビットが設定されても、無視する必要があります 。実行可能ビットは設定しても構いません 。
以下の例は、コンテナ内の server.crt ファイルに server-sertificate という名前のシークレットを作成します。このファイルのモードを 0440 に設定し、ユーザとグループを 103 にします。シークレット server-certificate の値には、プラットフォームを通して検索したものが提供されますので、シークレットのライフサイクルは Compose 実装によって直接管理されません。
services:
frontend:
image: awesome/webapp
secrets:
- source: server-certificate
target: server.cert
uid: "103"
gid: "103"
mode: 0440
secrets:
server-certificate:
external: true
サービスには複数のシークレットに対してアクセス権限を与えても secret 内で定義し、あらゆるサービスに許可するように
security_opt¶
security_opt は各コンテナのデフォルト
security_opt:
- label:user:USER
- label:role:ROLE
stdin_open¶
stdin_open は、サービス コンテナに標準入力を割り当てて実行するよう設定します。
stop_grace_period¶
stop_grace_period は、 Compose 実装がコンテナを停止しようとする時、 SIGTERM で処理できない場合（または、 stop_signal を停止シグナルとして指定していても）、 SIGKILL を送信する前にどれだけ待機する
stop_grace_period: 1s
stop_grace_period: 1m30s
コンテナに SIGKILL を送信して停止するまでは、デフォルトで 10 秒です。
stop_signal¶
stop_signal はシグナルを定義します。これは Compose 実装がサービス コンテナを停止するために使う SIGTERM の送信がサポートされます。
stop_signal: SIGUSR1
sysctls¶
sysctls はコンテナ内に設定する kernel パラメータを定義します。 sysctls は配列形式かマップ形式のどちらかを使えます。
sysctls:
net.core.somaxconn: 1024
net.ipv4.tcp_syncookies: 0
sysctls:
- net.core.somaxconn=1024
- net.ipv4.tcp_syncookies=0
sysctls が使えるのは kernel 内の
ulimits¶
ulimits はコンテナのデフォルト ulimits を上書きします。単一の
ulimits:
nproc: 65535
nofile:
soft: 20000
hard: 40000
user¶
user は、コンテナのプロセスを実行するために使うユーザを上書きします。デフォルトはイメージで指定されたもの（例： Dockerfile の USER ）が使われますが、設定が無ければ root です。
userns_mode¶
userns_mode はサービスに対するユーザ名前空間を設定します。サポートしている値はプラットフォーム固有であり、プラットフォームの設定に依存する
userns_mode: "host"
volumes¶
volumes は、サービス コンテナがアクセスできるようにする
マウントがホスト上のパスで、かつ、単一の値の場合は、サービス定義の一部ではなくトップレベルの volume キーで宣言しても
複数のコンテナを横断してボリュームを再利用するには、 トップレベルの「volumes」キー 内で名前付きボリュームを宣言する
この例が表すのは、 backend サービスによって使われる名前付きボリューム（ db-data ）と、この1つのサービスに対する
services:
backend:
image: awesome/backend
volumes:
- type: volume
source: db-data
target: /data
volume:
nocopy: true
- type: bind
source: /var/run/postgres/postgres.sock
target: /var/run/postgres/postgres.sock
volumes:
db-data:
短い形式¶
短い形式は、コロン区切りの値を持つ単一文字列を使い、ボリュームマウント（ VOLUME:CONTAINER_PASS ）や、アクセスモード（VOLUME:CONTAINER_PATH:ACCESS_MODE） を指定します。
VOLUME：コンテナをホスティングするプラットフォーム上のホストパス（バインド マウント）かボリューム名のどちらかを指定できます CONTAINER_PATH：ボリュームがマウントされるコンテナ内のパスACCESS_MODE：これはコンマ記号,で区切られたリストで、次の値が設定できます ：rw：読み込み と書き込み のアクセス（デフォルト）ro：読み込み専用 のアクセスz：SELinux オプションを示すもので、バインド マウントするホストの内容が、複数のコンテナ間で共有するZ：SELinux オプションを示すもので、バインド マウントするホストの内容がプライベートであり、他のコンテナとは共有しない
注釈
SELinux の
注釈
相対ホスト パスが Compose 実装によってサポートする . や .. で
長い形式¶
長い形式の構文は、短い形式では表現できない追加フィールドの設定を行えるようにします。
type：マウントの型 でvolume、bind、tmpfs、npineです。source：マウント元で、バインドマウントするホスト上のパスか、 トップレベル「volumes」キー で定義されるボリュームの名前です。target：ボリュームがマウントされるコンテナ内のパスです。read_only：ボリュームを読み込み専用に設定するフラグです。bind：追加のバインド オプションを設定します。propagation：バインドに伝搬モード を使います。create_host_path：何も指定がなければ、ホスト上のソースパスにディレクトリを作成します。パス上に同様のパスが存在している場合は、何もしません。これは、過去の docker-compose との後方互換正のため、短い構文では自動的に処理されます。selinux： SELinux の再ラベル オプションz（共有）かZ（プライベート）を指定します。
volume：追加のボリューム オプションを設定します。nocopy：ボリュームを作成する場合、コンテナからのデータのコピーを無効化するフラグです。
tmpfs：追加の tmpfs オプションを指定します。size：tmpfs マウント用の容量をバイトで（整数値またはバイト単位として）指定します。
consistency：マウントには一貫性 を必要とします。利用可能な値は、プラットフォームに固有のものです。
volumes_from¶
volumes_from は、他のサービスやコンテナから全てのボリュームをマウントします。オプションで読み込み専用のアクセス（ro）や読み書き（rw）を指定します。アクセスレベルの指定が無ければ、読み書きを使う
文字列の値には、 Compose アプリケーション モデル内にある別のサービスを定義します。 container: プレフィクスをサポートする場合、コンテナからのボリュームをマウントできるようにしますが、 Compose 実装によっては管理されません。
volumes_from:
- service_name
- service_name:ro
- container:container_name
- container:container_name:rw
working_dir¶
working_dir は、イメージで定義（例： Dockerfile の WORKDIR ）されたコンテナ用の
networks トップレベル 要素 ¶
networks （ネットワーク）はサービスが相互に通信できるようにするためのレイヤです。サービスに対して公開するネットワーク機能モデルとは、対象サービスと外部リソース間でのシンプルな IP 接続に限定されます。ただし、ネットワーク定義により、プラットフォームが提供する実際の実装を微調整できます。
トップレベルの networks セクション下でネットワーク名を定義すると、ネットワークが作成されます。サービスの networks サブセクションで指定されたネットワークにも、サービスは接続できます。
以下の例では、実行時にネットワーク front-tier と back-tier が作成され、それから forntend サービスは front-tier ネットワークと back-tier ネットワークに接続します。
services:
frontend:
image: awesome/webapp
networks:
- front-tier
- back-tier
networks:
front-tier:
back-tier:
driver¶
driver は、このネットワークに使うべきドライバを指定します。 Compose 実装はプラットフォーム上でドライバが利用できなければ、エラーを返す
driver: overlay
デフォルトかつ利用可能なボリュームは、プラットフォーム固有です。 Compose 仕様は、以下のドライバ none と host を指定するようにサポートする
hostはホスト側のネットワーク スタックを使用noneはネットワーク無効化
host や none¶
host と none では、内蔵ネットワークを扱う構文は異なります。これらネットワークは、暗黙的に Compose 実装の範囲外となるためです。これらのうち1つを使う場合、 host か name で外部ネットワークと
services:
web:
networks:
hostnet: {}
networks:
hostnet:
external: true
name: host
services:
web:
...
networks:
nonet: {}
networks:
nonet:
external: true
name: none
driver_opts¶
driver_opts は、このネットワーク用ドライバに渡すオプションのリストを、キーバリューの組み合わせで定義します。このオプションはドリア場に依存します。そのため、詳細情報はドライバのドキュメントをご確認ください。これはオプションの項目です。
driver_opts:
foo: "bar"
baz: 1
attachable¶
attachable を true に設定すると、スタンドアロン コンテナはサービスに加え、このネットワークに
networks:
mynet1:
driver: overlay
attachable: true
enable_ipv6¶
enable_ipv6 は、このネットワーク上で IPv6 ネットワーク機能を有効化します。
ipam¶
ipam は任意の IPAM 設定を指定します。これには複数の属性を持つオブジェクトがありますが、どれもオプションです。
driver：デフォルトに替わる、任意の IPAM ドライバです。config：ゼロ、もしくは、次の内容を含む複数の設定要素のリストです。subnet：ネットワークセグメントを表す CIDR 形式のサブネットip_range：コンテナに割り当て可能な IP アドレスの範囲gateway：マスタサブネットのための IPv4 または IPv6 ゲートウエイaux_addresses：ネットワーク ドライバによって使われる外部の IPv4 または IPv6 アドレスで、ホスト名から IP アドレスにマッピングする
options：ドライバ固有のオプションをキーバリューのマップとして指定
完全な例です：
ipam:
driver: default
config:
- subnet: 172.28.0.0/16
ip_range: 172.28.5.0/24
gateway: 172.28.5.254
aux_addresses:
host1: 172.28.1.5
host2: 172.28.1.6
host3: 172.28.1.7
options:
foo: bar
baz: "0"
internal¶
デフォルトでは、 Compose 仕様はネットワークに対する外部への接続性を提供する internal を true に設定する場合は、外部の
labels¶
ラベルを使ってコンテナにメタデータを追加します。配列形式もしくは辞書形式のどちらかを利用できます。
他のソフトウェアが使っているラベルとの重複を防ぐため、ユーザは逆引き DNS 記法を
labels:
com.example.description: "Financial transaction network"
com.example.department: "Finance"
com.example.label-with-empty-value: ""
labels:
- "com.example.description=Financial transaction network"
- "com.example.department=Finance"
- "com.example.label-with-empty-value"
Compose 実装はラベル com.docker.compose.project と com.docker.compose.network を指定する
external¶
external を true に設定した場合、このネットワークのライフサイクルは、対象アプリケーションの外で管理されます。Compose 実装はこれらネットワークを作成しようと
以下の例では、 proxy は外の世界へのゲートウェイです。ネットワークの作成を試みるのではなく、 Compose 実装はプラットフォームに対して outside という名前で既存ネットワークに存在しているかどうかを単純に尋ね、 proxy サービスのコンテナがそこに接続できるようにします。
services:
proxy:
image: awesome/proxy
networks:
- outside
- default
app:
image: awesome/app
networks:
- default
networks:
outside:
external: true
name¶
name は、このネットワークに対して任意の名前を設定します。name フィールドは、特別な文字を含むネットワークの参照にも使えます。この名前はそのまま使われるだけであり、プロジェクト名の範囲では使われ ません 。
networks:
network1:
name: my-app-net
プラットフォームのネットワークを定義するため、 external 属性と組み合わせての利用も可能です。これは、 Compose 実装では、 Compose がランタイム固有の値を
networks:
network1:
external: true
name: "${NETWORK_ID}"
volumes トップレベル 要素 ¶
ボリューム（ volumes ）とはプラットフォームによって実装される
volumes セクションは、複数のサービスを横断して再利用できる db-data という名前のボリュームとして他のサービスから共有されます。そのため、バックアップ用途にも使えるでしょう。
services:
backend:
image: awesome/database
volumes:
- db-data:/etc/data
backup:
image: backup-service
volumes:
- db-data:/var/lib/backup/data
volumes:
db-data:
トップレベルの volumes キー以下のエントリは空っぽにできます。ボリュームの作成にあたり、プラットフォームのデフォルト設定を使う場合に、そのようにします。オプションで、以下のキーを使って設定できます。
driver¶
このボリュームが使うべきボリュームドライバを指定します。デフォルトの値や利用可能な値は、プラットフォーム固有です。ドライバが利用できない場合は、 Compose 実装はエラーを返してアプリケーションのデプロイを中止する
driver: foobar
driver_opts¶
driver_opts は、このボリュームのドライバに渡すオプションのリストを、キーバリューの組み合わせで指定します。それぞれのオプションは、ドライバに依存します。
volumes:
example:
driver_opts:
type: "nfs"
o: "addr=10.40.0.199,nolock,soft,rw"
device: ":/docker/example"
external¶
external を true に設定した場合、このボリュームのライフサイクルは、対象アプリケーションの外で管理されます。Compose 実装はこれらボリュームを作成
以下の例では、 {project_name}_db-data という名前のボリューム作成を試みるのではなく、 Compose はシンプルに db-data という名前の既存ボリュームを探し、それを backend サービスのコンテナにマウントします。
services:
backend:
image: awesome/database
volumes:
- db-data:/etc/data
volumes:
db-data:
external: true
labels¶
ラベルはボリュームにメタデータを追加するために使います。配列形式もしくは辞書形式のどちらかを利用できます。
他のソフトウェアが使っているラベルとの重複を防ぐため、ユーザは逆引き DNS 記法を
labels:
com.example.description: "Database volume"
com.example.department: "IT/Ops"
com.example.label-with-empty-value: ""
labels:
- "com.example.description=Database volume"
- "com.example.department=IT/Ops"
- "com.example.label-with-empty-value"
Compose 実装はラベル com.docker.compose.project と com.docker.compose.network を指定する
name¶
name は、このボリュームに対して任意の名前を設定します。name フィールドは、特別な文字を含むボリュームの参照にも使えます。この名前はそのまま使われるだけであり、スタック名の範囲では使われ ません 。
volumes:
data:
name: "my-app-data"
external 属性と組み合わせての利用も可能です。この場合、プラットフォーム上で実際のボリュームを探すためのボリューム名は、Compose ファイル内で参照するための名前とは別に設定されます。
volumes:
db-data:
external:
name: actual-name-of-volume
次のようにすると、 Compose ファイルのパラメータで名前を探せるようになるため、ボリューム用のモデル ID を
volumes:
db-data:
external:
name: ${DATABASE_VOLUME}
configs トップレベル 要素 ¶
設定情報（ configs ）によって、 サービスに対して挙動を適用するにあたり、Docker イメージの再構築を不要にします。 configs はサービス用コンテナのファイルシステムへマウントされるため、サービスの観点からはボリュームに相当します。プラットフォームから取得する実際の実装詳細は、この設定情報の定義で設定できます。
設定情報にアクセスを許可すると、設定情報の内容が、コンテナ内ではファイルとしてマウントされます。コンテナ内のマウントポイントの場所は、 Linux コンテナでのデフォルトは </config-name> であり、 Windows コンテナーの場合は C:\<config-name> です。
デフォルトでは、設定情報はコンテナのコマンドを実行するユーザによって所有される
configs のサブセクションで、サービスがアクセスできる設定情報を明示的に許可できます。
トップレベルの configs 宣言による定義や参照される設定情報データは、このアプリケーションの（他の）サービス上からも参照できるようになります。設定情報の元になるのは file か external です。
file：指定されたパスにあるファイルの内容から、設定情報を作成します。external：設定情報が既に作成されている場合、設定を true にして指定します。Compose 実装は作成を試みません。また、存在しなければエラーを起こします。name：プラットフォームで探す設定情報の名前です。このフィールドは特別な文字を含む設定情報も参照できます。名前はそのまま使いますが、プロジェクト名の範囲外では使われ ません 。
この例では、アプリケーションのデプロイ時に http_config が <project_name>_http_config として作成されます。そして my_second_config は既存のプラットフォーム上に存在し、その値を探して得られる
この例では、アプリケーションのデプロイ時に server-http_config が（ <project_name>_http_config として）作成されます。このとき、 httpd.conf の内容は設定情報のデータ内容が登録されます。
configs:
http_config:
file: ./httpd.conf
あるいは、 httpd_config は外部（external）としての宣言もできます。そのような場合、 Compose 実装は対象サービスで公開されている設定情報データから http_config を探します。
configs:
http_config:
external: true
外部設定を探すにあたり、明確にキーを name で指定しての利用もできます。以下の例は先の例を編集したもので、パラメータ HTTP_CONFIG_KEY の設定を探します。そのため、デプロイ時に変数が 展開 されたものが設定されますが、 http_config としてコンテナに公開されます。
configs:
http_config:
external: true
name: "${HTTP_CONFIG_KEY}"
Compose ファイルでは、アプリケーション内の関連するサービスに対しては、設定情報に明示的な許可が必要です。
secrets トップレベル 要素 ¶
シークレット（ secrets ）は
トップレベルの secrets 宣言による定義や参照される設定情報データは、このアプリケーションの（他の）サービス上からも参照できるようになります。設定情報の元になるのは file か external です。
file：指定されたパスにあるファイルの内容から、シークレットを作成します。external：シークレットが既に作成されている場合、設定を true にして指定します。Compose 実装は作成を試みません。また、存在しなければエラーを起こします。name：プラットフォームで探すシークレットの名前です。このフィールドは特別な文字を含むシークレットも参照できます。名前はそのまま使いますが、プロジェクト名の範囲外では使われ ません 。
この例では、アプリケーションのデプロイ時に server-certificate が <project_name>_server-certificate として作成されます。このとき、 server.cert の内容にはプラットフォームのシークレットが登録されます。
secrets:
server-certificate:
file: ./server.cert
あるいは、 server-certificate は外部（external）としての宣言もできます。そのような場合、 Compose 実装は対象サービスで公開されているシークレットから server-certificate を探します。
secrets:
server-certificate:
external: true
外部のシークレットを探すにあたり、明確にキーを name で指定しての利用もできます。以下の例は先の例を編集したもので、パラメータ CERTIFICATE_KEY の設定を探します。そのため、デプロイ時に変数が 展開 されたものが設定されますが、 server-certificate としてコンテナに公開されます。
secrets:
server-certificate:
external: true
name: "${CERTIFICATE_KEY}"
Compose ファイルでは、アプリケーション内の関連するサービスに対しては、シークレットに明示的な許可が必要です。
フラグメント ¶
設定のフラグメントを YAML アンカー を使って再利用できます。
volumes:
db-data: &default-volume
driver: default
metrics: *default-volume
先述の例では、 db-data ボリューム指定をもとに default-volume としての「 *default-volume としてボリュームの metrics を定義するため再利用されます。同じ仕組みを Compose ファイルの他の要素にも適用できます。アンカーの指定は 変数展開 前に行う必要があるため、変数を使ったアンカーや別名の指定は行えません。
また、 YAML merge タイプ を使うアンカー参照を指定し、部分的に上書きできます。以下の例は metrics ボリューム指定を別名で再利用できませんが、 name 属性を上書きします。
services:
backend:
image: awesome/database
volumes:
- db-data
- metrics
volumes:
db-data: &default-volume
driver: default
name: "data"
metrics:
<<: *default-volume
name: "metrics"
拡張 ¶
特別な拡張フィールドは、名前が x- で始まる文字列であれば、どのような形式にも対応します。Compose ファイル内で、あらゆる構造が利用できます。以下の例は、 Compose 実装が認識できないフィールドを、警告なく無視する唯一の例外です。
x-custom:
foo:
- bar
- zot
services:
webapp:
image: awesome/webapp
x-foo: bar
このようなフィールドの内容は Compose 仕様では明示されていないため、任意の機能のために利用できます。 Compose 実装は未知の拡張フィールドを発見した場合、失敗
プラットフォームを拡張するには、プラットフォームやベンダによって提供されている拡張プレフィックスの利用を推奨します。これは、ブラウザに対して 任意の CSS 機能 のサポートを追加するのと同じです。
service:
backend:
deploy:
placement:
x-aws-role: "arn:aws:iam::XXXXXXXXXXXX:role/foo"
x-aws-region: "eu-west-3"
x-azure-region: "france-central"
参考となる履歴情報¶
このセクションは参考情報です。これを書いている時点で、以下プレフィクスの存在が分かっています。
プレフィクス |
ベンダー/組織 |
|---|---|
docker |
Docker |
kubernetes |
Kubernetes |
フラグメントとして拡張を使う¶
拡張フィールドをサポートするため、 Compose ファイルを次のように書き、再利用するフラグメントを読みやすく改善できます。
x-logging: &default-logging
options:
max-size: "12m"
max-file: "5"
driver: json-file
services:
frontend:
image: awesome/webapp
logging: *default-logging
backend:
image: awesome/database
logging: *default-logging
変数展開（補完）¶
Compsoe ファイルの値には変数を設定でき、実行時に変数展開できます。 Compose ファイルは Bash 風の構文 ${変数} を使います。
$変数 と ${変数} の両構文をサポートしています。デフォルトの値は、一般的なシェル構文を使い、その途中で記号を使い定義できます。
${変数:-default}は変数が環境変数内で未定義もしくは空白の場合にdefaultと評価します。${変数:+default}は変数が環境変数内で未定義の場合のみ、defaultと評価します。
同じように、以下の構文によって変数の強制を指定できます。
${変数:?err}は、変数が環境変数内で未定義か空白の場合、errを含むエラーメッセージと共に終了します。${変数?err}は、変数が環境変数内で未定義の場合のみ、errを含むエラーメッセージと共に終了します。
${変数/foo/bar} のような他のシェル風の拡張機能は Compose 仕様ではサポートされていません。
設定で文字列としてのドル記号を使う必要がある場合は、 $$ （二重ドル記号）を使います。また、 $$ は Compose によって値が変数展開されるのを防ぐため、Compose によって処理したくない環境変数の参照にも使えます。
web:
build: .
command: "$$VAR_NOT_INTERPOLATED_BY_COMPOSE"
Compose 仕様が変数展開を解決できず、かつ、デフォルト値が無い場合は、ユーザに対して警告を表示し、展開する変数を空白の文字列とする
Compose ファイル中のあらゆる値は、変数展開によって補完できます。複雑な要素を短くする表記を含めて、（複数の）ファイル単位を統合する前に補完を