重启客户端之前，docker-compose无法访问Spring Config服务器

Question

我使用Eureka，Config Server和我的客户端进行了“发现优先”设置。

问题在于这3个服务是按顺序启动的，但是客户端服务器似乎注册得太早，并且永远找不到配置服务器。我尝试了一个第三方库，该库允许等到config-server：8888可用时，但这似乎也不总是起作用。这类似于比赛条件。

The workaround is that if I docker restart the client-server after everything is up, it registers and finds config-server just fine.

First run of docker-compose:

Fetching config from server at : http://localhost:8888
Connect Timeout Exception on Url - http://localhost:8888. Will be trying the next url if available

When I docker restart the client:

Fetching config from server at : http://a80b001d04a7:8888/
Located environment: name=client-server, profiles=[default], label=null, version=053c8e1b14dc0281d5af0349c9b2cf012c1a346f, state=null

Not sure if my JAVA_OPTS properties aren't being set fast enough from my docker-compose.yml, or there is some networking race condition, or what. I've been going back and forth on this for too long.

My configuration is below:

Here's my docker-compose.yml:

version: '3'
services:
  eureka:
    image: eureka-server:latest
    environment:
    - "JAVA_OPTS=-DEUREKA_SERVER=http://eureka:8761/eureka"
    ports:
      - 8761:8761
  config:
    image: config-server:latest
    environment:
      - "JAVA_OPTS=-DEUREKA_SERVER=http://eureka:8761/eureka"
    depends_on:
      - eureka
    ports:
      - 8888:8888
  client:
    image: client-server:latest
    environment:
      JAVA_OPTS: -DEUREKA_SERVER=http://eureka:8761/eureka
    depends_on:
      - config
    ports:
      - 9000:9000

Here's the eureka-server application.yml:

server:
  port: 8761

spring:
  application:
    name: eureka-server

eureka:
  client:
    registerWithEureka: false
    fetchRegistry: false
    service-url:
      defaultZone: ${EUREKA_SERVER:http://localhost:8761/eureka}

Here's the config-server bootstrap.yml:

server:
  port: 8888

eureka:
  client:
    serviceUrl:
      defaultZone: ${EUREKA_SERVER:http://localhost:8761/eureka}

spring:
  application:
    name: config-server

Here's the client-server bootstrap.yml:

spring:
  application:
    name: client-server
  cloud:
    config:
      discovery:
        enabled: true
        serviceId: config-server
      fast-fail: true
    retry:
      max-attempts: 10000
      max-interval: 1000

eureka:
  instance:
    hostname: client-server
  client:
    registerWithEureka: true
    fetchRegistry: true
    serviceUrl:
      defaultZone: ${EUREKA_SERVER:http://localhost:8761/eureka}

Edit:

Using the docker-compose wait library (https://github.com/ufoscout/docker-compose-wait), I can have the client-server wait for eureka and config to be available, then wait 90 seconds (Eureka documentation suggests that registration could take up to 90 seconds), and it seems to work consistently.

Is this an acceptable solution? Feels like a bit of a hack.

Answer 1

作为纯粹主义者，您的问题的答案是否定的，这不是一个可接受的解决方案，因为正如此处所述，Dockerhealthcheck由于某种原因从 v3 中删除：

Docker 有意识地决定不支持等待容器处于“就绪”状态的功能。他们认为依赖于其他系统的应用程序应该能够抵御故障。

在同一链接中，描述了原因：

等待数据库（例如）准备就绪的问题实际上只是分布式系统更大问题的一个子集。在生产中，您的数据库可能随时不可用或移动主机。您的应用程序需要对这些类型的故障具有弹性。

要处理此问题，您的应用程序应尝试在失败后重新建立与数据库的连接。如果应用程序重试连接，它最终应该能够连接到数据库。

那么基本上有以下三种选择：

1. 将 v2.1 与healhcheck. 在此处查看示例
2. 使用 v3 和像wait-for-it或 dockerize这样的工具，@ortomala-lokni 已经完美解释了
3. 使您的应用程序对 config-server 故障具有弹性，并能够 config-client 在启动时重试连接

推荐和可接受的解决方案是 3)。您可以使用此处提到的Spring Retry。找到下面的配置：bootstrap.yml

spring:
  application:
    name: config-client
  profiles:
     active: dev
  cloud:
    config:
     discovery:
       enabled: true
       service-id: config-server
     fail-fast: true
     retry:
       initial-interval: 1500
       multiplier: 1.5
       max-attempts: 10000
       max-interval: 1000

eureka:
  instance:
    hostname: config-client
  client:
    registerWithEureka: true
    fetchRegistry: true
    serviceUrl:
      defaultZone: ${EUREKA_SERVER:http://localhost:8761/eureka}

顺便说一句，我在您的弹簧配置中发现了一个错误。它是fail-fast和不是fast-fail。

请记住包含以下依赖项（如果您使用的是 gradle，则类似）：

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

您可以在这里找到一个很好的配置（和解释），同时考虑了 Eureka 服务器中注册过程中的弹性。

在拥有微服务环境时，我们必须考虑环境的弹性，因为像 config-service、discovery-service 这样的平台服务在短时间内不可用。

但我根本不是纯粹主义者，我不会删除人们正在使用的某些功能（这是一个自由的问题）。因此，另一种解决方案是：

如果它对你有用，那么继续

因为我真的不明白为什么 Docker 会healthcheck从v3.5 中压制这个神奇的命令。