Compose ファイル version 2 リファレンス¶
Compose と Docker の互換表¶
Compose ファイル形式には、1 、 2 、 2.x 、 3.x のように複数のバージョンがあります。下にある表をちらっと見てみましょう。各バージョンの詳細についてや、アップグレードの仕方については、 Compose ファイルのバージョンとアップグレード をご覧ください。
この表は、各 Compose ファイル形式を、どの Docker リリースでサポートしているかを表します。
Compose ファイル形式 |
Docker Engine リリース |
|---|---|
Compose 仕様 |
19.03.0+ |
3.8 |
19.03.0+ |
3.7 |
18.06.0+ |
3.6 |
18.02.0+ |
3.5 |
17.12.0+ |
3.4 |
17.09.0+ |
3.3 |
17.06.0+ |
3.2 |
17.04.0+ |
3.1 |
1.13.1+ |
3.0 |
1.13.0+ |
2.4 |
17.12.0+ |
2.3 |
17.06.0+ |
2.2 |
1.13.0+ |
2.1 |
1.12.0+ |
2.0 |
1.10.0+ |
先ほどの表中にある Compose ファイル形式のバージョンに加え、Compose 自身も Compose リリースのページ にリリース情報の一覧があります。しかし、ファイル形式のバージョンは、各リリースごとに増えていません。たとえば、Compose ファイル形式 3.0 が始めて導入されたのは、 Compose リリース 1.10.0 からであり、以降はリリースに従って順々とバージョンが割り当てられています。
最新の Compose ファイル形式は `Compose 仕様`_ で定義されており、 Docker Compose 1.27.0 以上 から実装されています。
サービス設定リファレンス¶
Compose ファイルは YAML ファイルであり、 サービス（services） 、 ネットワーク（networks） 、 ボリューム（volumes） を定義します。Compose ファイルのデフォルトのパスは ./docker-compose.yml です。
Tip
このファイルは .yml か .yaml いずれか一方の拡張子を利用できます。どちらも機能します。
サービスの定義に入るのは、コマンドラインで docker run にパラメータを渡すのと同じように、サービスとして起動するコンテナに対して適用する設定です。同様に、ネットワークやボリュームの定義も docker network create や docker volume create と似ています。
docker run と同様に、 Dockerfile で指定した CMD 、 EXPOSE 、 VOLUME 、ENV のようなオプションが、デフォルト（の設定値）として尊重されます。そのため、 docker-compose.yml で再び指定する必要はありません。
Bash のような ${変数名} の構文を使い、環境変数を設定値として使用できます。詳しくは 変数の置き換え をご覧ください。
このセクションでは、（Docker Compose）バージョン2のサービス定義用にサポートされている、設定オプションの一覧を扱います。
blkio_config¶
対象のサービスに対し、
version: "2.4"
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_device¶
デバイスに割り当てる帯域を微調整します。記載する項目ごとに、2つキーが必要です。
path、対象となるデバイスを示す（ファイルシステム上に見える）パス を定義weight、値は 10 から 1000 までの整数
build¶
build では
version: "2.4"
services:
webapp:
build: ./dir
または、 context 配下のパスにある特定の（ファイルやディレクトリなどの）物（オブジェクト）と、 Dockerfile のオプションと 引数 を指定できます。
version: "2.4"
services:
webapp:
build:
context: ./dir
dockerfile: Dockerfile-alternate
args:
buildno: 1
build と同様に image （Docker イメージ）も指定する場合、 image の場所で指定された webapp とオプションの tag を使い、 Docker Compose が構築されるイメージに名前を付けます。
build: ./dir
image: webapp:tag
つまり、 ./ 以下から webapp という名前と tag というタグ名を持つイメージができます。
context¶
ヒント
Compose 形式 バージョン 2 で追加されました。
Dockerfile を含むディレクトリのパス、あるいは、git リポジトリへの URL を指定します。
相対パスとして値を指定すると、 Compose ファイルがある場所を基準とした相対パスとして解釈されます。また、そのディレクトリが構築コンテキストとなり、その内容が Docker デーモンに対して送られます。
Compose は作成時の名前を使ってイメージ構築やタグ付けをし、以降は、そのイメージを使います。
build:
context: ./dir
dockerfile¶
別の Dockerfile を指定します。
Compose は別の Dockerfile ファイルを使い構築します。
build:
context: .
dockerfile: Dockerfile-alternate
args¶
ヒント
Compose 形式 バージョン 2 で追加されました。
build の
まずはじめに、 Dockerfile 内で引数を指定しておきます。
# syntax=docker/dockerfile:1
ARG buildno
ARG gitcommithash
RUN echo "Build number: $buildno"
RUN echo "Based on commit: $gitcommithash"
そして、 build キーの下で引数を指定します。
build:
context: .
args:
buildno: 1
gitcommithash: cdc3b19
build:
context: .
args:
- buildno=1
- gitcommithash=cdc3b19
注釈
buildにおけるargの範囲
Dockerfile で、 FROM 命令の前に ARG 命令を指定すると、 FROM 命令以下の構築処理で ARG を利用できなくなります。もし両方で使いたい場合には、 FROM 命令の下でも指定する必要があります。使い方の詳細についてのドキュメントは ARG と FROM の相互作用を理解 を参照ください。
biuld 引数に対して値を指定しない場合は、Compose を実行時、環境変数の値が構築時の値として使用されます。
args:
- buildno
- gitcommithash
Tip
ブール値を使う場合
YAML の "true" , "false" , "yes" , "no" , "on" , "off" ）は、引用符で囲む必要があり、そうするとパーサは文字列としてそれらを解釈します。
cache_from¶
ヒント
Compose 形式 バージョン 2.2 で追加されました。
Engine がキャッシュの解決に使うイメージの一覧。
build:
context: .
cache_from:
- alpine:latest
- corp/web_app:3.14
extra_hosts¶
構築時に割り当てる（マッピングする）ホスト名を追加します。docker クライアントで --add-host パラメータを追加するのと同じ働きをします。
extra_hosts:
- "somehost:162.242.195.82"
- "otherhost:50.31.209.229"
次のように、構築時にコンテナ内の /etc/hosts にIP アドレスとホスト名の項目が作成されます。
162.242.195.82 somehost
50.31.209.229 otherhost
isolation¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
構築時のコンテナ default です。Windows では default 、 process 、hyperv を指定できます。詳細は Docker Engine のドキュメント をご覧ください。
指定が無い場合、 Compose が構築に使う値の決定には、サービスの定義で見つかった isolation 値を使います。
labels¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
Docker ラベル を使い、結果として作成されるイメージにメタデータを追加します。
指定するラベルが他のソフトウェアで使われているものと重複を避けるには、
build:
context: .
labels:
com.example.description: "Accounting webapp"
com.example.department: "Finance"
com.example.label-with-empty-value: ""
build:
context: .
labels:
- "com.example.description=Accounting webapp"
- "com.example.department=Finance"
- "com.example.label-with-empty-value"
network¶
ヒント
Compose 形式 バージョン 2.2 で追加されました。
RUN 命令で構築中に、コンテナが接続するネットワークを指定します。
build:
context: .
network: host
build:
context: .
network: custom_network_1
none の指定は、構築中にネットワーク機能を無効化します。
build:
context: .
network: none
cap_add, cap_drop¶
コンテナの man 7 capabilities をご覧ください。
cap_add:
- ALL
cap_drop:
- NET_ADMIN
- SYS_ADMIN
command¶
デフォルトの
command: bundle exec thin -p 3000
コマンドは、 Dockerfile と同じようにリスト形式にもできます。
command: [bundle, exec, thin, -p, 3000]
container_name¶
自動作成されるコンテナ名ではなく、任意のコンテナ名を指定します。
container_name: my-web-container
Docker コンテナ名は重複できません。そのため、任意のコンテナ名を指定した場合、サービスは複数のコンテナにスケールできなくなります。
cpu_rt_runtime、 cpu_rt_period¶
ヒント
Compose 形式 バージョン 2.2 で追加されました。
Docker デーモンのリアルタイム・スケジューラが使う CPU 割り当てパラメータを設定します。
cpu_rt_runtime: '400ms'
cpu_rt_period: '1400us'
整数の単位はマイクロ秒を使います。
cpu_rt_runtime: 95000
cpu_rt_period: 11000
device_cgroup_rules¶
ヒント
Compose 形式 バージョン 2.3 で追加されました。
cgroup が
device_cgroup_rules:
- 'c 1:3 mr'
- 'a 7:* rmw'
devices¶
--device と同じ形式を使います。
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"
depends_on¶
ヒント
Compose 形式 バージョン 2.0 で追加されました。
サービス間の
docker-compose upを実行すると、依存関係の順番に従いサービスを起動 します。以下の例では、webを起動する前にdbとredisを起動します。docker-compose up サービス名を実行すると、自動的にサービス名と依存関係のあるサービスも起動します。以下の例では、docker-compose up webによって、dbとredサービスも作成・起動します。docker-compose stopは、依存関係の順番に従いサービスを停止 します。以下の例では、dbとredisの前にwebを停止します。
簡単な例：
version: "2.4"
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres
注釈
depends_on では、 web が起動する前に db と redis が「
ヒント
Compose 形式 バージョン 2.1compose-file-version-21> で追加されました。
例：
version: "2.4"
services:
web:
build: .
depends_on:
db:
condition: service_healthy
redis:
condition: service_started
redis:
image: redis
db:
image: postgres
healthcheck:
test: "exit 0"
上の例では、 Compose は redis サービスが db サービスが web を起動します。
補足情報については、 healchechek セクション をご覧ください。
dns_search¶
任意のDNS 検索ドメインを変更します。単一の値、もしくはリストになります。
dns_search: example.com
dns_search:
- dc1.example.com
- dc2.example.com
entrypoint¶
デフォルトの entrypoint を上書きします。
entrypoint: /code/entrypoint.sh
entrypoint は Dockerfile と同様にリストにもできます。
entrypoint: ["php", "-d", "memory_limit=-1", "vendor/bin/phpunit"]
注釈
サービス用のイメージが Dockerfile で ENTRYPOINT 命令を持っていたとしても、 entrypoint はすべてのデフォルトの entrypoint 設定を上書きします。さらに、イメージ上のデフォルトのコマンドもクリアします。つまり、 Dockerifle 上のに CMD 命令は無視されます。
env_file¶
ファイル上の定義から環境変数を追加します。単一の値、もしくはリストになります。
Compose ファイルを docker-compose -f ファイル名 で指定する場合は、 env_file ファイルは指定したディレクトリに対する相対パスにあるとみなします。
environment でセクションで宣言された環境変数は、これらの値で上書きされます。つまり、値が保持されるのは、それぞれの値が空白もしくは未定義の場合です。
env_file: .env
env_file:
- ./common.env
- ./apps/web.env
- /opt/secrets.env
Compose は各行が VAR=VAL （変数=値）の形式と想定します。 # で始まる行はコメントとして無視します。また、空白行も無視します。
# Rails/Rack 環境変数を設定
RACK_ENV=development
注釈
サービスに biuld オプションを指定している場合、環境変数用ファイルで定義された変数は、構築中に自動で見えるようになりません。構築時の環境変数として定義するには、 build の args サブオプションを使います。
VAL の値は、一切変更されることなく、そのまま使われます。たとえば、値がクォートで囲まれていた場合（シェル変数でよくあります）、クォートも値としてそのまま Compose に渡されます。
「繰り返し現れる変数に対し、割り当てる値を決定するために、リスト内でのファイル順番が重要」なのを忘れないでください。リスト内のファイルは、上から下に処理されます。もしも a.env ファイルで指定された変数と、同じ変数が b.env ファイルにあっても、違う値が割り当てられた場合には、 b.env がリストの下（後方）にあるため、 b.env の値が有効になります。たとえば、以下のような docker-compose.yml が宣言されたとします。
services:
some-service:
env_file:
- a.env
- b.env
それぞれのファイルは、
# a.env
VAR=1
こちらと、
# b.env
VAR=hello
このような場合、 $VAR の値は hello になります。
environment¶
環境変数を追加します。配列もしくは
キーだけの環境変数は、Compose の実行時にマシン上で指定するものであり、 :ruby:`シークレット <secret>`（訳注：API鍵などの秘密情報）やホスト固有の値を指定するのに便利です。
environment:
RACK_ENV: development
SHOW: 'true'
SESSION_SECRET:
environment:
- RACK_ENV=development
- SHOW=true
- SESSION_SECRET
expose¶
コンテナの
expose:
- "3000"
- "8000"
extends¶
現在のファイルから別のファイルにサービスを拡張するもので、設定のオプションを追加します。
他の設定用のキーと一緒にサービスを extends （拡張）できます。 extends 値には service の定義が必要であり、オプションで file キーを指定します。
extends:
file: common.yml
service: webapp
service とは、 web や database などです。 file は対象のサービスを定義する Compose 設定ファイルの場所です。
file を省略したら、Compose は現在の設定ファイル上からサービスの定義を探します。 file の値は相対パスまたは絶対パスです。相対パスを指定したら、Compose はその場所を、現在のファイルからの相対パスとして扱います。
サービス自身が、他に対して拡張するサービス定義をできます。拡張は無限に可能です。Compose は循環参照をサポートしておらず、もし循環参照があれば docker-compose はエラーを返します。
extends に関するより詳細は、 extends ドキュメント をご覧ください。
external_links¶
対象の docker-compose.yml の外にあるコンテナだけでなく、Compose の外にあるコンテナとリンクします。特に、コンテナが共有サービスもしくは一般的なサービスを提供している場合に有用です。 external_links でコンテナ名とエイリアスを指定すると（ コンテナ名:エイリアス名 ）、古い（レガシー）オプション link のように動作します。
external_links:
- redis_1
- project_db_1:mysql
- project_db_1:postgresql
注釈
バージョン２のファイル形式 を使う場合、外部に作成したコンテナと接続する必要があれば、接続先のサービスが対象ネットワーク上に少なくとも１つ接続する必要があります。 links は古いオプションです。そのかわりに、 networks の使用を推奨します。
extra_hosts¶
ホスト名を割り当てます（マッピングします）。これは docker クライアントで --add-host パラメータを使うのと同じ値です。
extra_hosts:
- "somehost:162.242.195.82"
- "otherhost:50.31.209.229"
コンテナ内の /etc/hosts に、 IP アドレスとホスト名のエントリが追加されます。例：
162.242.195.82 somehost
50.31.209.229 otherhost
group_add¶
コンテナ内のユーザが所属する可能性のある、追加グループ（名前または番号）を指定します。コンテナ内と追加するホストシステム上の両方で、対象のグループが存在している必要があります。これが役立つ例は、（異なるユーザで動作する）複数のコンテナが、ホストシステム上にある同じファイルを読み書きする場合です。対象ファイルは、すべてのコンテナで共有されるグループで所有でき、そのために group_add で指定します。詳細については Docker のドキュメント をご覧ください。
完全な例：
version: "2.4"
services:
myservice:
image: alpine
group_add:
- mail
作成されたコンテナ内で id （コマンドを）実行すると、対象ユーザが mail グループに所属していると表示されます。これは、 group_add を指定しなかった場合の挙動と異なります。
healthcheck¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
このサービスのコンテナが「
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 1m30s
timeout: 10s
retries: 3
start_period: 40s
interval 、 timeout 、 start_period は 継続時間 として指定します。
ヒント
start_period オプションは、Compose 形式 バージョン 2.3 で追加されました。
test は文字列またはリスト形式のどちらかの必要があります。リスト形式の場合、１番目のアイテムは NONE か CMD か CMD-SHELL のどちらかの必要があります。文字列の場合は、 CMD-SHELL に続けて文字列をを指定するのと同じです。
# ローカルの web アプリを叩く
test: ["CMD", "curl", "-f", "http://localhost"]
前述したのは /bin/sh でラッピングされています。以下の２つは同じです。
test: ["CMD-SHELL", "curl -f http://localhost || exit 1"]
test: curl -f https://localhost || exit 1
対象のイメージで設定されているデフォルトのヘルスチェックを無効化するには、 disable: true を使えます。これは test: ["NONE"] を指定するのと同じです。
healthcheck:
disable: true
image¶
コンテナの実行時、元になるイメージを指定します。リポジトリ名/タグ、あるいはイメージ ID の一部を（前方一致で）指定できます。
image: redis
image: ubuntu:18.04
image: tutum/influxdb
image: example-registry.com:4000/postgresql
image: a4bc65fd
イメージが存在していなければ、Compose は pull （取得）を試みます。しかし build を指定している場合は除きます。その場合、指定されたオプションやタグを使って構築します。
init¶
ヒント
Compose 形式 バージョン 2.2 で追加されました。
コンテナ内で init を実行し、シグナルの転送と、プロセス true を指定します。
version: "2.4"
services:
web:
image: alpine:latest
init: true
isolation¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
コンテナの default です。Windows specify-isolation-technology-for-container-isolation用では、 default 、 process 、 hyperv が指定できます。詳細は、 Docker Engine ドキュメント をご覧ください。
labels¶
Docker ラベル を使い、コンテナに
他のソフトウェアが使うラベルと競合しないようにするため、
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"
links¶
コンテナを他のサービスと "SERVICE:ALIAS" ）か、サービス名だけです。
ヒント
liks はレガシーのオプションです。代わりに networks の利用を推奨します。
links:
- db
- db:database
- redis
リンクするサービスのコンテナは、エイリアスとして認識できるホスト名で到達（接続）可能になります。エイリアスが指定されなければ、サービス名で到達できます。
サービス間で通信するため、links を有効にする必要はありません。デフォルトでは、あらゆるサービスが他のサービスにサービス名で接続できます。（ Compose ネットワーク機能における links のトピック をご覧ください）
また、 links は depends_on と同じ方法でサービス間の依存関係表すため、サービスの起動順番を指定できます。
logging¶
サービスに対して
logging:
driver: syslog
options:
syslog-address: "tcp://192.168.0.42:123"
driver にはサービス用のコンテナで使う --log-driver オプションと同じです （ ドキュメントはこちら ）。
デフォルトの値は json-file です。
driver: "json-file"
driver: "syslog"
driver: "none"
注釈
docker-compose up で立ち上げてから docker-compose logs コマンドを使い、ログを表示できるのは json-file と journald ドライバを指定した時のみです。他のドライバを指定しても、ログは何ら表示されません。
ロギング・ドライバのオプションを指定するには options キーを使います。これは docker run コマンド実行時の --log-opt オプションと同じです。
ロギングのオプションはキーバリューのペアです。以下は syslog オプションを指定する例です。
driver: "syslog"
options:
syslog-address: "tcp://192.168.0.42:123"
network_mode¶
ヒント
ファイル形式 バージョン 2 で変更されました。
ネットワークの動作モードを指定します。 docker クライアントで --network パラメータを指定する時と同じように使うには、 service:[サービス名] という特別な形式を加えます。
network_mode: "bridge"
network_mode: "host"
network_mode: "none"
network_mode: "service:[サービス名]"
network_mode: "container:[コンテナ名/id]"
networks¶
ヒント
ファイル形式 バージョン 2 で変更されました。
ネットワークに追加するには、トップレベルの networks キー の項目をご覧ください。
services:
some-service:
networks:
- some-network
- other-network
aliases¶
aliases が適用されるのは
注釈
複数のコンテナだけでなく複数のサービスに対しても、ネットワーク範囲内でエイリアスが利用できます。ただしその場合、どのコンテナに対して名前解決されるのかの保証はありません。
一般的な形式は、以下の通りです。
services:
some-service:
networks:
some-network:
aliases:
- alias1
- alias3
other-network:
aliases:
- alias2
以下の例では、３つのサービス（ web 、 worker 、 db ）に、２つのネットワーク（ new と legacy ）が提供されています。 db サービスはホスト名 db または database として new ネットワーク上で到達可能です。そして、legacy ネットワーク上では db または mysql として到達できます。
version: "2.4"
services:
web:
image: "nginx:alpine"
networks:
- new
worker:
image: "my-worker-image:latest"
networks:
- legacy
db:
image: mysql
networks:
new:
aliases:
- database
legacy:
aliases:
- mysql
networks:
new:
legacy:
ipv4_address 、 ipv6_address¶
サービスがネットワークへ追加時、コンテナに対して
トップレベルのネットワーク・セクション では、適切なネットワーク設定に ipam ブロックが必要です。ここで、それぞれの固定アドレスが扱うサブネットやゲートウェイを定義します。
注釈
IPv6 アドレスが必要であれば、 com.docker.network.enable_ipv6 ドライバ・オプションを true にする必要があります。
例：
version: "2.4"
services:
app:
image: busybox
command: ifconfig
networks:
app_net:
ipv4_address: 172.16.238.10
ipv6_address: 2001:3984:3989::10
networks:
app_net:
driver: bridge
enable_ipv6: true
ipam:
driver: default
config:
- subnet: 172.16.238.0/24
gateway: 172.16.238.1
- subnet: 2001:3984:3989::/64
gateway: 2001:3984:3989::1
link_local_ips¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
使用例：
version: "2.4"
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¶
Compose がサービス用コンテナをどのネットワークに接続させるか、その優先度を指定します。指定がない場合、デフォルトの値は 0 です。
以下の例では、 app サービスがまず接続するのは、優先度の高い app_net_1 です。それから、 app_net_3 に接続し、それからデフォルトの優先度が 0 の app_net_2 に接続します。
version: "2.4"
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:
注釈
複数のネットワークが同じ優先度の場合、接続順は未定義になります。
pid¶
pid: "host"
pid: "container:custom_container_1"
pid: "service:foobar"
container:<コンテナ名> 、 service:<サービス名> の形式を指定すると、サービスは指定したコンテナかサービスが使用する PID アドレス空間を共有します。
"host" を指定すると、サービスの PID モードは、ホスト PID モードを設定します。これを有効化すると、コンテナとホスト・オペレーティング・システム間で PID アドレス空間を共有します。コンテナにこのフラグを付けて起動すると、、他のコンテナからアクセスできるだけでなく、ベアメタル・マシン上の名前空間などから操作できるようになります。
pids_limit¶
ヒント
ファイル形式 バージョン 2.1 で追加されました。
コンテナの PID 上限を調整します。 -1 を指定すると、 PID は無制限になります。
pids_limit: 10
platform¶
ヒント
ファイル形式 バージョン 2.4 で追加されました。
サービスを実行するコンテナの、対象プラットフォームを os[/arch[/variant]] の形式で指定します。以下は例です。
platform: osx
platform: windows/amd64
platform: linux/arm64/v8
このパラメータは、どのイメージを取得するかや、サービスをどのプラットフォームで構築するかを指定します。
ports¶
公開用のポートです。ホスト側とコンテナ側の両方のポートを指定（ ホスト側:コンテナ側 ）できるだけでなく、コンテナ側のポートのみも指定できます（ホスト側はランダムなポートが選ばれます）。
注釈
ホスト側:コンテナ側 の形式でポートを割り当てる時、コンテナのポートが 60 以下であればエラーが発生します。これは YAML が xx:yy 形式の指定を、60 進数（60が基準）の数値とみなすからです。そのため、ポートの割り当てには常に文字列としての指定を推奨します（訳者注： " で囲んで文字扱いにする）。
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"
- "12400-12500:1240"
runtime¶
ヒント
ファイル形式 バージョン 2.3 で追加されました。
サービスのコンテナが使う ;ruby:ランタイム <runtime> を指定します。デフォルトのランタイムと、利用可能なランタイムの一覧は docker info の出力から確認できます。
web:
image: busybox:latest
command: true
runtime: runc
scale¶
ヒント
ファイル形式 バージョン 2.2 で追加されました。
このサービス用にデプロイする、デフォルトのコンテナ数を指定します。 docker-compse up を実行するとすぐに、 指定した数に一致するよう Compose がコンテナの作成または削除をします。この値は --scale フラグを使って上書き可能です。
web:
image: busybox:latest
command: echo 'scaled'
scale: 3
stop_grace_period¶
コンテナを停止するために SIGTERM （あるいは、 stop_signal で指定した何らかの停止シグナル）を処理出来ない場合、 SIGKILL を送信するまで、どれだけ待機するか指定します。 期間 として指定します。
stop_grace_period: 1s
stop_grace_period: 1m30s
デフォルトでは、コンテナに SIGKILL を送信して終了するまでの stop ウェイトは 10 秒です。
stop_signal¶
コンテナに対して別の停止シグナルを設定します。デフォルトでは stop で SIGTERM を使います。 stop_signal で別のシグナルを指定したら、 stop 実行時にそのシグナルを送信します。
stop_signal: SIGUSR1
storage_opt¶
ヒント
ファイル形式 バージョン 2.1 で追加されました。
このサービスに対し、ストレージ・ドライバのオプションを指定します。
storage_opt:
size: '1G'
sysctls¶
ヒント
ファイル形式 バージョン 2.1 で追加されました。
コンテナ内でのカーネル・パラメータを指定します。配列もしくはディレクトリのどちらかで指定できます。
sysctls:
net.core.somaxconn: 1024
net.ipv4.tcp_syncookies: 0
sysctls:
- net.core.somaxconn=1024
- net.ipv4.tcp_syncookies=0
ulimits¶
コンテナのデフォルト ulimits を上書きします。単一の整数値で上限を指定できるだけでなく、ソフト／ハード・リミットの両方も指定できます。
ulimits:
nproc: 65535
nofile:
soft: 20000
hard: 40000
userns_mode¶
ヒント
ファイル形式 バージョン 2.1 で追加されました。
userns_mode: "host"
Docker デーモンでユーザ名前空間の指定があっても、このサービスに対する
volumes¶
ホスト上のパス、または
短い書式¶
[ソース:]ターゲット[:モード] の形式を使います。 ソース の場所にはホスト上のパスまたはボリューム名のどちらかを指定できます。 ターゲット とはボリュームがマウントされるコンテナ上のパスです。標準的なモードは、 ro は rw の
ホスト上の相対パスをマウント可能です。相対パスは Compose 設定ファイルが使っているディレクトリを基準とします。相対パスは . または .. で始まります。
volumes:
# パスを指定する場合は、Engine がボリュームを作成
- /var/lib/mysql
# 絶対パスを指定しての割り当て
- /opt/data:/var/lib/mysql
# ホスト上のパスを指定する時は、Compose ファイルからの相対パスを指定
- ./cache:/tmp/cache
# ユーザ用ディレクトリのパスを使用
- ~/configs:/etc/configs/:ro
# 名前付きボリューム（Named volume）
- datavolume:/var/lib/mysql
長い書式¶
ヒント
ファイル形式 バージョン 2.3 で追加されました。
type：マウントの種類 でvolume、bind、tmpfs、npipeのどれかsource：マウント元 であり、バインド・マウントするホスト上のパスか、 トップレベルの volume キー で定義済みのボリューム名。tmpfs マウントでの利用には、不適切target：コンテナ内で、ボリュームをマウントするパスread_only：ボリュームを読み込み専用に指定するフラグbind：バインドの追加オプションを指定propagation：バインドにはプロパゲーション・モード を使用
volueme：ボリュームの追加オプションを指定nocopy：ボリュームを作成しても、コンテナからのデータのコピーを無効にするフラグ
tmpfs：tmpfs の追加オプションを指定size：tmpfs マウント用の容量をバイトで指定
version: "2.4"
services:
web:
image: nginx:alpine
ports:
- "80:80"
volumes:
- type: volume
source: mydata
target: /data
volume:
nocopy: true
- type: bind
source: ./static
target: /opt/app/static
networks:
webnet:
volumes:
mydata:
注釈
バインド・マウントを作成する場合、長い構文では参照するフォルダを事前に作成しておく必要があります。短い構文では、対象フォルダが存在しなければ即時作成します。詳しい情報は バインド・マウントのドキュメント をご覧ください。
volume_driver¶
このサービス上で宣言されたすべてのボリュームが使う、デフォルトの
volume_driver: mydriver
注釈
バージョン 2 ファイルでは、このオプションが適用されるのは volumes 以下で指定したボリュームが、明示された名前付きボリューム、または、ホスト上のパスではない場合）のみです。名前付きボリュームに対してドライバを指定するには、 トップレベルの volume オプション 以下で driver キーを使います。
詳しい情報は Docker ボリューム と ボリューム・プラグイン をご覧ください。
volumes_from¶
他のサービスやコンテナから、すべてのボリュームをマウントします。オプションで、 ro ）や <read-write> 読み書き可能 （ rw ）を指定できます。アクセスレベルの指定がなければ、読み書き可能です。
volumes_from:
- service_name
- service_name:ro
- container:container_name
- container:container_name:rw
ヒント
ファイル形式 バージョン 2 で変更されました。
期間の指定¶
設定オプションのいくつかには、 healthcheck 用サブオプションの interval と timeout のように、期間を文字列で指定可能な形式があります。次のように指定します。
2.5s
10s
1m30s
2h32m
5h34m56s
サポートしている単位は、 us 、 ms 、 s 、 m 、 h です。
バイト値の指定¶
設定オプションのいくつかには、 blkio_config 用サブオプションの device_read_bps のように、バイト値を文字列で指定可能な形式があります。次のように指定します。
2b
1024kb
2048k
300m
1gb
サポートしている単位は、 b 、 k 、 m 、 g と、他にも kb 、 mb 、 gd の記法です。
ボリューム設定リファレンス¶
サービス宣言の一部として ボリューム を臨機応変に宣言できますが、このセクションでは、複数のサービス間（ volumes_from に依存）を横断して再利用可能な
ボリューム上での一般的な情報は、 ボリュームの使用 と ボリューム・プラグインの記述 をご覧下さい。
以下は2つのサービスをセットアップする例です。データベースの（ data-volume という名前の）データ・ディレクトリを、他のサービスからはボリュームとして共有するため、定期的なバックアップのために利用できます。
version: "2.4"
services:
db:
image: db
volumes:
- data-volume:/var/lib/db
backup:
image: backup-service
volumes:
- data-volume:/var/lib/backup/data
volumes:
data-volume:
トップレベルの volumes キー以下のエントリは、空っぽにできます。その場合、Engine によって設定されているデフォルトのドライバ設定（多くの場合、 local ドライバ）が使われます。オプションで、以下のキーを設定できます。
driver¶
このボリュームに対して、どのボリューム・ドライバを使うか指定します。デフォルトは、Docker Engineで使用するように設定されているドライバであり、多くの場合は local です。対象のドライバが利用できなければ、 docker-compose up でボリュームを作成しようとしても、Engine はエラーを返します。
driver: foobar
driver_opts¶
ボリュームが使うドライバに対して、オプションをキーバリューのペアで指定します。これらのオプションはドライバに依存します。オプションの詳細については、各ドライバのドキュメントをご確認ください。
volumes:
example:
driver_opts:
type: "nfs"
o: "addr=10.40.0.199,nolock,soft,rw"
device: ":/docker/example"
external¶
このオプションを true に設定すると、Compose の外でボリュームを作成します（訳者注：Compose が管理していない Docker ボリュームを利用します、という意味）。 docker-compose up を実行してもボリュームを作成しません。もしボリュームが存在していなければ、エラーを返します。
バージョン 2.0 形式では、external は他のボリューム用の設定キー（ driver 、driver_opts 、 labels ） と一緒に使えません。この制限は、バージョン 2.1 以上ではありません。
以下の例は、 [プロジェクト名]_data という名称のボリュームを作成する代わりに、Compose は data という名前で外部に存在するボリュームを探し出し、それを db サービスのコンテナの中にマウントします。
version: '2.4'
services:
db:
image: postgres
volumes:
- data:/var/lib/postgres/data
volumes:
data:
external: true
また、Compose ファイルの中で使われている名前を参照し、ボリューム名を指定可能です。
volumes
data:
external:
name: actual-name-of-volume（実際のボリューム名）
labels¶
ヒント
ファイル形式 バージョン 2.1 で追加されました。
Docker ラベル を使い、コンテナにメタデータを追加します。配列もしくは
他のソフトウェアが使うラベルと競合しないようにするため、ラベルには逆引き 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"
ネットワーク設定リファレンス¶
ネットワークを作成するには、トップレベルの networks キーを使って指定します。Compose 上でネットワーク機能を使うための詳細情報は、 networking をご覧ください。
driver¶
対象のネットワークが使用するドライバを指定します。
デフォルトでどのドライバを使用するかは Docker Engine の設定に依存します。一般的には単一ホスト上であれば bridge でしょうし、 Swarm 上であれば overlay でしょう。
ドライバが使えなければ、Docker Engine はエラーを返します。
driver: overlay
ヒント
バージョン 2.1 ファイル形式で変更されました。
Compose 形式 2.1 からは、オーバレイ・ネットワークは attachable として常に作成可能となりました。また、これは設定変更できません。つまり、スタンドアロン・コンテナはオーバレイ・ネットワークに接続できないことを意味します。
driver_opts¶
ネットワークが使うドライバに対して、オプションをキーバリューのペアで指定します。これらのオプションはドライバに依存します。オプションの詳細については、各ドライバのドキュメントをご確認ください。
driver_opts:
foo: "bar"
baz: 1
ipam¶
IPAM （IPアドレス管理）のカスタム設定を指定します。様々なプロパティ（設定）を持つオブジェクトですが、各々の指定はオプションです。
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¶
Docker は外部との接続をするために、デフォルトではブリッジネットワークにも接続します。外部への隔たれたオーバレイ・ネットワークを作成したい場合は、このオプションを true に指定できます。
labels¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
Docker ラベル を使ってコンテナにメタデータを追加します。アレイ形式か辞書形式が使えます。
他のソフトウェアが使っているラベルとの重複を避けるため、逆引き 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"
external¶
このオプションを true に設定したら、Compose の外にネットワークを作成します（訳者注：Compose が管理していない Docker ネットワークを利用します、という意味）。 docker-compose up を実行してもネットワークを作成しません。もしネットワークが存在していなければ、エラーを返します。
バージョン 2.0 形式までは、external は他のネットワーク用の設定キー（ driver 、driver_opts 、 ipam ） と一緒に使えません。この制限はバージョン 2.1 以上にはありません。
以下の例は、外の世界とのゲートウェイに proxy を使います。 [プロジェクト名]_outside という名称のネットワークを作成する代わりに、Compose は outside という名前で外部に存在するネットワークを探し出し、それを proxy サービスのコンテナに接続します。
version: '2.4'
services:
proxy:
build: ./proxy
networks:
- outside
- default
app:
build: ./app
networks:
- default
networks:
outside:
external: true
また、Compose ファイルの中で使われている名前を参照し、ネットワーク名を指定可能です。
version: "2.4"
networks:
outside:
external:
name: actual-name-of-network
バージョン 2 docker-compose ファイルではサポートしていません。代わりに network_mode を使います。
変数の置き換え¶
設定オプションでは環境変数も含めることができます。シェル上の Compose は docker-compose の実行時に環境変数を使えます。たとえば、シェルで POSTGRES_VERSION=9.3 という変数を設定ファイルで扱うには、次のようにします。
db:
image: "postgres:${POSTGRES_VERSION}"
この設定で docker-compose up を実行したら、Compose は POSTGRES_VERSION 環境変数をシェル上で探し、それを値と置き換えます。この例では、Compose は設定を実行する前に image に postgres:9.3 を割り当てます。
環境変数が設定されていなければ、Compose は空の文字列に置き換えます。先の例では、 POSTGRES_VERSION が設定されなければ、 image オプションは postgres: です。
環境変数のデフォルト値は doc:.env ファイル <env-file> を使って指定できます。Compose はプロジェクトのディレクトリ内（Compose ファイルが置いてある親フォルダ）を自動的に探します。シェル環境における値は、 .env ファイル内のもので上書きします。
警告
.env ファイル機能が使えるのは docker-compose up コマンドを使った時のみです。 docker stack deploy では機能しません。
$変数 と ${変数} の両方がサポートされています。加えて、 2.1 ファイル形式を使う時は、典型的なシェル構文を用いて、デフォルトの値を指定できます。
${変数:-default}は、環境変数における変数が未定義もしくは空の場合、値はdefaultになります。${変数-default}は、環境変数における変数が未定義の場合のみ、値はdefaultになります。
同様に、以下の構文によって省略できない変数を指定できます。
${変数:?err}は、環境変数における変数が未定義もしくは空の場合、errを含むメッセージのエラーと共に終了します。${変数?err}は、環境変数における変数が未定義の場合のみ、errを含むメッセージのエラーと共に終了します。
${変数/foo/bar} のような拡張シェル形式の機能はサポートされていません。
$$ （二重ドル記号）を指定する時は、設定ファイル上でリテラルなドル記号の設定が必要です。Compose は値を補完しませんので、 $$ の指定により、 Compose によって処理されずに環境変数を参照します。
web:
build: .
command: "$$VAR_NOT_INTERPOLATED_BY_COMPOSE"
もしも間違えてドル記号（ $ ）だけにしたら、 Compose は環境変数の値を解釈し、次のように警告を表示します。
The VAR_NOT_INTERPOLATED_BY_COMPOSE is not set. Substituting an empty string.
拡張フィールド¶
ヒント
Compose 形式 バージョン 2.1 で追加されました。
拡張フィールドを使い、設定の一部の再利用できる場合があります。それぞれの特別フィールドは、Compose ファイルの存在する場所（ルート）に位置する限り利用でき、それらの名前は x- で始まる文字に続きます。
注釈
3.7 形式以降（の 3.x 系統）と、2.4 形式（以降の 2.x 形式）では、拡張フィールドでも service のルート、volume、network、config、secret を定義できます。
version: "3.9"
x-custom:
items:
- a
- b
options:
max-size: '12m'
name: "custom"
各フィールドの内容は Compose からは無視されます。ですが、 YAML アンカー を使ったリソース定義のために挿入できます。たとえば、同じログ記録設定を使うために、複数のサービスを使いたい場合を考えます。
logging:
options:
max-size: '12m'
max-file: '5'
driver: json-file
Compose ファイルでは、次のようにも書けます。
version: "3.9"
x-logging:
&default-logging
options:
max-size: '12m'
max-file: '5'
driver: json-file
services:
web:
image: myapp/web:latest
logging: *default-logging
db:
image: mysql:latest
logging: *default-logging
YAML merge type を使い、拡張フィールド値の部分的に上書きもできます。例：
version: "3.9"
x-volumes:
&default-volume
driver: foobar-storage
services:
web:
image: myapp/web:latest
volumes: ["vol1", "vol2", "vol3"]
volumes:
vol1: *default-volume
vol2:
<< : *default-volume
name: volume02
vol3:
<< : *default-volume
driver: default
name: volume-local