Разрешение заполнителей для конкретной конфигурации клиента

Я изучаю возможности проекта Spring Cloud Config. Мне было интересно, можно ли использовать заполнители для конкретной конфигурации приложения?

Например:

Мой файл application.yml:

server:
  port: 8888

spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          search-locations: classpath:/config

Папка конфигурации содержит файл my-app.yml:

key:
  value: ${my.password}

Сервер запущен с переменной среды -Dmy.password=password. Запрос на получение /my-app/native url возвращает:

{
    "name": "my-app",
    "profiles": ["native"],
    "label": null,
    "version": null,
    "state": null,
    "propertySources": [{
        "name": "classpath:/config/my-app.yml",
        "source": {
            "key.value": "${my.password}"
        }
    }]
}

Свойство env в заполнителе возвращается клиенту без оценки, есть ли способ оценить свойство перед отправкой ответа клиенту?


spring-boot spring spring-cloud spring-cloud-config
person Maxim Kirilov    schedule 30.10.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вы можете использовать функцию override для установки значения key.value при запуске сервера:

-Dspring.cloud.config.server.overrides.key.value=overrideValue

Я думаю, что ваши клиенты должны быть запущены позже.

документация Spring:

Переопределение свойств

Сервер конфигурации имеет функцию «переопределения», которая позволяет оператору задавать свойства конфигурации для всех приложений. Переопределенные свойства не могут быть случайно изменены приложением с помощью обычных перехватчиков Spring Boot. Чтобы объявить переопределения, добавьте карту пар "имя-значение" в spring.cloud.config.server.overrides, как показано в следующем примере:

spring:   
  cloud:
    config:
      server:
        overrides:
          foo: bar

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

...

person alexbt    schedule 30.10.2016
comment
Спасибо за ваш ответ, это частично решает мою проблему. Например, если сервер конфигурации предоставляет разные значения (один и тот же ключ) для разных приложений. Одно значение берется из среды, а другое жестко закодировано в файле конфигурации. Есть вариант контролировать? - person Maxim Kirilov; 31.10.2016
comment
Я не думаю, что это возможно (по крайней мере, я не знаю). у вас часто меняются пароли? Почему бы вам не использовать весеннее загрузочное облако {cipher} на вашем сервере GIT. У вас будет один {cipher} для каждого клиента (организованный по имени приложения или по разным меткам)? У вас будут преимущества зашифрованных паролей. Будет ли это соответствовать вашим потребностям? Если вы не знаете о cyper, дайте мне знать, я обновлю ответ - person alexbt; 01.11.2016
comment
Я знаком с функциональностью шифра. Проблема в том, что пароль может быть изменен во время установки и по запросу. - person Maxim Kirilov; 01.11.2016
comment
Тогда я не знаю, что еще можно сделать (не говорю, что чего-то нет, просто я не знаю об этом). - person alexbt; 01.11.2016