9.4 实例

services:
  config-server:
    image: 192.168.10.110:5000/config-server:0.0.1-SNAPSHOT
    networks:
      backend:
        aliases: 
          - config-server
    ports:
      - "8071:8071"
    environment:
      encrypt.key: "123456789abcdef"
      spring.profiles.active: "git"
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:8071/actuator/health >> /dev/null && exit 0 || exit 1"]
      interval: 1m30s
      timeout: 30s
      retries: 5
      start_period: 10s
  cloud-learning:
    image: 192.168.10.110:5000/cloud-learning:0.0.1-SNAPSHOT
    networks:
      backend:
        aliases: 
          - cloud-learning
    ports:
      - "8080:8080"
    environment:
      ENCRYPT_KEY: "fje83Ki8403Iod87dne7Yjsl3THueh48jfuO9j4U2hf64Lo"
      SPRING_PROFILES_ACTIVE: "dev"
      SPRING_CLOUD_CONFIG_URI: "http://config-server:8071"
    depends_on:
      config-server:
        condition: service_healthy

networks:
  backend:
    driver: bridge

上述的Compose文件定义了两个service：config-server和cloud-learning。两者均是web端微服务，其中config-server是一个Spring Cloud Config Server，而cloud-learning是Config的客户端。

depends_on的问题

在cloud-learning启动时需要从config-server获取配置信息，因此cloud-learning需要先等待config-server启动就绪后才能正常工作。

而depends_on默认的condition是service_started，它只是约定容器启动的顺序。观察docker compose up命令执行的日志可以发现，两个微服务会并行启动，cloud-learning并不会等待config-server处于就绪状态能够提供服务后再启动！因此，cloud-learning启动时会报告配置服务连接不上的警告。

解决方案：

为config-server添加健康检查命令（healthcheck），检查微服务是否启动完成，并将依赖条件定义为service_healthy。此时，只有当config-server通过健康检查后，cloud-learning才会开始启动。

健康检查命令输出：0表示healthy；1表示unhealthy。

environment指令用法

在上述的两个服务中，均利用环境变量覆盖了微服务中的某些属性，比如用ENCRYPT_KEY覆盖encrypt.key。

可以使用两种环境变量的表示方式：

• 所有字母大写，并将点”.“转换成下划线"_"，如ENCRYPT_KEY。

• 保持和properties文件中的属性一样，如：encrypt.key。

condition为service_started时，可以看到明显的交错

按照上述示例的配置，condition为service_healthy时，两个service的启动并不存在交错