Как понять, что весеннее загрузочное приложение готово к работе?

Question

У меня есть несколько микросерий на весну Одним из них является сервер конфигурации. Я пытаюсь запустить сервисы вместе с docker-compose. Но есть проблема. Микросервисы пытаются получить конфиги с сервера конфигурации до его инициализации. Я хочу написать скрипт для запуска микросервиса, предотвращающий фальстарт. Я должен теперь, как я могу определить момент, когда мой сервер конфигурации готов. Прослушивание порта не работает. Докер скрывает информацию о своей сети. Я считаю, что есть лучший способ, чем стандартный анализ вывода.

Кто-нибудь знает, как определить время запуска приложения весенней загрузки?

Answer 1

Если ваша проблема связана с сервером конфигурации, Вы также можете реализовать механизм пружинного повтора

spring:
   application:
      name: test-service
   cloud:
      config:
         enabled: true
         uri: ${CONFIG_SERVER_URL:http://127.0.0.1:8761} #where the config-service is running
         fail-fast: true #the service will not run if it can't reach the config-service
         name: common,test-service
         retry:
           max-attempts: 10
           max-interval: 5000

Вы также должны иметь зависимость при повторном запуске

// https://mvnrepository.com/artifact/org.springframework.retry/spring-retry
compile group: 'org.springframework.retry', name: 'spring-retry', version: '1.2.4.RELEASE'

Answer 2

Кто-нибудь знает, как определить время запуска приложения весенней загрузки?

Ваше приложение должно быть готово, когда оно возвращает код 200 из /health конечной точки с такой полезной нагрузкой, как этот

{
  "status": "UP"
}

Это означает, что ваше приложение не имеет проблем и готово к работе. В любом случае, эта конечная точка обычно используется приложением монитора, чтобы узнать о состоянии вашего приложения, чтобы поддерживать кластер, эта конечная точка обычно не используется другими приложениями. этот монитор обычно

• Использует эту конечную точку, чтобы знать, когда ваше приложение готово принимать мировые запросы, таким образом, оно может зарегистрировать ваше приложение по общедоступному адресу, например
• Попробуйте перезапустить приложение, ожидая, что оно сможет решить проблему, когда /health вернет ВНИЗ статус

Взгляните на Docker Healthcheck , он использует ту же концепцию, что и пружина

Чтобы эта конечная точка была доступна, вам нужно добавить зависимость пружинного привода, вот пример Gradle

compile group: 'org.springframework.boot', name: 'spring-boot-starter-actuator', version: '1.5.10.RELEASE'

Микросервисы пытаются получить конфиги с сервера конфигурации до его инициализации ....

Вот некоторые важные моменты, которые нужно прояснить

• Docker compose не предоставляет порядок запуска, если вы не используете условие depen_on , в любом случае docker никогда не будет ждать, пока первый контейнер полностью запустится (событие с помощью healthcheck), чтобы затем запустить второй контейнер
• Если ваш микросервис A зависит от микросервиса B , тогда A должен быть подготовлен к устранению сбоя и недоступности B , это микросервис предпосылка, потому что это произойдет, когда-нибудь или даже хуже, в неожиданный момент, когда это не должно быть. Как насчет config-server перезапускается в какой-то момент? Что будет с зависимыми приложениями?

Поэтому я советую вам позволить вашему приложению просто не работать, когда оно пытается получить информацию из приложения config server , в случае сбоя вы можете сделать некоторые вещи:

• Сделайте какую-нибудь попытку , используя пружинную попытку , например
• Если вы можете иметь дело с какой-то временной конфигурацией сервера недоступностью, тогда я предлагаю добавить пользовательский чек в ваш /health, предоставляя эту информацию некоторому микросервису монитора
• Если ваше приложение не может работать без сервера конфигурации , тогда просто наберите System.exit(-1) и позвольте docker-compose перезапустить ваше приложение снова и снова, пока сервер конфигурации ответьте что-нибудь полезное

Вот небольшой пример, который моделирует ваш случай и решает его с помощью Docker

• сервер конфигурации
• Приложение-1

config-server займет больше времени, чем app-1 , чтобы подготовиться, тогда app-1 останется нездоровым до config-server правильно отвечает

version: '3.4'
services:
  mg-config-server:
    image: nginx:1.10
    healthcheck:
      test: ["CMD", "bash", "-c", "sleep 15; exit 0"]
      interval: 10s
      timeout: 17s
      retries: 3
      start_period: 10s
    networks:
      - my-net
    command: bash -c "echo starting; sleep 20; nginx -g 'daemon off;'"

  mg-app-1:
    image: alpine:3.7
    healthcheck:
      test: ["CMD", "curl", "http://mg-config-server"]
      interval: 5s
      timeout: 5s
      retries: 3
      start_period: 1s
    command: sh -c 'echo starting; apk add --update curl; tail -f /dev/null'
    restart: always
    networks: 
      - my-net
    dns:
    - 8.8.8.8

networks:
  my-net:
    driver: overlay

Тогда просто запустите

docker-compose up
docker ps | grep "mg" 

В любом случае, в этом случае имеет больше смысла использовать Docker Swarm, потому что он проверит конечные точки проверки работоспособности и перезапустит контейнеры, если они не исправны

docker swarm init --advertise-addr <your-machine-ip>
docker stack deploy --compose-file docker-compose.yml my-stack && docker ps | grep "my-stack"

Версия докера: 18.02.0-ce

Извините за слишком длинный ответ, надеюсь, это поможет