Compose ファイル version 2 リファレンス

リファレンスと方針

以下のトピックでは、 Compose ファイル形式バージョン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 です。

ちなみに

このファイルは .yml.yaml いずれか一方の拡張子を利用できます。どちらも機能します。

サービスの定義に入るのは、コマンドラインで docker run にパラメータを渡すのと同じように、サービスとして起動するコンテナに対して適用する設定です。同様に、ネットワークやボリュームの定義も docker network createdocker volume create と似ています。

docker run と同様に、 Dockerfile で指定した CMDEXPOSEVOLUMEENV のようなオプションが、デフォルト(の設定値)として尊重されます。そのため、 docker-compose.yml で再び指定する必要はありません。

Bash のような ${変数名} の構文を使い、環境変数を設定値として使用できます。詳しくは 変数の置き換え をご覧ください。

このセクションでは、(Docker Compose)バージョン2のサービス定義用にサポートされている、設定オプションの一覧を扱います。

blkio_config

対象のサービスに対し、ブロック IO 制限(block IO limits) を指定するためのオプション設定です。

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 、対象となるデバイスを示す(ファイルシステム上に見える) パス(path) を定義

  • rate 、(制限する転送レートとして)バイト数を整数の値で表すか、(転送レートの) バイト値 を文字列で表す

device_read_iops, device_write_iops

指定するデバイスに対し、1秒あたりの処理数を制限する設定です。記載する項目ごとに、2つのキーが必要です。

  • path 、対象となるデバイスを示す(ファイルシステム上に見える) パス(path) を定義

  • rate 、整数の値で1秒間で許可される操作数を表す

weight

他のサービスと比較し、指定対象のサービスに割り当てられる帯域の割合を変更。値は 10 から 1000 までの整数で、デフォルトは 500 です。

weight_device

デバイスに割り当てる帯域を微調整します。記載する項目ごとに、2つキーが必要です。

  • path 、対象となるデバイスを示す(ファイルシステム上に見える) パス(path) を定義

  • weight 、値は 10 から 1000 までの整数

build

構築時(build time) に適用するオプションを指定します。

build では 構築コンテキスト(build context) へのパスを含む文字列を指定できます。

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

つまり、 ./ 以下から 構築(build) した結果、 webapp という名前と tag というタグ名を持つイメージができます。

context

ヒント

Compose 形式 バージョン 2 で追加されました。

Dockerfile を含むディレクトリのパス、あるいは、git リポジトリへの URL を指定します。

相対パスとして値を指定すると、 Compose ファイルがある場所を基準とした相対パスとして解釈されます。また、そのディレクトリが構築コンテキストとなり、その内容が Docker デーモンに対して送られます。

Compose は作成時の名前を使ってイメージ構築やタグ付けをし、以降は、そのイメージを使います。

build:
  context: ./dir

dockerfile

別の Dockerfile を指定します。

Compose は別の Dockerfile ファイルを使い構築します。 構築パス(build path) の指定も必要です(訳者注:構築コンテキスト、つまり、使いたい Dockerfile のある場所を指定)。

build:
  context: .
  dockerfile: Dockerfile-alternate

args

ヒント

Compose 形式 バージョン 2 で追加されました。

build の 引数(arg) (構築時のオプション)を指定します。ここで指定した引数は、構築の処理中のみ環境変数として利用できます。

まずはじめに、 Dockerfile 内で引数を指定しておきます。

# syntax=docker/dockerfile:1

ARG buildno
ARG gitcommithash

RUN echo "Build number: $buildno"
RUN echo "Based on commit: $gitcommithash"

そして、 build キーの下で引数を指定します。 マッピング(mapping) またはリストで引数を渡します。

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

ちなみに

ブール値を使う場合

YAML の ブール値(boolean values)"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 で追加されました。

構築時のコンテナ 分離(isolation) 技術を指定します。 Linux 上で唯一サポートされている値は default です。Windows では defaultprocesshyperv を指定できます。詳細は Docker Engine のドキュメント をご覧ください。

指定が無い場合、 Compose が構築に使う値の決定には、サービスの定義で見つかった isolation 値を使います。

labels

ヒント

Compose 形式 バージョン 2.1 で追加されました。

Docker ラベル を使い、結果として作成されるイメージにメタデータを追加します。 配列(array) または 連想配列(dictionary) が使えます。

指定するラベルが他のソフトウェアで使われているものと重複を避けるには、 逆引き DNS 記法(reverse-DNS notation) の利用を推奨します。

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

shm_size

ヒント

Compose 形式 バージョン 2.3 で追加されました。

構築用コンテナの /dev/shm パーティションの容量を指定します。(容量の)バイト数を整数の値として表すか、 バイト値 の文字列で表します。

build:
  context: .
  shm_size: '2gb'
build:
  context: .
  shm_size: 10000000

target

ヒント

Compose 形式 バージョン 2.3 で追加されました。

Dockerfile の中で定義された ステージ(stage) を指定して構築します。詳細は マルチステージ・ビルド をご覧ください。

build:
  context: .
  target: prod

cap_add, cap_drop

コンテナの ケーパビリティ(capabilities) を追加・削除します。ケーパビリティの一覧は man 7 capabilities をご覧ください。

cap_add:
  - ALL

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

cgroup_parent

コンテナに対してオプションの親 cgroup を指定します。

cgroup_parent: m-executor-abcd

command

デフォルトの コマンド(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 が 許可されたデバイス一覧(allowed devices list) にルールを追加します。

device_cgroup_rules:
  - 'c 1:3 mr'
  - 'a 7:* rmw'

devices

デバイス・マッピング(割り当て)(device mapping) の一覧です。docker クライアントで作成するオプションの --device と同じ形式を使います。

devices:
  - "/dev/ttyUSB0:/dev/ttyUSB0"

depends_on

ヒント

Compose 形式 バージョン 2.0 で追加されました。

サービス間の 依存関係(dependency) を明示します。サービス依存関係は、以下の挙動が発生します。

  • docker-compose up を実行すると、依存関係の順番に従いサービスを 起動(start) します。以下の例では、 web を起動する前に dbredis を起動します。

  • docker-compose up サービス名 を実行すると、自動的に サービス名 と依存関係のあるサービスも起動します。以下の例では、 docker-compose up web によって、 dbred サービスも作成・起動します。

  • docker-compose stop は、依存関係の順番に従いサービスを 停止(stop) します。以下の例では、 dbredis の前に web を停止します。

簡単な例:

version: "2.4"
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

注釈

depends_on では、 web が起動する前に dbredis が「 準備完了(ready) 」になるのを待ちません。単に各サービスが起動するのを待つだけです。サービスの準備が完了するまで待つ必要がある場合は、この問題の解決や方針検討のために 起動順番の制御 をご覧ください。

ヒント

Compose 形式 バージョン 2.1compose-file-version-21> で追加されました。

ヘルスチェック(healthcheck) が指示するのは、あるコンテナを起動する前に依存関係が必要で、他のコンテナが「 正常(healthy)」(ヘルスチェックの状態が成功を示す時)になるまで依待機します。

例:

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 サービスが 起動完了(started) するまで待ち(従来の挙動)、そして、 db サービスが 正常(healthy) になった後に、 web を起動します。

補足情報については、 healchechek セクション をご覧ください。

dns

任意の DNS サーバに設定を変更します。単一の値、もしくはリストになります。

dns: 8.8.8.8
dns:
  - 8.8.8.8
  - 9.9.9.9

dns_opt

コンテナの resolv.conf ファイルに、任意の DNS オプションをリストで追加。

dns_opt:
  - use-vc
  - no-tld-query

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 オプションを指定している場合、環境変数用ファイルで定義された変数は、構築中に自動で見えるようになりません。構築時の環境変数として定義するには、 buildargs サブオプションを使います。

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

環境変数を追加します。配列もしくは 辞書形式(dictionary) で指定できます。boolean 値 (true、false、yes、no のいずれか) は、YML パーサによって True か False に変換されないよう、クォート( ' 記号)で囲む必要があります。

キーだけの環境変数は、Compose の実行時にマシン上で指定するものであり、 :ruby:`シークレット <secret>`(訳注:API鍵などの秘密情報)やホスト固有の値を指定するのに便利です。

environment:
  RACK_ENV: development
  SHOW: 'true'
  SESSION_SECRET:
environment:
  - RACK_ENV=development
  - SHOW=true
  - SESSION_SECRET

注釈

サービスに biuld オプションを指定している場合、環境変数用ファイルで定義された変数は、構築中に自動で見えるようになりません。構築時の環境変数として定義するには、 buildargs サブオプションを使います。

expose

コンテナの 公開(露出)(expose) 用のポート番号を指定しますが、ホストマシン上で公開するポートを指定しません。つまり、つながったサービス間でのみアクセス可能になります。内部で使うポートのみ指定できます。

expose:
 - "3000"
 - "8000"

extends

現在のファイルから別のファイルにサービスを拡張するもので、設定のオプションを追加します。

他の設定用のキーと一緒にサービスを extends (拡張)できます。 extends 値には service の定義が必要であり、オプションで file キーを指定します。

extends:
  file: common.yml
  service: webapp

service とは、 拡張される(extend) サービスの名前で、 webdatabase などです。 file は対象のサービスを定義する Compose 設定ファイルの場所です。

file を省略したら、Compose は現在の設定ファイル上からサービスの定義を探します。 file の値は相対パスまたは絶対パスです。相対パスを指定したら、Compose はその場所を、現在のファイルからの相対パスとして扱います。

サービス自身が、他に対して拡張するサービス定義をできます。拡張は無限に可能です。Compose は循環参照をサポートしておらず、もし循環参照があれば docker-compose はエラーを返します。

extends に関するより詳細は、 extends ドキュメント をご覧ください。

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 で追加されました。

このサービスのコンテナが「 正常(healthy) 」かどうかを判断するために実行する、確認用コマンドを設定します。ヘルスチェックがどのように動作するかの詳細は、 HEALTHCHECK Dockerfile 命令 のドキュメントをご覧ください。

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost"]
  interval: 1m30s
  timeout: 10s
  retries: 3
  start_period: 40s

intervaltimeoutstart_period継続時間 として指定します。

ヒント

start_period オプションは、Compose 形式 バージョン 2.3 で追加されました。

test は文字列またはリスト形式のどちらかの必要があります。リスト形式の場合、1番目のアイテムは NONECMDCMD-SHELL のどちらかの必要があります。文字列の場合は、 CMD-SHELL に続けて文字列をを指定するのと同じです。

# ローカルの web アプリを叩く
test: ["CMD", "curl", "-f", "http://localhost"]

前述したのは /bin/sh でラッピングされています。以下の2つは同じです。

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 を実行し、シグナルの転送と、プロセス 再配置(reap) します。サービスに対してこの機能を有効化するには、このオプションで true を指定します。

version: "2.4"
services:
  web:
    image: alpine:latest
    init: true

注釈

デフォルトの init バイナリは、 Tiny が使われ、デーモンのホスト上の /usr/libexec/docker-init にインストールされます。 任意の init バイナリ使うには、デーモンに対して init-path 設定オプション を通して指定できます。

isolation

ヒント

Compose 形式 バージョン 2.1 で追加されました。

コンテナの 隔離(isolation) 技術を指定します。 Linux 上では、唯一サポートしている値が default です。Windows specify-isolation-technology-for-container-isolation用では、 defaultprocesshyperv が指定できます。詳細は、 Docker Engine ドキュメント をご覧ください。

labels

Docker ラベル を使い、コンテナに メタデータ(metadata) を追加します。配列または辞書形式で追加できます。

他のソフトウェアが使うラベルと競合しないようにするため、 逆引き DNS 記法(reverse-DNS notation) の利用を推奨します。

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"

logging

サービスに対して ログ記録(logging) の設定をします。

logging:
  driver: syslog
  options:
    syslog-address: "tcp://192.168.0.42:123"

driver にはサービス用のコンテナで使う ロギング・ドライバ(logging driver) を指定します。これは docker run コマンドにおける --log-driver オプションと同じです ( ドキュメントはこちら )。

デフォルトの値は json-file です。

driver: "json-file"
driver: "syslog"
driver: "none"

注釈

docker-compose up で立ち上げてから docker-compose logs コマンドを使い、ログを表示できるのは json-filejournald ドライバを指定した時のみです。他のドライバを指定しても、ログは何ら表示されません。

ロギング・ドライバのオプションを指定するには 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) (別のホスト名)とは、ネットワーク上のサービスに対してです。同一ネットワーク上の他のコンテナが、サービス名か、このエイリアスを使い、サービス用コンテナの1つに接続します。

aliases が適用されるのは 同一ネットワークの範囲内(network-scoped) のみです。そのため、同じサービスでも、ネットワークごとに異なったエイリアスが使えます。

注釈

複数のコンテナだけでなく複数のサービスに対しても、ネットワーク範囲内でエイリアスが利用できます。ただしその場合、どのコンテナに対して名前解決されるのかの保証はありません。

一般的な形式は、以下の通りです。

services:
  some-service:
    networks:
      some-network:
        aliases:
         - alias1
         - alias3
      other-network:
        aliases:
         - alias2

以下の例では、3つのサービス( webworkerdb )に、2つのネットワーク( newlegacy )が提供されています。 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

サービスがネットワークへ追加時、コンテナに対して 固定(static) IP アドレスを割り当てます。

トップレベルのネットワーク・セクション では、適切なネットワーク設定に 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

priority

Compose がサービス用コンテナをどのネットワークに接続させるか、その優先度を指定します。指定がない場合、デフォルトの値は 0 です。

以下の例では、 app サービスがまず接続するのは、優先度の高い app_net_1 です。それから、 app_net_3 に接続し、それからデフォルトの優先度が 0app_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 アドレス空間を共有します。コンテナにこのフラグを付けて起動すると、、他のコンテナからアクセスできるだけでなく、ベアメタル・マシン上の名前空間などから操作できるようになります。

ヒント

ファイル形式 バージョン 2.1 で追加されました。 service:container: 形式には、 バージョン 2.1 以上が必要です。

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

security_opt

各コンテナに対するデフォルトの ラベリング・スキーマ(labeling scheme) を上書きします。

security_opt:
  - label:user:USER
  - label:role:ROLE

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

tmpfs

コンテナ内にテンポラリ・ファイルシステムをマウントします。単一の値もしくはリストです。

tmpfs: /run
tmpfs:
  - /run
  - /tmp

ulimits

コンテナのデフォルト ulimits を上書きします。単一の整数値で上限を指定できるだけでなく、ソフト/ハード・リミットの両方も指定できます。

ulimits:
  nproc: 65535
  nofile:
    soft: 20000
    hard: 40000

userns_mode

ヒント

ファイル形式 バージョン 2.1 で追加されました。

userns_mode: "host"

Docker デーモンでユーザ名前空間の指定があっても、このサービスに対する ユーザ名前空間(user namespace) を無効にします。詳しい情報は dockerd をご覧ください。

volumes

ホスト上のパス、または 名前付きボリューム(named volumes) をマウントします。名前付きボリュームには、 トップレベルの volume キー を指定が必要です。

短い書式

短い書式(short syntax) は、一般的に [ソース:]ターゲット[:モード] の形式を使います。 ソース の場所にはホスト上のパスまたはボリューム名のどちらかを指定できます。 ターゲット とはボリュームがマウントされるコンテナ上のパスです。標準的なモードは、 ro読み込み専用(read-only)rw読み書き(read-write) (デフォルト)です。

ホスト上の相対パスをマウント可能です。相対パスは 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 で追加されました。

長い書式(long syntax) は、短い書式では表現できない追加フィールドを設定できるようにします。

  • type :マウントの 種類(type)volumebindtmpfsnpipe のどれか

  • sourceマウント元(source) であり、バインド・マウントするホスト上のパスか、 トップレベルの volume キー で定義済みのボリューム名。tmpfs マウントでの利用には、不適切

  • target :コンテナ内で、ボリュームをマウントするパス

  • read_only :ボリュームを読み込み専用に指定するフラグ

  • bind :バインドの追加オプションを指定

    • propagation :バインドには プロパゲーション・モード(propagation mode) を使用

  • 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) を指定します。

volume_driver: mydriver

注釈

バージョン 2 ファイルでは、このオプションが適用されるのは 匿名ボリューム(anonymous volume) (イメージの中で指定されているか、 volumes 以下で指定したボリュームが、明示された名前付きボリューム、または、ホスト上のパスではない場合)のみです。名前付きボリュームに対してドライバを指定するには、 トップレベルの volume オプション 以下で driver キーを使います。

詳しい情報は Docker ボリュームボリューム・プラグイン をご覧ください。

volumes_from

他のサービスやコンテナから、すべてのボリュームをマウントします。オプションで、 read-only(読み込み専用) のアクセス( ro )や <read-write> 読み書き可能 ( rw )を指定できます。アクセスレベルの指定がなければ、読み書き可能です。

volumes_from:
 - service_name
 - service_name:ro
 - container:container_name
 - container:container_name:rw

ヒント

ファイル形式 バージョン 2 で変更されました。

restart

no はデフォルトの 再起動ポリシー(restart policy) であり、どのような状況下でもコンテナを再起動しません。 always (常に)が指定されれば、コンテナは常に再起動します。 on-failure ポリシーは、終了コードが 障害発生(on-failure) エラーの場合に、コンテナを再起動します。

restart: "no"
restart: "always"
restart: "on-failure"
restart: "unless-stopped"

cpu_count, cpu_percent, cpu_shares, cpu_period, cpu_quota, cpus, cpuset, domainname, hostname, ipc, mac_address, mem_limit, memswap_limit, mem_swappiness, mem_reservation, oom_kill_disable, oom_score_adj, privileged, read_only, shm_size, stdin_open, tty, user, working_dir

それぞれの単一の値であり、 docker run の値に対応します。

ヒント

cpu_countcpu_percentcpus オプションは、ファイル形式 バージョン 2.2 で追加されました。

ヒント

oom_kill_disablecpu_period は、ファイル形式 バージョン 2.1 で追加されました。

cpu_count: 2
cpu_percent: 50
cpus: 0.5
cpu_shares: 73
cpu_quota: 50000
cpu_period: 20ms
cpuset: 0,1

user: postgresql
working_dir: /code

domainname: foo.com
hostname: foo
ipc: host
mac_address: 02:42:ac:11:65:43

mem_limit: 1000000000
memswap_limit: 2000000000
mem_reservation: 512m
privileged: true

oom_score_adj: 500
oom_kill_disable: true

read_only: true
shm_size: 64M
stdin_open: true
tty: true

期間の指定

設定オプションのいくつかには、 healthcheck 用サブオプションの intervaltimeout のように、期間を文字列で指定可能な形式があります。次のように指定します。

2.5s
10s
1m30s
2h32m
5h34m56s

サポートしている単位は、 usmssmh です。

バイト値の指定

設定オプションのいくつかには、 blkio_config 用サブオプションの device_read_bps のように、バイト値を文字列で指定可能な形式があります。次のように指定します。

2b
1024kb
2048k
300m
1gb

サポートしている単位は、 bkmg と、他にも kbmbgd の記法です。

ボリューム設定リファレンス

サービス宣言の一部として ボリューム を臨機応変に宣言できますが、このセクションでは、複数のサービス間( volumes_from に依存)を横断して再利用可能な 名前付きボリューム(named volume) を作成します。それから、 docker コマンドラインや API を使って、簡単に取り出したり調査したりします。

ボリューム上での一般的な情報は、 ボリュームの使用ボリューム・プラグインの記述 をご覧下さい。

以下は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 は他のボリューム用の設定キー( driverdriver_optslabels ) と一緒に使えません。この制限は、バージョン 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(実際のボリューム名)

警告

バージョン 2.1 では非推奨となりました。

external.name はファイル形式バージョン 2.1 では非推奨となりました。代わりに name を使います。

labels

ヒント

ファイル形式 バージョン 2.1 で追加されました。

Docker ラベル を使い、コンテナにメタデータを追加します。配列もしくは 辞書形式(dictionary) で指定できます。

他のソフトウェアが使うラベルと競合しないようにするため、ラベルには逆引き 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"

name

ヒント

ファイル形式 バージョン 2.1 で追加されました。

このボリュームに対してカスタム名を設定します。この名前の領域は、特別な文字列を含むボリュームとして参照できます。この名前はそのまま全体を通して使用されますので、他の場所ではボリューム名として使用 できません

version: "2.4"
volumes:
  data:
    name: my-app-data

また、 external 属性とあわせて使えます。

version: "2.4"
volumes:
  data:
    external: true
    name: my-app-data

ネットワーク設定リファレンス

ネットワークを作成するには、トップレベルの 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

enable_ipv6

ヒント

Compose 形式 バージョン 2.1 で追加されました。

このネットワーク上で IPv6 通信を有効にします。

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 は他のネットワーク用の設定キー( driverdriver_optsipam ) と一緒に使えません。この制限はバージョン 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 を使います。

name

ヒント

Compose 形式 バージョン 2.1 で追加されました。

このネットワークにカスタム名を指定します。 name のフィールドには、特別な文字を含むネットワーク参照が使えます。この名前は単に名前として使われるだけであり、スタック名のスコープでは使われ ません

version: "2.4"
networks:
  network1:
    name: my-app-net

また、 external プロパティをつなげても利用できます。

version: "2.4"
networks:
  network1:
    external: true
    name: my-app-net

変数の置き換え

設定オプションでは環境変数も含めることができます。シェル上の Compose は docker-compose の実行時に環境変数を使えます。たとえば、シェルで POSTGRES_VERSION=9.3 という変数を設定ファイルで扱うには、次のようにします。

db:
  image: "postgres:${POSTGRES_VERSION}"

この設定で docker-compose up を実行したら、Compose は POSTGRES_VERSION 環境変数をシェル上で探し、それを値と置き換えます。この例では、Compose は設定を実行する前に imagepostgres: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

Compose に関するドキュメント

参考

Compose file reference

https://docs.docker.com/compose/compose-file/