配置文件

目录

通过配置文件，您可以定义一组活动的配置文件，以便根据不同的用途和环境调整您的 Compose 应用程序模型。

顶级元素 services 支持一个 `profiles` 属性来定义一个命名配置文件列表。没有 `profiles` 属性的服务始终处于启用状态。

当没有列出的 `profiles` 与活动的配置文件匹配时，Compose 将忽略该服务，除非该服务由命令显式指定。在这种情况下，其配置文件将添加到活动配置文件集。

注意

所有其他顶级元素不受 `profiles` 的影响，始终处于活动状态。

对其他服务的引用（通过 `links`、`extends` 或共享资源语法 `service:xxx`）不会自动启用否则会被活动配置文件忽略的组件。相反，Compose 会返回错误。

示例

services:
  web:
    image: web_image

  test_lib:
    image: test_lib_image
    profiles:
      - test

  coverage_lib:
    image: coverage_lib_image
    depends_on:
      - test_lib
    profiles:
      - test

  debug_lib:
    image: debug_lib_image
    depends_on:
      - test_lib
    profiles:
      - debug

在上面的例子中

  • 如果 Compose 应用程序模型在没有启用任何配置文件的情况下被解析，它只包含 `web` 服务。
  • 如果启用配置文件 `test`，模型将包含服务 `test_lib` 和 `coverage_lib`，以及始终启用的服务 `web`。
  • 如果启用配置文件 `debug`，模型将包含 `web` 和 `debug_lib` 服务，但不包含 `test_lib` 和 `coverage_lib`，因此模型在 `debug_lib` 的 `depends_on` 约束方面无效。
  • 如果启用配置文件 `debug` 和 `test`，模型将包含所有服务：`web`、`test_lib`、`coverage_lib` 和 `debug_lib`。
  • 如果 Compose 使用 `test_lib` 作为要运行的显式服务执行，即使未启用 `test` 配置文件，`test_lib` 和 `test` 配置文件也会处于活动状态。
  • 如果 Compose 使用 `coverage_lib` 作为要运行的显式服务执行，则服务 `coverage_lib` 和配置文件 `test` 将处于活动状态，并且 `test_lib` 将通过 `depends_on` 约束被引入。
  • 如果 Compose 使用 `debug_lib` 作为要运行的显式服务执行，则模型在 `debug_lib` 的 `depends_on` 约束方面再次无效，因为 `debug_lib` 和 `test_lib` 没有列出任何共同的 `profiles`。
  • 如果 Compose 使用 `debug_lib` 作为要运行的显式服务执行并且启用了配置文件 `test`，则会自动启用配置文件 `debug`，并且服务 `test_lib` 将作为依赖项被引入，从而启动服务 `debug_lib` 和 `test_lib`。

查看如何在 Docker Compose 中使用 `profiles`。