包含
使用`include`，您可以将单独的`compose.yaml`文件直接包含到当前的`compose.yaml`文件中。这使得将复杂的应用程序模块化为子Compose文件变得很容易，这反过来又使应用程序配置更简单、更明确。
顶级元素`include`有助于直接在配置文件的组织中反映负责代码的工程团队。它还解决了`extends`和`merge`提出的相对路径问题。
`include`部分中列出的每个路径都作为单个Compose应用程序模型加载，并具有其自己的项目目录，以便解析相对路径。
包含的Compose应用程序加载后，所有资源都将复制到当前的Compose应用程序模型中。
注意
`include`递归应用，因此包含的Compose文件声明其自身的`include`部分，也会导致包含这些其他文件。
示例
include:
- my-compose-include.yaml #with serviceB declared
services:
serviceA:
build: .
depends_on:
- serviceB #use serviceB directly as if it was declared in this Compose file`my-compose-include.yaml`管理`serviceB`，其中详细说明了一些副本、用于检查数据的Web UI、隔离的网络、用于数据持久化的卷等。依赖于`serviceB`的应用程序不需要了解基础设施细节，并将Compose文件用作它可以依赖的构建块。
这意味着管理`serviceB`的团队可以重构其自己的数据库组件以引入其他服务，而不会影响任何依赖团队。这也意味着依赖团队不需要在其运行的每个Compose命令上包含额外的标志。
包含和覆盖
如果来自`include`的任何资源与包含的Compose文件中的资源冲突，Compose将报告错误。此规则可防止与包含的compose文件作者定义的资源发生意外冲突。但是，在某些情况下，您可能希望调整包含的模型。这可以通过向include指令添加覆盖文件来实现。
include:
- path :
- third-party/compose.yaml
- override.yaml # local override for third-party model这种方法的主要限制是您需要为每个include维护一个专用的覆盖文件。对于包含多个include的复杂项目，这将导致许多Compose文件。
另一个选项是使用`compose.override.yaml`文件。当声明相同的资源时，将拒绝来自使用`include`的文件的冲突，但全局Compose覆盖文件可以覆盖生成的合并模型，如下例所示。
主`compose.yaml`文件
include:
- team-1/compose.yaml # declare service-1
- team-2/compose.yaml # declare service-2覆盖`compose.override.yaml`文件
services:
service-1:
# override included service-1 to enable debugger port
ports:
- 2345:2345
service-2:
# override included service-2 to use local data folder containing test data
volumes:
- ./data:/data组合在一起，这使您可以从第三方可重用组件中受益，并根据您的需求调整Compose模型。