前言

本文翻译自官方文档。

Compose应用程序模型

Compose是一个用于定义和运行多容器Docker应用程序的工具。使用Compose，您可以通过compose.yml文件来配置应用程序的服务，然后，使用一个命令，从配置中创建并启动所有服务。compose.yml文件的编写规范由Compose规范定义。Compose规范允许您定义与平台无关的基于容器的应用程序。这样的应用程序被设计为一组容器，这些容器必须与足够的共享资源和通信通道一起运行。

• 服务：应用程序的组件被定义为服务。服务是一个抽象概念，通过一次或多次运行相同的容器镜像和配置在平台上实现。
• 网络：服务通过网络相互通信。在Compose规范中，网络是一个平台功能抽象，用于在连接在一起的服务中的容器之间建立IP路由
• 卷：服务将持久数据存储和共享到卷中。规范将这种持久化数据描述为具有全局选项的高级文件系统挂载。实际的特定于平台的实现细节被分组到卷定义中，并且可能部分地在某些平台上实现。
• 配置：有些服务需要依赖于运行时或平台的配置数据。为此，规范定义了一个专用的配置概念。从服务容器的角度来看，配置与卷类似，因为它们是挂载到容器中的文件。但实际的定义涉及不同的平台资源和服务，这些资源和服务是由这种类型抽象出来的。
• 项目：项目是应用程序规范在平台上的单独部署。使用顶级名称属性设置的项目名称用于将资源分组在一起，并将它们与其他应用程序或具有不同参数的相同Compose指定应用程序的其他安装隔离开来。

Compose规范

顶层属性

顶级属性是由规范定义的，用于向后兼容。它只是提供信息。

service

• build：指定用于从源创建容器镜像的构建配置，请看下文构建规范。
• image：指定要从哪个镜像启动容器。

    image: redisimage: redis:5image: redis@sha256:0ed5d5928d4737458944eb604cc8509e245c3e19d02ad83935398bc4b991aac7image: library/redisimage: docker.io/library/redisimage: my_private.registry:5000/redis

• command：用于覆盖容器镜像声明的默认命令

command: bundle exec thin -p 3000

• configs：见下文configs
• container_name：指定自定义容器名称的字符串，如果Compose文件指定了container_name，则Compose不会将服务扩展到一个容器之外。
• depends_on：表示服务之间的启动和关闭依赖关系。

services:web:build: .depends_on:- db- redisredis:image: redisdb:image: postgres

• deploy：见下文部署规范
• develop：见下文开发规范
• entrypoint：声明了服务容器的默认入口点。这将覆盖服务的Dockerfile中的ENTRYPOINT指令。

entrypoint: /code/entrypoint.sh

• env_file：见下文环境变量
• environment：见下文环境变量
• extends：见下文多compose.yml文件共享与扩展
• ports：公开容器端口

ports:- "3000"- "3000-3005"- "8000:8000"- "9090-9091:8080-8081"- "49100:22"- "8000-9000:80"- "127.0.0.1:8001:8001"- "127.0.0.1:5000-5010:5000-5010"- "6060:6060/udp"

• profiles：见下文Profiles
• restart：定义平台在容器终止时应用的策略

    restart: "no"restart: alwaysrestart: on-failurerestart: unless-stopped

• volumes：定义可由服务容器访问的挂载主机路径或命名卷

services:backend:image: example/backendvolumes:- type: volumesource: db-datatarget: /datavolume:nocopy: true- type: bindsource: /var/run/postgres/postgres.socktarget: /var/run/postgres/postgres.sockvolumes:db-data:

network

• driver：指定该网络应使用哪个驱动程序

networks:db-data:driver: overlay

• attachable：如果attachable设置为true，那么除了服务之外，独立容器应该能够连接到这个网络。如果一个独立容器连接到网络，它可以与服务和其他也连接到网络的独立容器通信。

networks:mynet1:driver: overlayattachable: true

• external：如果设置为true
  • 指定在应用程序生命周期之外维护该网络的生命周期。Compose不会尝试创建这些网络，如果不存在则返回错误。
  • 除了名称以外的所有其他属性都无关紧要。如果Compose检测到任何其他属性，它会将Compose文件视为无效而拒绝。

services:proxy:image: example/proxynetworks:- outside- defaultapp:image: example/appnetworks:- defaultnetworks:outside:external: true

• internal：默认情况下，Compose提供到网络的外部连接。当该属性设置为true时，允许您创建外部隔离的网络。
• name：为网络设置自定义名称

networks:network1:name: my-app-net

它也可以与外部属性一起使用来定义Compose应该检索的平台网络：

networks:network1:external: truename: "${NETWORK_ID}"

volumes

• external：
  • 指定此卷已经存在于平台上，并且其生命周期在应用程序生命周期之外进行管理。然后Compose不会创建卷，如果卷不存在则返回错误。
  • 除了名称以外的所有其他属性都无关紧要。如果Compose检测到任何其他属性，它会将Compose文件视为无效而拒绝。

services:backend:image: example/databasevolumes:- db-data:/etc/datavolumes:db-data:external: true

• name：设置卷的自定义名称

volumes:db-data:name: "my-app-data"

configs

如有需要可查看官网

secrets

如有需要可查看官网

环境变量

使用Compose，您可以通过多种方式在容器中设置环境变量。您既可以使用Compose文件，也可以使用CLI。

.env文件

Docker Compose中的.env文件是一个文本文件，用于定义环境变量，这些变量在运行Docker Compose up时应该对Docker容器可用。该文件通常包含环境变量的键值对，它允许您在一个地方集中和管理配置。如果需要存储多个环境变量，.env文件很有用。.env文件是在容器中设置环境变量的默认方法。env文件应该放在项目目录的根目录中，紧邻compose.yaml文件。

$ cat .env
TAG=v1.5

在compose.yml中可以直接引用.env文件中定义的变量：

$ cat compose.yml
services:web:image: "webapp:${TAG}"

您可以在撰写中使用多个.env文件。Docker Compose会按照指定的顺序读取它们。如果同一个变量在多个文件中定义，最后一个定义优先：

services:webapp:image: my-webapp-imageenv_file:- .env- .env.override

.env文件的语法如下：

• 以#开头的行被当作注释处理，并被忽略。
• 空白行江被忽略
• 值类型应该被加引号，插值类型不加引号
• ${VAR:-default} ：VAR的值已设置且不为空，否则VAR的值为default
• ${VAR-default}：VAR的值已设置，否则VAR的值为default
• ${VAR:?error}：VAR的值已设置且不为空，否则异常退出
• ${VAR?error}：VAR的值已设置，否则异常退出
• ${VAR:+replacement}：如果VAR的值已设置且非空，则替换，否则为空
• ${VAR+replacement}：如果VAR的值已设置且非空，则替换，否则为空

environment属性

您可以直接在Compose文件中设置环境变量，而无需使用.env文件，在Compose .yml中使用environment属性。。

web:environment:- DEBUG=1

主机shell中的环境变量

您可以在主机或执行docker compose命令的shell环境中使用现有的环境变量。如果未设置环境变量，Compose将使用空字符串代替。

Profiles（剖面）

通过剖面可以有选择地启动服务，帮助您调整Compose应用程序模型，以适应各种用途和环境。这是通过将每个服务分配给零个或多个剖面来实现的。服务通过profiles属性实现剖面，该属性接受一个剖面名称数组：

services:frontend:image: frontendprofiles: [frontend]phpmyadmin:image: phpmyadmindepends_on: [db]profiles: [debug]backend:image: backenddb:image: mysql

启动剖面

• 启动指定剖面

docker compose --profile debug up

• 启动多个剖面

docker compose --profile frontend --profile debug up

自动启动剖面和依赖项解析

如果在使用docker compose up时没有指定剖面，则只启动没有profiles属性的服务，此外，docker compose up不会启动不同剖面的依赖项，这意味着目标服务依赖的任何其他服务都应该：

• 共享一个相同的剖面
• 或通过显式的指定剖面来启动

多compose.yml文件共享与扩展

• 分块
• 扩展
• 合并
• 包含

构建规范

Compose可以从service下的build属性和image属性构建服务：

• build：从自定义构建定义构建服务
• image：从已存在镜像构建服务

不要同时使用build和image属性，当这两个属性同时出现时，Compose会有一个默认的处理逻辑，并且这个逻辑用户可以自定义配置。

构建属性

build属性值可以是以下两种类型：

• 构建上下文的路径字符串：在这种情况下Compose会在这个上下文中寻找一个规范的Dockerfile来进行构建。
• 详细的构建定义：在这种情况下可以指定构建参数。

使用字符串语法，构建上下文可以构建为：

• 一个相对路径。该路径必须为目录，且必须包含Dockerfile：

services:webapp:build: ./dir

• Git存储库URL：

services:webapp:build: https://github.com/mycompany/example.git#branch_or_tag:subdirectory

build也可以是一个对象，其字段定义如下：

• context：定义了一个包含Dockerfile的目录的路径，或者一个指向Git仓库的URL。

build:context: ./dir

• dockerfile：指定Dockerfile：

build:context: .dockerfile: webapp.Dockerfile

• dockerfile_inline：将Dockerfile内容定义为Compose文件中的内联字符串，该属性不能和dockerfile属性同时出现：

build:context: .dockerfile_inline: |FROM baseimageRUN some command

• args：定义构建参数，即Dockerfile的ARG值：

build:context: .args:GIT_COMMIT: cdc3b19

• target：定义要构建的阶段：

build:context: .target: prod

此外还有许多属性，详情请看官方文档。

部署规范

部署规范用于定义在部署时的资源配置等元数据，详情请看官方文档。

开发规范

开发规范用于定义本地开发时的开发钩子，以便加快本地开发工作流速度，详情请看官方文档。

Compose指令

请查阅官方文档。