Как прочитать несколько конфигурационных файлов с сервера Spring Cloud Config

Question

Spring config config server поддерживает чтение файлов свойств с именем ${spring.application.name}.properties, Однако у меня есть 2 файла свойств в моем приложении.

a.properties
b.properties

Могу ли я заставить сервер конфигурации прочитать оба этих файла свойств?

Answer 1

Переименуйте файлы свойств в git или файловой системе, где находится ваш сервер настроек.

a.properties -> <your_application_name>.properties
a.properties -> <your_application_name>-<profile-name>.properties

Например, если имя вашего приложения test и вы запускаете приложение на dev профиль, ниже два свойства будут использоваться вместе.

test.properties
test-dev.properties

Также вы можете указать дополнительные профили в bootstrap.properties вашего клиента конфигурации, чтобы получить больше файлов свойств, как показано ниже. Например,

spring:
  profiles: dev
  cloud:
    config:
      uri: http://yourconfigserver.com:8888
      profile: dev,dev-db,dev-mq

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

test.properties
test-dev.properties
test-dev-db.prpoerties
test-dev-mq.properties

Answer 2

Обратите внимание, что предоставленный ответ предполагает, что ваши файлы свойств обращаются к различным профилям выполнения. Если они не имеют значения, т. Е. Ваши свойства разделены на разные файлы по какой-то другой причине, например, в целях обслуживания, разделенной на бизнес / функциональный домен или по любой другой причине, которая соответствует вашим потребностям, то, определив профиль для каждого такого файла, Вы просто "злоупотребляете" функцией профиля для достижения своей цели (несколько файлов свойств на приложение).

Затем вы можете спросить: "Хорошо, так в чем же проблема?". Проблема в том, что вы сдерживаете себя от различных возможностей, которые у вас были бы в противном случае. Если вы действительно хотите настроить конфигурацию приложения по профилю, вам придется создать псевдо, суб, профили для этого, поскольку имя файла уже является профилем. Пример:

Конфигурация вашего приложения может быть изменена с помощью различных профилей, которые вы используете внутри вашего приложения Springboot (например, в аннотации @Profile()), пусть они будут dev, uat, prod. Вы можете загрузить свое приложение, установив различные профили как активные, например, 'dev' vs 'uat', и получить желаемую группу свойств. Для ваших файлов a.properties b.properties и c.properties, если бы были поддержаны разные имена файлов, у вас были бы файлы a. dev.properties b- dev.properties и c- dev.properties против a. Aat. Файлы.properties и cut.properties для профилей 'dev' и 'uat'.

Тем не менее, с помощью предоставленного решения вы уже определили 3 профиля для каждого файла: appname-a.properties appname-b.properties и appname-c.properties: a, b и c. Теперь представьте, что вам нужно создать отдельный профиль для каждого... профиля (! Он уже показывает, что здесь что-то идет не так)! в результате вы получите множество изменений в профиле (которые будут ухудшаться при увеличении файлов): файлы будут называться appname- a-dev.properties, appname- b-dev.properties, app- c-dev.properties vs appname- a-uat.properties, appname- b-uat.properties, app- c-uat.properties, но профили были бы увеличены с ['dev', ' uat'] до ['a-dev', 'b-dev', 'c-dev', 'a-uat', 'b-uat', 'c-uat']!!!

Хуже того, как вы собираетесь справляться со всеми этими профилями внутри вашего кода и, в частности, с вашими аннотациями @Profile()? Будете ли вы загромождать пространство кода "искусственными" профилями только потому, что хотите добавить еще один или два разных файла свойств? Было бы достаточно определить ваши профили dev или uat, где это применимо, и определить где-то еще соответствующие имена файлов свойств (которые затем могут быть дополнительно поддержаны профилем, без каких-либо других действий по настройке), как это происходит во внешних свойствах. конфигурация для отдельных приложений Springboot

Для полноты аргумента я просто добавлю, что если вы хотите однажды переключиться на файлы свойств .yml с помощью предоставленного решения для именования на основе профилей, вы также потеряете возможность определять различные "разделы документа yaml для профиля" внутри одного и того же Файл.yml (Да, в.yml вы можете иметь один файл свойств, но при этом определить несколько логических документов yml внутри, что обычно делается для настройки свойств для разных профилей, при этом все связанные свойства находятся в одном месте). Вы теряете возможность, потому что вы уже использовали профиль в имени файла (appname-profile.yml)

Я выпустил запрос на извлечение с небольшим исправлением для spring-cloud-config-server 1.4.x, который позволяет определять дополнительно поддерживаемые имена файлов (appart из "application[-profile]" и "{appname}[-profile]", которые в настоящее время поддерживаются), предоставив свойство среды spring.cloud.congif.server.searchNames - аналог Spring.config.name для приложений springboot. Я надеюсь, что это будет рассмотрено и принято.

Answer 3

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

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

appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties

application.properties // for my use, contains local properties only
bootstrap.properties // for my use, contains management properties only

В моем приложении у меня есть определенные свойства, которые позволяют мне достичь того, что мне нужно. Но обратите внимание, что у меня есть и остальная необходимая конфигурация (включить облачную конфигурацию, обновление актуатора, обнаружение службы эврики и так далее) - просто выделив их для акцента:

spring.application.name=appxyz
spring.cloud.config.name=appxyz-data-soures,appxyz-interfaces,appxyz-feature

Вы можете заметить, что я не хотел обыгрывать свое имя приложения, а вместо этого использовал его в качестве префикса для своих файлов свойств конфигурации.

На моем сервере конфигурации я настроил в application.yml для захватаpattern: 'appxyz-*':

spring:
  cloud:
    config:
      server:
        git:
          uri: <git repo default>
          repos:
            appxyz:
              pattern: 'appxyz-*'
              uri: <another git repo if you have 1 repo per app>
              private-key: ${git.appxyz.pk}
          strict-host-key-checking: false
          ignore-local-ssh-settings: true
          private-key: ${git.default.pk}

В моем репозитории Git есть следующее. Никаких application.properties и bootstrap, потому что я не хотел, чтобы они публиковались и заменялись / обновлялись извне, но вы можете это сделать, если хотите.

appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties

Это будет сопоставление с образцом pattern: 'appxyz-*'который захватит и вернет соответствующие файлы из моего репозитория git. Профиль также будет применен и соответственно получит правильный файл свойств. Приоритет ценности также сохраняется.

Кроме того, если вы хотите добавить еще файл в свое приложение (скажем, appxyz-circuit-breaker.properties), нам нужно только сделать:

1. Добавьте шаблон имени в spring.cloud.config.name=...,appxyz-circuit-breaker
2. Добавляйте копии файла локально, а также извне (в репозиторий git.

Больше не нужно добавлять / изменять или перезапускать сервер конфигурации позже. Для нового приложения это похоже на однократную регистрацию: добавить запись подrepos из application.yml.

Надеюсь, это так или иначе поможет!

Answer 4

В вашем приложении bootstrap.properties вы должны указать, как показано ниже:

spring.application.name=a,b