Централизация микросервисов JHipster без использования Docker compose или любого контейнера Docker, нужна помощь

Question

В настоящее время я пытаюсь реализовать сценарий

Я использовал приложение Jhipster Registry непосредственно из git -hub, чтобы использовать его в качестве реестра Eureka и сервера Spring-Cloud-Config ( будет функцией по умолчанию).

Мне нужно централизовать конфигурации файлов конфигураций приложений микросервисов в Jhipster реестре.

Все это мы должны обойтись без используя Docker, поскольку текущий проект не использует Docker. Для этого я внес изменения в файл bootstrap .yml , как показано ниже (для работы в качестве составного профиля, хотя собственный тип с локальной файловой системой, поскольку у нас нет доступа к производственному репозиторию git. Итак, выбрал файловую систему только с профилем dev / Composite . В настоящее время мой boostrap.yml выглядит следующим образом

spring:
  application:
    name: jhipster-registry
  profiles:
    active: dev
    include: composite
  cloud:
    config:
      server:
        
        bootstrap: true
        composite:
          - type: native #git
            
            search-locations: file:/C:/Jhipster_Eureka/jhipster-registry-master/central-config/
            
        prefix: /config
      fail-fast: true
      
      name: jhipster-registry
      profile: composite 

Я также создал шлюз .yml файл в папке central-config (шлюз является одним из примеров приложения микросервисов, конфигурацию которого я пытаюсь централизовать, будь то клиент eureka, источник данных - все, что по умолчанию относится к application-dev .yml в созданном мной приложении микросервисного шлюза Jhipster ), указав всю конфигурацию, как показано ниже gateway.yml

   server:
  port: 8888
management:
  health:
    diskspace:
      enabled: false
# ===================================================================
# JHipster Sample Spring Cloud Config.
# ===================================================================

# Property used on app startup to check the config server status

configserver:
  name: JHipster Registry config server
  status: Connected to the JHipster Registry config server!

# Default JWT secret token (to be changed in production!)
jhipster:
  security:
    authentication:
      jwt:
        # It is recommended to encrypt the secret key in Base64, using the `base64-secret` property.
        # For compabitibily issues with applications generated with older JHipster releases,
        # we use the non Base64-encoded `secret` property here.
        # secret: my-secret-key-which-should-be-changed-in-production-and-be-base64-encoded
        # The `base64-secret` property is recommended if you use JHipster v5.3.0+
        # (you can type `echo 'secret-key'|base64` on your command line)
        base64-secret: bXktc2VjcmV0LWtleS13aGljaC1zaG91bGQtYmUtY2hhbmdlZC1pbi1wcm9kdWN0aW9uLWFuZC1iZS1iYXNlNjQtZW5jb2RlZAo=

spring:
  profiles:
    active: dev
    include:
      - swagger

eureka:
  instance:
    prefer-ip-address: true
  client:
    service-url:
      defaultZone: http://admin:admin@localhost:8761/eureka/



  datasource:
  type: com.zaxxer.hikari.HikariDataSource
  url: jdbc:mysql://localhost:3306/conference?useUnicode=true&characterEncoding=utf8&useSSL=false&useLegacyDatetimeCode=false&serverTimezone=UTC&createDatabaseIfNotExist=true
  username: root
  password: root
  hikari:
    poolName: Hikari
    auto-commit: false
    data-source-properties:
      cachePrepStmts: true
      prepStmtCacheSize: 250
      prepStmtCacheSqlLimit: 2048
      useServerPrepStmts: true

  jpa:
    show-sql: true
    liquibase:
      # Remove 'faker' if you do not want the sample data to be loaded automatically
      contexts: dev

Проблема № 1 Если я запускаю свой реестр, он работает правильно, без каких-либо проблем. Если я попытаюсь запустить приложение микросервиса «шлюз» без определения определений источников данных, упомянутых в его собственном файле конфигурации (application-dev.yml), это будет ошибкой ling во время выполнения.

Трассировка стека исключений во время выполнения

2020-08-06 21:45:58.301  WARN 28804 --- [  restartedMain] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Unable to start web server; nested exception is java.lang.RuntimeException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'servletEndpointRegistrar' defined in class path resource [org/springframework/boot/actuate/autoconfigure/endpoint/web/ServletEndpointManagementContextConfiguration$WebMvcServletEndpointManagementContextConfiguration.class]:
 Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.boot.actuate.endpoint.web.ServletEndpointRegistrar]: Factory method 'servletEndpointRegistrar' threw exception; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'healthEndpoint' defined in class path resource [org/springframework/boot/actuate/autoconfigure/health/HealthEndpointConfiguration.class]: Unsatisfied dependency expressed through method 'healthEndpoint' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'healthContributorRegistry' defined in class path resource [org/springframework/boot/actuate/autoconfigure/health/HealthEndpointConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.boot.actuate.health.HealthContributorRegistry]: Factory method 'healthContributorRegistry' threw exception; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name 'org.springframework.boot.actuate.autoconfigure.jdbc.DataSourceHealthContributorAutoConfiguration': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource' defined in class path resource [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.zaxxer.hikari.HikariDataSource]: Factory method 'dataSource' threw exception; nested exception is org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$DataSourceBeanCreationException: Failed to determine a suitable driver class

Я удивлен, как экземпляр eureka был взят из этого файла gateway.yml , но не из источника данных , так что здесь пошло не так?

Проблема № 2

В файле gateway.app упоминается yml server.port:8888, но это будет порт spring-cloud-config-server или микро- порт служебного приложения, например, 8083. Я заметил, что если я пытаюсь изменить этот порт с 8888 на 8083, он выдает ошибку во время выполнения, не может найти клиента обнаружения, в чем проблема или мне все еще не хватает конфигурации?

Пожалуйста, дайте мне знать, если запрос теперь достаточно подробный, чтобы ответить.

Answer 1

Docker абсолютно НЕ требуется для архитектуры микросервисов JHipster с использованием jhipster-registry, ваш вариант использования хорошо поддерживается, а проблемы, с которыми вы столкнулись, связаны только с ошибками вашей конфигурации.

gateway.yml не с правильным отступом, поэтому имена свойств для datasource не совпадают, поэтому вы получаете эту ошибку о невозможности найти драйвер JDB C.

Блок eureka в середине spring block полностью сломал его, и в любом случае конфигурация eureka используется всеми приложениями, поэтому ее следует разместить в application-dev.yml и application-prod.yml.

gateway.yml, как и любые другие файлы, которые находятся в репозитории среды (central-config папка при использовании собственного) должны иметь тот же формат, что и ваши локальные файлы application.yml.

Если вам неудобно работать с файлами YAML, вы можете переключиться на обычные свойства.

Об именах файлов в собственном репозиторий, Spring Cloud Config Server do c говорит:

Если репозиторий файловый, сервер создает Среда из application.yml (совместно используется всеми клиентами) и foo.yml (с приоритетом foo.yml). Если в файлах YAML есть документы, указывающие на профили Spring, они применяются с более высоким приоритетом (в порядке перечисленных профилей). Если есть файлы профиля c YAML (или свойств), они также применяются с более высоким приоритетом, чем значения по умолчанию.

Таким образом, в основном это означает, что в вашей папке central-config у вас должен быть эти файлы:

• application.yml: все свойства, общие для всех приложений, когда профиль не задан
• application-dev.yml: все свойства, общие для всех приложений, когда установлен профиль разработчика. Здесь вы поместите секрет JWT для разработчика, URL-адрес сервера Eureka для разработчиков (часто localhost)
• application-prod.yml: все свойства, общие для всех приложений, когда установлен профиль prod. Здесь вы поместите секрет JWT для prod, URL-адрес для prod Eureka server
• gateway.yml: все свойства приложения шлюза, когда профиль не установлен
• gateway-dev.yml: все свойства приложения шлюза, когда установлен профиль разработчика. Здесь вы поместите источник данных разработчика
• gateway-prod.yml: все свойства приложения шлюза, когда установлен профиль prod. Здесь вы разместите источник данных prod

Поэтому, когда ваш шлюз загружается с профилем dev, он получит комбинацию application.yml, application-dev.yml, gateway.yml и gateway-dev. yml

Этот механизм может работать только в том случае, если вы следуете соглашению об именах {app name}-{profile}.yml

Итак, присвоение имени файла application-dev-gateway.yml означало просто свойства, общие для всех приложений с профилем dev-gateway, который является вероятно, не то, что вы имели в виду.