2016-05-19 4 views
5

У меня есть вопрос о приоритете переменных среды при работе с spring cloud config serverSpring Cloud Config Приоритет Сервер Переменные среды

В моей службы у меня есть локальные свойства файла application.yml с этим содержанием

foo: 
    bar: "some" 
    buz: "some" 
    joe: "some" 

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

foo: 
    bar: "some-specific" 

Так что с этой установкой конфигурации во время выполнения приведет в этом:

{ 
    "foo.bar": "some-specific", 
    "foo.buz": "some", 
    "foo.joe": "some" 
} 

Теперь я пытаюсь переопределить foo.bar и foo.joe с переменной окружения.

Так что я запустить службу с помощью этой команды:

FOO_BAR=some-env FOO_JOE=some-env gradle bootRun

Из того, что я прочитал в this part of the spring boot documentation переменные среды должны иметь приоритет над файлами конфигурации - также облако конфигурации документации пружина не указывает STH разные - так что я бы ожидать, что результат будет:

{ 
    "foo.bar": "some-env", 
    "foo.buz": "some", 
    "foo.joe": "some-env" 
} 

Но вместо этого я получаю:

{ 
    "foo.bar": "some-specific", 
    "foo.buz": "some", 
    "foo.joe": "some-env" 
} 

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

Это объяснимо - или это ошибка? Любые намеки в этом?

Пожалуйста, найдите пример кода здесь:

https://github.com/mduesterhoeft/configserver-test

В файле README в хранилище перечислены проблемы, описанные здесь, как Use Case 3

+2

Config Server имеет наивысший приоритет. – spencergibb

+0

@spencergibb спасибо за подсказку - это где-то документировано? Все, что я нашел, это «Это те же правила, которые применяются в автономном приложении Spring Boot». - поэтому я думал, что эти правила применяются - https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config –

+0

Он должен если это не так, но это будет в документации весеннего облака. – spencergibb

ответ

7

определяют следующие свойства в мерзавца репо (в качестве источника для конфиг-сервера) [для данного профиля]: spring.cloud.config: overrideSystemProperties: false overrideNone: true

Имейте в виду свойства (особенно overrideSystemProperties & overrideNone) в bootsrap.yml по умолчанию отключены от конфигурационного сервера

+2

Just FYI, для меня это сработало, когда я поместил его в конфигурационный файл git repo для отдельного приложения (клиент конфигурации) и не работал, когда я поместил его в конфигурационный файл git repo для сервера конфигурации. – Matt

+1

После некоторой мысли , Я понял, что это здорово, но это возможно, но это, вероятно, не очень хорошая идея. Весь смысл втягивания * централизованного * компонента конфигурации состоит в том, чтобы получить именно это - * централизованную * конфигурацию. Если вы начнете позволять ему стать * распределенным * config, есть 101 способ сделать что-то неправильно. Подумайте, что произойдет, если вам нужно изменить ключ API, который был предоставлен через env var. Вам нужно будет перезапустить службу. Какая же точка в этом случае для сервера конфигурации? Используйте с осторожностью! – demaniak

Смежные вопросы