Compose 高级用法详解——AI教你学Docker

发布于:2025-07-06 ⋅ 阅读:(10) ⋅ 点赞:(0)

3.6 Compose 高级用法详解

Docker Compose 除了常规的多服务编排,还支持一系列高级功能,如服务健康依赖、环境切换、配置模板化等。掌握这些技巧,能让你的多容器项目更健壮、更自动化、更易维护。

一、depends_on 的高级用法与启动顺序

1. 基本用法

  • depends_on 指定服务间的启动顺序,确保依赖的服务优先启动。

    services:
      web:
        depends_on:
          - db
      db:
        image: postgres
    
  • 启动时会先启动 db,再启动 web。

2. 高级用法(条件依赖,Compose v3.4+)

  • 仅控制“启动顺序”,不保证被依赖服务已就绪(如数据库完全可用)。

  • 高级写法可以指定健康检查条件(condition 字段,v2 语法,Compose v3 推荐结合 healthcheck)。

    services:
      web:
        depends_on:
          db:
            condition: service_healthy
      db:
        image: postgres
        healthcheck:
          test: ["CMD", "pg_isready", "-U", "postgres"]
          interval: 10s
          retries: 5
    
  • 效果:web 服务仅在 db 的健康检查通过(状态为 healthy)后启动。

3. 实践建议

  • 复杂依赖场景要用 healthcheck 配合 depends_on,避免业务服务因依赖服务未就绪而频繁重启。
  • 生产环境建议应用端实现重试/等待逻辑,Compose 启动顺序仅作辅助。

二、healthcheck 结合 restart 策略

1. healthcheck 作用

  • 定期检测服务是否健康。

  • 如果检测失败,会将服务状态标记为“unhealthy”。

    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s
    
  • test 可为命令行数组或 shell 命令。

2. restart 策略

  • 控制服务异常退出时的自动重启行为:

    策略 说明
    no(默认) 不自动重启
    always 任何情况下都重启
    unless-stopped 除非被手动 stop,否则一直重启
    on-failure 非 0 状态码退出时重启,可指定最大次数
    restart: on-failure:5
    

3. healthcheck 与 restart 配合

  • healthcheck 失败只会将容器标记为 unhealthy,不会自动重启容器。
  • 若需自动重启,可通过外部监控、Swarm/K8s 等更高级平台实现。
  • 推荐用 healthcheck + depends_on: condition,实现依赖就绪后再启动关联服务。
  • 对于“僵死”服务,通过 healthcheck 发现后,人工或自动化脚本可重启。

三、多环境配置(开发/测试/生产)

1. 多 Compose 文件覆盖

  • 基础文件:docker-compose.yml

  • 覆盖文件:docker-compose.override.yml(自动加载)、docker-compose.dev.ymldocker-compose.prod.yml

  • 启动时合并多个文件,后面的配置会覆盖前面的同名字段:

    # 开发环境
    docker compose -f docker-compose.yml -f docker-compose.override.yml up -d
    
    # 生产环境
    docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d
    

2. 环境变量与 .env 文件

  • .env 文件存储通用或敏感配置(如数据库密码、API Key),不同环境用不同的 .env 文件。
  • 在 CI/CD、生产部署时注入环境变量,避免敏感信息写死。
  • 支持 ${VAR_NAME} 占位符动态引用变量。

3. 配置差异管理建议

  • 通用配置写在主 compose 文件,环境相关或敏感配置用覆盖文件和变量注入实现。
  • 生产、开发、测试环境分别维护独立的 yml 或 env 文件。

四、Compose 文件模板化(扩展 Compose、环境占位符)

1. 环境变量占位符

  • 在 compose 文件中用 ${VAR_NAME} 动态替换内容,适合端口、密码、路径等参数化。

    services:
      db:
        image: postgres:${PG_VERSION}
        environment:
          - POSTGRES_PASSWORD=${DB_PASSWORD}
    
  • 变量来源优先级:命令行 -e > yaml environment 字段 > env_file > .env 文件。

2. 扩展与继承(YAML anchors)

  • 通过 YAML 的锚点(anchor)和别名(alias)简化重复配置(Compose v3+ 支持)

    x-defaults: &defaults
      restart: always
      logging:
        driver: "json-file"
        options:
          max-size: "10m"
    
    services:
      web:
        <<: *defaults
        image: myweb
      api:
        <<: *defaults
        image: myapi
    

3. Compose Spec 扩展机制

  • Compose Spec 支持 x- 前缀自定义扩展字段,便于后续模板化工具或脚本读取。

    services:
      app:
        image: myapp
        x-extra-labels:
          - env=dev
          - version=1.0.0
    

4. 模板化工具

  • 可用 envsubst、yq、gomplate 等工具在 CI/CD 中批量替换变量。
  • 对于更复杂模板化,可用 Helm(K8s)、Kustomize、Ansible 等进阶方案。

五、参考资料