Docker Compose配置文件是Docker Compose定义服务、网络和数据卷的核心。格式为YAML，默认路径为./docker-compose.yml，可以使用.yml或.yaml扩展名，目前Compose最新版本的配置文件格式是V3。Compose配置文件中涉及的配置项也很多，但大多数配置项的含义和含义docker run命令相关选项相似。
本文主要参考官方文官方文档V3版Compose总结配置文件。它们都是不涉及具体操作的概念内容。
这里主要对Compose简要总结配置文件版本的相关要点。对于每个版本的具体变化和升级信息，请参考官方信息Compose配置文件版本和升级指南。
目前有三种版本Compose配置文件格式：
省略旧格式YAML的根配置项version来指定。
版本未声明Compose所有配置文件都被视为V1.所有服务都是根选项Compose声明在配置文件中。
支持V1的Compose最高到1.6.x，再高版本的Compose不推荐使用V1版Compose配置文件。
不支持数据卷、网络和构建参数配置。
V1的Compose不会利用网络优势，每个容器都位于默认的bridge从其他容器可以上网，IP需要使用地址访问links启用容器之间的发现。
通过YAML的根配置项version具体配置如指定version: '2'或version: '2.1'等。
必须在Compose配置文件根选项指定版本号，主版本号为2，所有服务必须在services配置项下声明。
1.6.0 版本的Compose都支持V2，Docker Engine的版本需要1.10.0 版本。
支持数据卷和网络的配置。
默认情况下，每个容器都添加了默认网络，并且可以在与服务名称相同的主机名下找到。在很大程度上，links不必要。
V二中增加了环境变量替换。
最新版本，也推荐使用版本，推出版本的目的是Compose和Docker Engine的swarm交叉兼容在模式之间形成。
通过YAML的根配置项version具体配置如指定version: '3'或version: '3.1'等。
V3删除了多个配置项，但也增加了更多的配置项。
关于Compose配置文件版本的常见注意事项：
在指定Compose当配置文件需要使用的版本时，应同时指定主版本和次版本的数字。如果没有给定次版本的数字，则默认使用0而不是最新版本，因此不支持在更高版本中添加的新功能。version: 用的是3.0版本不是最新的3.8版本。
在使用多Compose配置文件时应注意：
使用多个Compose在配置文件扩展服务时，每个文件必须是相同的版本。
Compose配置文件格式具有多种版本。其中Compose配置文件格式版本和Docker如下表所示：
Compose配置文件格式版本 Docker Engine 版本
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 1.0 1.9.1. 如果使用旧版本Docker，可参考官方Compose版本发布列表。每组发布说明都详细说明了支持。Docker Engine与版本兼容Compose配置文件格式版本。
在1.20.0版本，Compose在docker-compose一个新的选项被引入到命令中--compatibility，目的是帮助开发人员更容易过渡到V3版。该选项启用后，docker-compose命令会读取每个服务定义的deploy试图将部分转换为等效部分V2配置项。目前，以下deploy以下配置项已转换：
resources下的limits和reservations下的memory
replicas
restart_policy下的 condition 和max_attempts
所有其他配置项都将被忽略，如果这些被忽略的配置项存在，将发出警告。可以使用带--compatibility的Config命令检查将用于deploy的配置。
请注意不要在生成环境中使用兼容模式！
建议不要在生产环境中使用--compatibility选项。非使用Swarm模型属性产生的配置只是近似值，因此可能会产生意想不到的结果。
Docker Compose配置文件用于定义服务、网络和数据卷YAML文件。服务定义了服务启动的每个容器的配置，就像将命令行参数传递给docker run网络和数据卷的定义相似docker network create和docker volume create。跟docker run同样，如果在Dockerfile中通过诸如CMD、EXPOSE、VOLUME和ENV这些指令指定了相关选项，因此在默认情况下不需要docker-compose.yml再次指定它们。以下是从官网引进的一个Compose对于配置文件的示例，首先可以大致了解其结构：
version: "3.8" services: redis: image: redis:alpine ports: - "6379" networks: - frontend deploy: replicas: 2 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure db: image: postgres:9.4 volumes: - db-data:/var/lib/postgresql/data networks: - backend deploy: placement: constraints: - "node.role==manager" vote: image: dockersamples/examplevotingapp_vote:before ports: - "5000:80" networks: - frontend depends_on: - redis deploy: replicas: 2 update_config: parallelism: 2 restart_policy: condition: on-failure result: image: dockersamples/examplevotingapp_result:before ports: - "5001:80" networks: - backend depends_on: - db deploy: replicas: 1 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure worker: image: dockersamples/examplevotingapp_worker networks: - frontend - backend deploy: mode: replicated replicas: 1 labels: [APP=VOTING] restart_policy: condition: on-failure delay: 10s max_attempts: 3 window: 120s placement: constraints: - "node.role==manager" visualizer: image: dockersamples/visualizer:stable ports: - "8080:8080" stop_grace_period: 1m30s volumes: - "/var/run/docker.sock:/var/run/docker.sock" deploy: placement: constraints: - "node.role==manager"
networks:
frontend:
backend:
volumes:
db-data:顶层的version、services、networks和volumes将Compose配置文件分为四个部分，其中version指定Compose配置文件的版本，services定义服务，networks定义网络，volumes定义数据卷。
服务定义了该服务启动的每个容器的配置，就像将命令行参数传递给docker run一样。比如以下配置：
services:
redis:
image: redis:alpineservices下的redis是用户自定义的服务名称，redis下的image只是众多服务配置项中的其中一个，意思是指定镜像名称或id。下面就对服务的相关配置项进行一个总结。
在构建时应用的配置项。一般直接指定Dockerfile所在文件夹路径，可以是绝对路径，或者相对于Compose配置文件的路径。可以指定为包含构建上下文（context）路径的字符串。例如：
version: "3.8"
services:
webapp:
build: ./dir也可以使用context指定上下文路径，使用dockerfile基于上下文路径指定Dockerfile文件，使用args指定构建参数。例如：
version: "3.8"
services:
webapp:
build:
context: ./dir
dockerfile: Dockerfile-alternate
args:
buildno: 1如果同时指定了build和image。例如：
build: ./dir
image: webapp:tagCompose会在./dir目录下构建一个名为webapp，标签为tag的镜像。
使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，build配置项被忽略。因为docker stack命令不会在部署之前构建镜像。
指定包含Dockerfile的目录路径或git仓库url。该目录是发送给Docker守护进程（Daemon）的构建上下文（context）。当配置的值是相对路径时，它将被解释为相对于Compose配置文件的路径。例如：
build:
context: ./dir指定上下文为Compose配置文件目录下的dir目录。
指定Dockerfile文件。Compose会使用指定的Dockerfile文件构建镜像，但必须要指定构建上下文路径。例如：
build:
context: .
dockerfile: Dockerfile-alternateCompose会使用Compose配置文件所在目录下名为Dockerfile-alternate的Dockerfile文件构建镜像。
添加构建参数，这些只能在构建过程中访问的环境变量。首先在Dockerfile文件中指定参数：
ARG buildno
ARG gitcommithash
RUN echo "Build number: $buildno"
RUN echo "Based on commit: $gitcommithash"然后build中指定参数，以下两种写法都可以：
build:
context: .
args:
buildno: 1
gitcommithash: cdc3b19build:
context: .
args:
- buildno=1
- gitcommithash=cdc3b19这时构建过程中使用的参数的值为args指定的值。在指定构建参数时也可以不指定值，在这种情况下，构建过程中使用的参数的值为运行Compose的环境中的值。例如：
args:
- buildno
- gitcommithash使用布尔值时的注意事项：YMAL中布尔类型的值（"true"、"false"、"yes"、"no"、"on"、"off"）必须用引号引起来，以便解析器将它们解释为字符串。
在3.2版的配置文件格式中加入
指定缓存解析镜像列表。例如：
build:
context: .
cache_from:
- alpine:latest
- corp/web_app:3.14在3.3版的配置文件格式中加入
将元数据以标签的形式添加到生成的镜像中。可以使用数组或字典两种格式。推荐使用反向DNS写法以避免和其他应用的标签冲突。例如：
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"在3.4版的配置文件格式中加入
设置容器网络连接以获取构建过程中的RUN指令。例如：
build:
context: .
network: custom_network_1设置为none可以在构建期间禁用网络连接。例如：
build:
context: .
network: none在3.5版的配置文件格式中加入
指定容器的/dev/shm分区大小。指定的值为表示字节数的整数值或表示字节值的字符串。例如
build:
context: .
shm_size: 10000000build:
context: .
shm_size: '2gb'在3.4版的配置文件格式中加入
指定在Dockerfile中定义的构建阶段，即镜像只构建到指定阶段就停止构建。例如：
build:
context: .
target: prod指定构建阶段为prod，即镜像只构建到prod阶段，prod阶段之后的内容不会被构建。
添加或删除容器内核能力（capability）。完整的capability列表可查看man 7 capabilities。例如，让容器拥有所有内核能力：
cap_add:
- ALL例如，删除NET_ADMIN和SYS_ADMIN能力：
cap_drop:
- NET_ADMIN
- SYS_ADMIN使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，cap_add和cap_drop配置项将被忽略。
为容器指定一个可选的父控制组。例如：
cgroup_parent: m-executor-abcd使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，cgroup_parent配置项将被忽略。
覆盖容器启动后默认执行的命令。可以写成字符串形式。例如：
command: bundle exec thin -p 3000也可以写成JSON数组形式。例如：
command: ["bundle", "exec", "thin", "-p", "3000"]在3.3版的配置文件格式中加入
为每个服务授予对配置（configs）的访问权限。支持short和long两种格式的语法。更多configs信息，参考configs。
注意：该配置（config）必须已存在或者在堆栈文件顶层configs配置项中定义，否则堆栈部署将失败。
short语法仅指定config名称来授予容器访问config的权限并将其挂载到容器的/<config_name>上。source名称和目标挂载点都设置为config名称。例如以下示例，授予了redis服务对configs的my_config和my_other_config的访问权限，其中my_config的值设置到文件./my_config.txt的内容中，my_other_config定义为外部资源，这意味着它已经在Docker中通过运行docker config create命令或其他堆栈部署进行定义，如果外部config不存在，堆栈部署将会失败并显示config not found错误：
version: "3.8"
services:
redis:
image: redis:latest
deploy:
replicas: 1
configs:
- my_config
- my_other_config
configs:
my_config:
file: ./my_config.txt
my_other_config:
external: truelong语法提供了在服务的任务容器内如何创建config的更多粒度：
source：Docker中存在的config名称。
target：指定要挂载到服务的任务容器的文件的路径加名称。如果未指定，默认为/。
uid和gid：指定服务的任务容器所拥有的该文件的UID或GID。如果在LInux中未指定，两者都默认为0。不支持Windows。
mode：以八进制表示法指定要挂载到服务的任务容器的文件权限。例如，0444代表可读。默认值就为0444。config内容已挂载到临时文件系统中，所以不可写，如果设置了可写位将被忽略。可以设置可执行位。如果不熟悉UNIX文件权限模式，可以使用权限计算器 。
例如以下示例，指定config名称为my_config，授予redis服务对my_config的访问权限，指定要挂载到redis服务的任务容器的路径加文件名称为/redis_config，指定UID和GID均为103，指定要挂载到服务的任务容器的文件权限为0440（group-readable），但该redis服务没有访问my_other_config的权限：
version: "3.8"
services:
redis:
image: redis:latest
deploy:
replicas: 1
configs:
- source: my_config
target: /redis_config
uid: '103'
gid: '103'
mode: 0440
configs:
my_config:
file: ./my_config.txt
my_other_config:
external: true可以授予服务访问多个config的权限，并且可以混合long和short语法。定义config并不意味着授予服务对其的访问权限。
指定自定义容器的名称，而不是使用默认名称。例如：
container_name: my-web-container因为Docker容器的名称必须唯一，所以为一个服务指定了自定义容器名称后，该服务不能进行扩展。如果尝试为该服务扩容将会导致错误。
使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，container_name配置项将被忽略。
在3.3版的配置文件格式中加入
在3.8或更高版本文件格式中支持将组托管服务帐户（GMSA）配置与Compose配置文件一起使用。
配置托管服务帐户的凭据规格（credential spec）。此选项仅用于使用Windows容器的服务。credential_spec配置必须采用file://或registry://格式。使用file:时，引用的文件必须存在于Docker数据目录的CredentialSpecs子目录中，在Windows上，Docker数据目录默认为C:\ProgramData\Docker\。以下示例从名为C:\ProgramData\Docker\CredentialSpecs\my-credential-spec.json的文件加载凭证规格：
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凭据规格时，只需用config指定凭据规格。例如：
version: "3.8"
services:
myservice:
image: myimage:latest
credential_spec:
config: my_credential_spec
configs:
my_credentials_spec:
file: ./my-credential-spec.json|指定服务之间的依赖关系，解决服务启动先后顺序问题。指定服务之间的依赖关系，将会导致以下行为：
docker-compose up以依赖顺序启动服务。
docker-compose up SERVICE会自动包含SERVICE的依赖项。
docker-compose stop以依赖顺序停止服务。
例如以下示例：
version: "3.8"
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres启动时会先启动db和redis，最后才启动web。在使用docker-compose up web启动web时，也会启动db和redis，因为在web服务中指定了依赖关系。在停止时也在web之前先停止db和redis。
使用depends_on时的注意事项：
服务不会等待该服务所依赖的服务完全启动之后才启动。例如上例，web不会等到db和redis完全启动之后才启动。
V3版不再支持的condition形式的depends_on。
V3版中，在swarm mode下部署堆栈时，depends_on配置项将被忽略。
在3版的配置文件格式中加入
指定部署和运行服务的相关配置。该配置仅在swarm mode下生效，并只能通过docker stack deploy命令部署，docker-compose up和docker-compose run命令将被忽略。例如：
version: "3.8"
services:
redis:
image: redis:alpine
deploy:
replicas: 6
placement:
max_replicas_per_node: 1
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failuredeploy配置项中包含endpoint_mode、labels、mode、placement、replicas、resources、restart_policy、update_config等子配置项。
在3.2版的配置文件格式中加入
为外部客户端连接到swarm指定服务发现方式：
endpoint_mode: vip：Docker为服务分配了一个前端的虚拟IP，客户端通过该虚拟IP访问网络上的服务。Docker在客户端和服务的可用工作节点之间进行路由请求，而无须关系有多少节点正在参与该服务或这些节点的IP地址或者端口。这是默认设置。
endpoint_mode: dnsrr：DNS轮询（DNSRR），Docker设置服务的DNS条目，以便对服务名称的DNS查询返回IP地址列表，并且客户端通过轮询的方式直接连接到其中之一。
例如：
version: "3.8"
services:
wordpress:
image: wordpress
ports:
- "8080:80"
deploy:
mode: replicated
replicas: 2
endpoint_mode: vip指定服务的标签。这些标签仅在服务上设置，而不在服务的任何容器上设置。例如：
version: "3.8"
services:
web:
image: web
deploy:
labels:
com.example.description: "This label will appear on the web service"指定服务的容器副本模式。可以为：
global：每个swarm节点只有一个该服务容器。
replicated：整个集群中存在指定份数的服务容器副本，为默认值。
例如，指定容器副本模式为global：
version: "3.8"
services:
worker:
image: dockersamples/examplevotingapp_worker
deploy:
mode: global指定constraints和preferences。constraints可以指定只有符合要求的节点上才能运行该服务容器，preferences可以指定容器分配策略。例如，指定集群中只有满足node.rolemanager和engine.labels.operatingsystemubuntu 18.04条件的节点上能运行db服务容器，并且在满足node.labels.zone的节点上均匀分配：
version: "3.8"
services:
db:
image: postgres
deploy:
placement:
constraints:
- "node.role==manager"
- "engine.labels.operatingsystem==ubuntu 18.04"
preferences:
- spread: node.labels.zone在3.8版的配置文件格式中加入
如果服务的容器副本模式为replicated（默认），可以指定每个节点上运行的最大容器副本数量。当指定的容器副本数量大于最大容器副本数量时，将引发no suitable node (max replicas per node limit exceed)错误。例如：
version: "3.8"
services:
worker:
image: dockersamples/examplevotingapp_worker
networks:
- frontend
- backend
deploy:
mode: replicated
replicas: 6
placement:
max_replicas_per_node: 1如果服务的容器副本模式为replicated（默认），指定运行的容器副本数量。例如：
version: "3.8"
services:
worker:
image: dockersamples/examplevotingapp_worker
networks:
- frontend
- backend
deploy:
mode: replicated
replicas: 6配置资源限制。例如，指定redis服务使用的cpu份额为25%到50%，内存为20M到50M：
version: "3.8"
services:
redis:
image: redis:alpine
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M在V3版Compose配置文件中的改变：resources取代了V3版之前的Compose配置文件中旧的资源限制的配置项，包括cpu_shares、cpu_quota、cpuset、mem_limit、memswap_limit、mem_swappiness。
在非swarm mode容器上设置资源限制：此处的resources配置项只有用于deploy配置项之下和swarm mode。如果要在非swarm mode部署中设置资源限制，需使用V2版Compose配置文件中CPU、memory和其他资源的配置项。
指定容器的重启策略。代替restart。有以下配置选项：
condition：重启策略。值可以为none、on-failure或any，默认为any。
delay：尝试重启的等待时间。指定为持续时间（durations）。默认值为0。
max_attempts：重启最多尝试的次数，超过该次数将放弃。默认为永不放弃。如果在window配置的时间之内未成功重启，则此次尝试不计入max_attempts的值。
window：在决定重启是否成功之前的等待时间。指定为持续时间（durations）。默认值为立即决定。
例如，指定重启策略为失败时重启，等待5s，重启最多尝试3次，决定重启是否成功前的等待时间为120s：
version: "3.8"
services:
redis:
image: redis:alpine
deploy:
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 120s在3.7版的配置文件格式中加入
配置在更新失败的情况下如何回滚服务。有以下配置选项：
parallelism：一次回滚的容器数量。如果设置为0，则所有容器同时回滚。
delay：每个容器组之间的回滚所等待的时间。默认值为0s。
failure_action：回滚失败后的行为。有continue和pause两种，默认值为pause。
monitor：每次任务更新后监视失败的时间（ns|us|ms|s|m|h）。默认值为0s。
max_failure_ratio：在回滚期间能够容忍的最大失败率。默认值为0。
order：设置回滚顺序。stop-first为在开启新任务之前停止旧任务，start-first为首先启动新任务，和正在运行任务短暂重叠，默认值为stop-first。
配置如何更新服务。该配置对滚动更新很有用。有以下配置选项：
parallelism：一次更新的容器数量。
delay：更新一组容器之间的等待时间。
failure_action：更新失败后的行为。有continue、rollback和pause三种，默认值为pause。
monitor：每次任务更新后监视失败的时间（ns|us|ms|s|m|h）。默认值为0s。
max_failure_ratio：在更新期间能够容忍的最大失败率。
order：设置更新顺序。stop-first为在开启新任务之前停止旧任务，start-first为首先启动新任务，和正在运行任务短暂重叠，默认值为stop-first。注意该配置项在3.4版的配置文件格式中加入，仅支持3.4或更高版本。
例如，指定每次更新2个容器，更新等待时间10s，更新顺序为先停止旧任务再开启新任务：
version: "3.8"
services:
vote:
image: dockersamples/examplevotingapp_vote:before
depends_on:
- redis
deploy:
replicas: 2
update_config:
parallelism: 2
delay: 10s
order: stop-first以下为支持docker-compose up和docker-compose run，不支持docker stack deploy或deploy配置项的配置项：
build
cgroup_parent
container_name
devices
tmpfs
external_links
links
network_mode
restart
security_opt
userns_mode指定设备映射列表。与Docker客户端create的--device选项类似。例如：
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，devices配置选项将被忽略。
自定义DNS服务器。可以是一个值或一个列表。例如：
dns: 8.8.8.8dns:
- 8.8.8.8
- 9.9.9.9自定义DNS搜索域。可以是一个值或一个列表。例如：
dns_search: example.comdns_search:
- dc1.example.com
- dc2.example.com覆盖默认的入口命令。注意设置entrypoint会覆盖所有在服务镜像上使用Dockerfile的ENTRYPOINT指令设置的默认入口命令，并清除掉服务镜像上任何使用Dockerfile的CMD指令设置的启动容器时默认执行的命令。可以写成字符串形式，例如：
entrypoint: /code/entrypoint.sh也可以写成JSON数组形式，例如：
entrypoint: ["php", "-d", "memory_limit=-1", "vendor/bin/phpunit"]从文件中获取环境变量。可以是一个值或一个列表。例如：
env_file: .envenv_file:
- ./common.env
- ./apps/web.env
- /opt/runtime_opts.env如果指定了Compose配置文件，env_file路径为相对于该文件所在目录的路径。如果环境文件中设置有与environment选项同名的变量，将以后者为准，无论这些变量的值是空还是未定义。其中环境文件每行都以VAR=VAL格式声明环境变量，以#开头的行被解析为注释，和空行一样将被忽略。环境文件示例如下：
# Set Rails/Rack environment
RACK_ENV=development如果变量的值被引号引起来（通常是shell变量），则引号也包含在传递给Compose的值中。如果以列表的形式同时指定了多个环境文件，列表中文件的顺序对于给多次出现的环境变量确定值十分重要，且列表中的文件是从上到下处理的。如果指定了多个环境文件且有至少两个文件声明了相同名称但不同值的环境变量，那么指定列表中顺序靠下的文件将覆盖顺序靠上的文件中的相同名称的环境变量的值。例如：
services:
some-service:
env_file:
- a.env
- b.env如果a.env中有VAR=1，b.env中有VAR=2，则最终$VAR=2。
注意：这里所说的环境变量是针对宿主机的Compose而言的，如果在服务中指定了build配置项，那么这些变量并不会进入构建过程中，如果要定义构建时用的环境变量首选build的arg子选项。
设置环境变量。可以使用数组或字典两种格式。任何布尔类型的值都必须用引号引起来，以便解析器将它们解释为字符串。值设置了键没设置值的环境变量可以在运行Compose的主机环境中解析它们的值，这对于使用密钥和特定于主机的值用处很大。例如：
environment:
RACK_ENV: development
SHOW: 'true'
SESSION_SECRET:environment:
- RACK_ENV=development
- SHOW=true
- SESSION_SECRET注意：这里所说的环境变量是针对宿主机的Compose而言的，如果在服务中指定了build配置项，那么这些变量并不会进入构建过程中，如果要定义构建时用的环境变量首选build的arg子选项。
暴露指定端口，但不映射到宿主机，只被连接的服务访问。只能指定内部端口。例如：
expose:
- "3000"
- "8000"链接到docker-compose.yml外部的容器，甚至并非Compose管理的外部容器，特别是对于提供共享或公共服务的容器。在同时指定容器名称和链接别名（CONTAINER:ALIAS）时，external_links与旧版本中的配置项links有类似的语义。例如：
external_links:
- redis_1
- project_db_1:mysql
- project_db_1:postgresql注意：Compose项目里面的容器连接到外部容器的前提条件是外部容器中必须至少有一个容器连接到与项目内的服务的同一个网络里面。建议使用networks代替旧版本中的配置项Links。
使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，external_links配置项将被忽略。
添加主机名到IP的映射。使用和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配置运行检查以确定服务容器是否健康。支持以下配置选项：
test：指定健康检测的方法。
interval：启动容器到进行健康检查的间隔时间以及两次健康检查的间隔时间。
timeout：单次健康检查的超时时间，超过该时间该次健康检查失败。
retries：健康检查失败后的最大重试次数，重试了最大次数依然失败，容器将被视为unhealthy。
start_period：为需要时间引导的容器提供的初始化时间，在此期间检查失败将不计入最大重试次数，但是如果在启动期间健康检查成功，则会将容器视为已启动，并且所有连续失败将计入最大重试次数。
其中interval、timeout和start_period都被指定为持续时间（durations）。start_period是在3.4版的配置文件格式中加入。test必须是字符串或JSON数组格式。如果是JSON数组格式，第一项必须是NONE、CMD或CMD-SHELL其中之一。如果是字符串格式，则等效于指定CMD-SHELL后跟该字符串的JSON数组格式。
例如以下示例，指定检测方法为访问http://localhost，健康检查间隔时间为1m30s，健康检查超时时间为10s，重试次数为3，启动容器后等待健康检查的初始化时间为40s：
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 1m30s
timeout: 10s
retries: 3
start_period: 40s例如以下示例，两种形式等效：
test: ["CMD-SHELL", "curl -f http://localhost || exit 1"]test: curl -f https://localhost || exit 1使用disable: true可以设置镜像禁用所有健康检查，相对于test: ["NONE"]。例如：
healthcheck:
disable: true指定要从中启动容器的镜像。可以写仓库/标签（repository/tag）或镜像ID。示例如下：
image: redisimage: ubuntu:18.04image: tutum/influxdbimage: example-registry.com:4000/postgresqlimage: a4bc65fd如果镜像不存在，Compose会自动拉取镜像，除非指定了build，这种情况下会使用指定选项构建镜像并给镜像打上指定标签。
在3.7版的配置文件格式中加入
在容器内运行一个初始化程序以转发信号并获取进程。设置为true即可为服务启动此功能。例如：
version: "3.8"
services:
web:
image: alpine:latest
init: true注意：默认使用的初始化二进制文件是Tini，并安装在主机守护进程的/usr/libexec/docker-init。可以通过Daemon configuration file中的init-path将守护进程配置为使用自定义的初始化二进制文件 。
指定容器的隔离技术。Linux上只支持default值。Windows上支持default、process和hyperv这三个值。
将元数据以标签的形式添加到容器中。可以使用数组或字典两种格式。例如：
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"警告：--link是Docker的遗留功能。它最终可能会被删除。建议您使用用户自定义网络代替--link来进行两个容器间的通信。用户自定义的网络不支持--link在容器之间共享的环境变量的功能。但是可以使用例如数据卷之类的其他机制以更可控的方式在容器之间共享环境变量。
链接到其他服务中的容器。可以使用"SERVICE:ALIAS"或"SERVICE"的格式，其中SERVICE为服务名称，ALIAS为链接别名。例如：
web:
links:
- "db"
- "db:database"
- "redis"链接服务的容器可以通过与别名相同的主机名访问，如果未指定别名，则可以使用服务名。默认情况下，不需要链接即可使服务进行通信，任何服务都可以使用该服务的名称访问任何其他服务。链接也可以和depends_on一样表示服务之间的依赖关系 ，因此可以确定服务启动的顺序。
注意：如果同时定义链接和网络，则它们之间具有链接的服务必须共享至少一个公共网络才能进行通信。
使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，links配置项将被忽略。
服务的日志配置。例如：
logging:
driver: syslog
options:
syslog-address: "tcp://192.168.0.42:123"driver配置项指定服务容器的日志驱动，与docker run中的--log-driver选项一样。默认值为json-file，这里列举三种日志驱动类型：
driver: "json-file"driver: "syslog"driver: "none"使用options配置项为日志驱动指定日志记录选项，与docker run中的--log-opt选项一样。例如：
driver: "syslog"
options:
syslog-address: "tcp://192.168.0.42:123"默认日志驱动json-file具有限制日志存储量的选项。例如以下示例，max-size设置最大存储大小为200k，max-file设置存储的最大文件数为10，随着日志超过最大限制，将删除较旧的日志文件以允许存储新日志：
options:
max-size: "200k"
max-file: "10"设置网络模式。使用和Docker客户端中的--network的参数一样的值，格式为service:[service name]。可以指定使用服务或者容器的网络。示例如下：
network_mode: "bridge"network_mode: "host"network_mode: "none"network_mode: "service:[service name]"network_mode: "container:[container name/id]"注意事项：
在swarm mode下部署堆栈时，该选项将被忽略。
network_mode: "host"不能与links配置项混用。
指定所加入的网络。需要在顶层networks配置项中引入具体的网络信息。例如：
services:
some-service:
networks:
- some-network
- other-network
networks:
some-network:
other-network:指定服务在此网络上的别名（备用主机名）。同一网络上的其他容器可以使用服务名称或此别名来连接到服务的任何一个容器。由于aliases属于网络范围，因此同一服务在不同的网络上可以具有不同的别名。例如：
services:
some-service:
networks:
some-network:
aliases:
- alias1
- alias3
other-network:
aliases:
- alias2在以下示例中，提供了web、worker和db三个服务，以及new和legacy两个网络：
version: "3.8"
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:在该例中，可以通过主机名db或database在new网络上访问db服务，通过db或mysql在legacy网络上访问db服务。
注意：网络范围内的别名可以被多个容器甚至多个服务共享。如果是这样，则不能保证名称恰好解析到哪一个容器。
加入网络后，为此服务的容器指定一个静态IP地址。在顶层networks配置项中的相应网络配置必须有子网配置覆盖每个静态地址的ipam配置。例如：
version: "3.8"
services:
app:
image: nginx:alpine
networks:
app_net:
ipv4_address: 172.16.238.10
ipv6_address: 2001:3984:3989::10
networks:
app_net:
ipam:
driver: default
config:
- subnet: "172.16.238.0/24"
- subnet: "2001:3984:3989::/64"注意：如果需要IPv6寻址，则必须使用V2.x版本的Compose配置文件并设置顶层networks配置项下的enable_ipv6选项。在当前swarm mode下IPv6选项不会起作用。
跟主机系统共享进程命名空间。
pid: "host"将PID模式设置为主机PID模式，打开该选项的容器之间，以及容器和宿主机操作系统之间可以通过进程ID来相互访问和操作。
暴露端口。注意端口映射与network_mode: host不兼容。支持short和long两种格式的语法。short语法可以使用HOST:CONTAINER的格式指定端口映射，也可以指定容器端口，宿主机会随机选择临时端口进行映射。例如：
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"注意：当使用HOST:CONTAINE格式来映射端口时，如果使用的容器端口小于60可能会得到错误得结果，因为YAML将会解析xx:yy这种数字格式为60进制，因此建议始终采用字符串格式来指定端口映射。
long语法支持配置short语法中不支持的附加字段。这些附加字段如下：
target：指定容器内的端口。
published：指定公开的端口。
protocol：指定端口协议（tcp或udp）。
mode：使用host在每个节点公开一个主机端口，或使用ingress对swarm mode端口进行负载均衡。
示例如下：
ports:
- target: 80
published: 8080
protocol: tcp
mode: hostlong语法在3.2版的配置文件格式中加入
指定重启策略。例如想要在容器退出时总是会重启容器，指定以下重启策略：
restart: always一共支持以下重启策略：
no：在任何情况下都不会重启容器。默认的重启策略。
always：在容器退出时总是重启容器。
on-failure：在容器以非0状态码退出时才会重启。
unless-stopped：在容器退出时总是重启容器，但是不考虑在Docker守护进程启动时就已经停止了的容器。
使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，restart配置项将被忽略。
为每个服务授予对保密数据（secrets）的访问权限。支持short和long两种格式的语法。更多secrets信息，参考secrets。
使用docker stack deploy时的注意事项：该保密数据（secret）必须已存在或者在Compose配置文件顶层secrets配置项中定义，否则堆栈部署将失败。
short语法仅指定secret名称来授予容器访问secret数据的权限并将其挂载到容器的/run/secrets/<secret_name>上。source名称和目标挂载点都设置为secret名称。例如以下示例，授予了redis服务对secrets的my_secret和my_other_secret的访问权限，其中my_secret的值设置到文件./my_secret.txt的内容中，my_other_secret定义为外部资源，这意味着它已经在Docker中通过运行docker secret create命令或其他堆栈部署进行定义，如果外部secret不存在，堆栈部署将会失败并显示secret not found错误：
version: "3.8"
services:
redis:
image: redis:latest
deploy:
replicas: 1
secrets:
- my_secret
- my_other_secret
secrets:
my_secret:
file: ./my_secret.txt
my_other_secret:
external: truelong语法提供了在服务的任务容器内如何创建secret的更多粒度：
source：Docker中存在的secret名称。
target：指定要挂载到服务的任务容器的/run/secrets/中的文件名称。如果未指定，默认为source的值。
uid和gid：指定服务的任务容器的/run/secrets/中所拥有的该文件的UID或GID。如果未指定，两者都默认为0。
mode：以八进制表示法指定要挂载到服务的任务容器的/run/secrets/中的文件权限。例如，0444代表可读。默认值在Docker 1.13.1为0000，在较新版本为0444。secret内容已挂载到临时文件系统中，所以不可写，如果设置了可写位将被忽略。可以设置可执行位。如果不熟悉UNIX文件权限模式，可以使用权限计算器 。
例如以下示例，指定secret名称为my_secret，授予redis服务对my_secret的访问权限，指定要挂载到redis服务的任务容器的/run/secrets/中的文件名称为redis_secret，指定UID和GID均为103，指定要挂载到服务的任务容器的/run/secrets/中的文件权限为0440（group-readable），但该redis服务没有访问my_other_secret的权限：
version: "3.8"
services:
redis:
image: redis:latest
deploy:
replicas: 1
secrets:
- source: my_secret
target: redis_secret
uid: '103'
gid: '103'
mode: 0440
secrets:
my_secret:
file: ./my_secret.txt
my_other_secret:
external: true可以授予服务访问多个secret的权限，并且可以混合long和short语法。定义secret并不意味着授予服务对其的访问权限。
为每个容器覆盖默认的标签（label）。例如配置标签中的用户名和角色名：
security_opt:
- label:user:USER
- label:role:ROLE使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，security_opt配置项将被忽略。
指定在发送SIGKILL之前，如果容器无法处理SIGTERM或使用stop_signal指定的任何停止信号时，试图停止该容器所需要的等待时间。默认情况下，stop在发送SIGKILL之前等待10秒以退出容器。时间指定为duration。具体示例如下：
stop_grace_period: 1sstop_grace_period: 1m30s设置停止容器的信号。默认使用SIGTERM停止容器。例如指定SIGUSR1信号：
stop_signal: SIGUSR1在容器中设置的内核参数。可以使用数组或字典两种格式。例如指定连接数为1024和开启TCP的syncookies：
sysctls:
net.core.somaxconn: 1024
net.ipv4.tcp_syncookies: 0sysctls:
- net.core.somaxconn=1024
- net.ipv4.tcp_syncookies=0使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，sysctls配置项要求Docker Engine 19.03或以上。
在3.6版的配置文件格式中加入
挂载一个临时文件系统到容器内部。可以是一个值或一个列表。例如：
tmpfs: /run
1.
tmpfs:
- /run
- /tmp在容器内挂载一个临时文件系统。Size可以指定挂载的tmpfs大小，以字节为单位。默认情况下不受限制。例如：
- type: tmpfs
target: /app
tmpfs:
size: 1000使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时使用3至3.5版本的Compose配置文件，tmpfs配置项将被忽略。
覆盖容器的默认ulimit值。可以单一地将限制值设为一个整数，也可以将soft/hard限制指定为映射。例如，指定最大进程数为65535，指定文件句柄数，其中软限制为20000，系统硬限制为40000，软限制应用可以随时修改，不能超过硬限制，硬限制只能root用户提高：
ulimits:
nproc: 65535
nofile:
soft: 20000
hard: 40000指定用户命名空间模式。如果Docker守护进程配置了用户名称空间，则禁用此服务的用户名称空间。以下是使用主机上的用户命名空间的配置示例：
userns_mode: "host"使用docker stack deploy时的注意事项：在swarm mode下部署堆栈时，userns_mode配置项将被忽略。
指定所挂载的主机路径或数据卷名称。支持short和long两种格式的语法。可以将主机路径作为单个服务的一部分进行挂载，而无需在顶层volumes配置项中定义。但是如果想要在多个服务之间重用数据卷，需要在顶层volumes配置项中定义一个数据卷名称。
在3版的配置文件格式中的变化：在顶层volumes配置项中定义了数据卷名称并从每个服务的volumes列表中引用了该数据卷。这将替代早期版本的Compose配置文件格式中的volumes_from配置项。
short语法使用通用的[SOURCE:]TARGET[:MODE]格式，SOURCE可以是主机路径或数据卷名称，TARGET为挂载数据卷的容器路径，MODE可以为ro只读模式或rw读写模式（默认）。可以在主机上挂载相对路径，该路径相对于正在使用的Compose配置文件的目录进行扩展，相对路径应始终以.或..开头。例如：
volumes:
#只指定一个路径，Docker会自动在创建一个数据卷（这个路径是容器内部的）
- /var/lib/mysql
#使用绝对路径挂载数据卷
- /opt/data:/var/lib/mysql
#使用基于Compose配置文件的相对路径作为数据卷挂载到容器
- ./cache:/tmp/cache
#使用基于root用户的相对路径作为数据卷挂载到容器
- ~/configs:/etc/configs/:ro
#使用已经存在命名的数据卷挂载到容器
- datavolume:/var/lib/mysqllong语法支持配置以下short语法中不支持的附加字段：
type：挂载类型，可以为volume、bind、tmpfs或npipe。
source：挂载源，在主机上用于绑定挂载的路径或定义在顶层volumes配置项中的数据卷名称。不适用于tmpfs挂载类型。
target：数据卷挂载在容器中的路径。
read_only：设置数据卷为只读。
bind：配置额外的bind选项。
propagation：用于绑定的传播模式。
volume：配置额外的volume选项。
nocopy：创建数据卷时禁止从容器复制数据。
tmpfs：配置额外的tmpfs选项。
size：tmpfs挂载的大小，以字节为单位。
consistency：挂载的一致性要求，可以为consistent、cached或delegated。其中consistent表示主机和容器具有相同视图。cached表示读取缓存，主机视图是权威的。delegated表示读写缓存，容器视图是权威的。
例如：
version: "3.8"
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:此外，还有domainname、hostname、ipc、mac_address、privileged、read_only、shm_size、stdin_open、tty、user和working_dir这些配置项。它们都是单值配置，和docker run中的对应选项类似。注意mac_address是旧版本配置项。例如：
#指定容器中运行应用的用户名
user: postgresql
#指定容器的工作目录
working_dir: /code
#指定容器中的搜索域名
domainname: foo.com
#指定容器中的主机名
hostname: foo
ipc: host
#指定容器中的mac地址
mac_address: 02:42:ac:11:65:43
#指定容器为特权容器
privileged: true
#指定以只读模式挂载容器的root文件系统，不能对容器内容进行修改
read_only: true
#设置/dev/shm分区的大小
shm_size: 64M
#打开标准输入，可以接受外部输入
stdin_open: true
#分配tty设备用来支持终端登录
tty: true虽然可以声明即时生效的数据卷作为服务声明的一部分，但这部分可以通过顶层volumes配置项定义一个数据卷以实现在多个服务之间重用，并且可以使用docker命令行或API轻松进行检索和检查。例如以下示例，数据库的数据目录作为数据卷与另一个服务共享以便定期备份：
version: "3.8"
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配置项下的条目可以为空，这种情况下配置的默认驱动，默认驱动在大多数情况下为local驱动。下面就对数据卷的相关配置项进行一个总结。
指定该数据卷所要使用的数据卷驱动。默认为Docker Engine中配置使用的无论哪种驱动，大多数情况下为local驱动。如果驱动不可用，则引擎会在docker-compose up尝试创建数据卷时返回一个错误。以下为指定数据卷驱动的示例：
driver: foobar以键值对的形式指定用来传递给该数据卷所使用的数据卷驱动的列表选项。这些选项取决于数据卷驱动，可以参考数据卷驱动程序文档。例如：
volumes:
example:
driver_opts:
type: "nfs"
o: "addr=10.40.0.199,nolock,soft,rw"
device: ":/docker/example"指定该数据卷是否是外部数据卷。如果设置为true，则指定该数据卷是在Compose外部创建的。由于docker-compose up不会尝试创建该数据卷，如果该数据卷不存在则会引发错误。在3.3及以下版本的Compose配置文件格式中，external配置项不能与包括driver、driver_opts和labels在内的其他数据卷配置项同时使用，在3.4及以上版本中则没有此限制。例如以下示例，Compose不会尝试创建一个名为[projectname]_data的数据卷，而是查找一个现存的被简单称为data的数据卷并将其挂载到db服务的容器中：
version: "3.8"
services:
db:
image: postgres
volumes:
- data:/var/lib/postgresql/data
volumes:
data:
external: true通过external配置项下的name配置项可以指定数据卷的名称，该名称与Compose配置文件中用于引用数据卷的名称区分开来。例如：
volumes:
data:
external:
name: actual-name-of-volume不过external配置项下的name配置项在3.4版的配置文件格式中就已经被弃用了，可以用name配置项替代。
使用docker stack deploy时的注意事项：如果使用docker stack deploy代替docker-compose up以swarm mode启动应用，则会创建不存在的外部数据卷。在swarm mode下，服务定义数据卷后将自动创建该卷。由于服务任务已在新节点上安排，因此SwarmKit将在本地节点上创建数据卷。
将元数据以标签的形式添加到容器中。可以使用数组或字典两种格式。例如：
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"在3.4版的配置文件格式中加入
为该数据卷设置一个自定义名称。例如：
version: "3.8"
volumes:
data:
name: my-app-data可以和external配置项一起使用。例如：
version: "3.8"
volumes:
data:
external: true
name: my-app-data通过顶层networks配置项可以指定要创建的网络。下面就对网络的相关配置项进行一个总结。