Spring Cloud Server, обслуживающий несколько файлов свойств для одного приложения

Question

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

-> applicationA
          - datasource.properties
          - security.properties
          - jms.properties

Как переместить все свойства на облачный сервер Spring и сохранить их в отдельности?

На сегодняшний день янастроили сервер конфигурации, который будет читать только ОДИН файл свойств, так как это кажется стандартным способом.Этот файл, который получает сервер конфигурации, похоже, решен с помощью spring.application.name.В моем случае он будет читать только один файл с таким именем:

-> applicationA.properties

Как добавить другие файлы, которые будут разрешены сервером конфигурации?

Answer 1

Это можно сделать.Вам необходимо создать собственный EnvironmentRepository, который загружает файлы ваших свойств.

org.springframework.cloud.config.server.support.AbstractScmAccessor # getSearchLocations выполняет поиск файлов свойств для загрузки:

for (String prof : profiles) {
            for (String app : apps) {
                String value = location;
                if (app != null) {
                    value = value.replace("{application}", app);
                }
                if (prof != null) {
                    value = value.replace("{profile}", prof);
                }
                if (label != null) {
                    value = value.replace("{label}", label);
                }
                if (!value.endsWith("/")) {
                    value = value + "/";
                }
                output.addAll(matchingDirectories(dir, value));
            }
        }

Там вы можете добавить пользовательский код, который читает необходимые файлы свойств.Приведенный выше код точно соответствует поведению, описанному в весенних документах.NativeEnvironmentRepository НЕ имеет никакого доступа к GIT / SCM, поэтому вы должны использовать JGitEnvironmentRepository в качестве основы для собственной реализации.

Answer 2

Как отметил @nmyk, ​​NativeEnvironmentRepository загружает мини-приложение, чтобы собирать свойства, предоставляя ему - своего рода - "жестко запрограммированный" {appname} . * И приложение . * Поддерживаемые имена файлов свойств.(@Stefan Isele - prefabware.com JGitEnvironmentRepository также использует NativeEnvironmentRepository), который поддерживает определение дополнительных имен файлов через свойство среды spring.cloud.config.server.searchNames , в том же смысле, что и для одного приложения Springboot, как определено в Externalized Configuration.Application Property Files раздел документации, используя свойство spring.config.name enviroment.Я надеюсь, что они рассмотрят его в ближайшее время, так как кажется, что многие спрашивали об этой функции в переполнении стека, и, конечно, многие другие ищут ее и читают рекомендованные в настоящее время решения.

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

Answer 3

Не так, как вы просили.Сервер Spring Cloud Config использует NativeEnvironmentRepository, который:

Простая реализация {@link EnvironmentRepository}, которая использует SpringApplication и файлы конфигурации, расположенные по обычным протоколам.Результирующая среда состоит из источников свойств, расположенных с использованием имени приложения в качестве основы файла конфигурации (spring.config.name) и имени среды в виде профиля Spring.

См .: https://github.com/spring-cloud/spring-cloud-config/blob/master/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/NativeEnvironmentRepository.java

Таким образом, в основном каждый раз, когда клиент запрашивает свойства у Config Server, он создает ConfigurableApplicationContext с использованием SpringApplicationBuilder.И он запускается со следующим свойством конфигурации:

String config = application;
if (!config.startsWith("application")) {
    config = "application," + config;
}
list.add("--spring.config.name=" + config);

Таким образом, возможными именами файлов свойств будут только application.properties(or .yml) и имя клиентского приложения конфигурации, которое запрашивает конфигурацию - в вашем случае applicationA.properties.

Но вы можете "обмануть".В конфигурации сервера конфигурации вы можете добавить такое свойство

spring:
  cloud:
    config:
      server:
        git:
          search-paths: '{application}, {application}/your-subdirectory'

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

applicationA/application.properies
applicationA/your-subdirectory/application.properies