【问题标题】:Spring Cloud Config Server Priority of Environment VariablesSpring Cloud Config Server 环境变量的优先级
【发布时间】:2016-09-15 22:57:46
【问题描述】:

我对使用spring cloud config server时环境变量的优先级有疑问

在我的服务中,我有一个包含此内容的本地属性文件 application.yml

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

该服务还连接到配置存储库的配置服务器,该配置存储库包含一个文件testservice-api.yml(其中testservice-api 是该服务的spring 应用程序名称)。这个文件的内容是:

foo:
  bar: "some-specific"

因此,使用此设置,运行时的配置将导致:

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

现在我尝试使用环境变量覆盖 foo.barfoo.joe

所以我用这个命令启动服务:

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

根据我在this part of the spring boot documentation 中读到的内容,环境变量应该优先于配置文件——spring cloud 配置文档也没有说明不同——所以我希望结果是:

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

但是我得到了:

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

因此只有 jar 内的本地配置文件中的配置会被环境变量覆盖 - 配置仓库中的属性似乎优先于环境变量。

这是可以解释的 - 或者这是一个错误?这个有什么提示吗?

请在此处找到示例代码:

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

存储库中的自述文件将此处描述的问题列为Use Case 3

【问题讨论】:

  • 配置服务器优先级最高。
  • @spencergibb 感谢您的提示 - 它记录在某处吗?我发现的只是“这些规则与在独立 Spring Boot 应用程序中应用的规则相同。” - 所以我认为这些规则适用 - docs.spring.io/spring-boot/docs/current/reference/html/…
  • 如果不是应该是,但它会在 spring cloud 文档中。
  • @spencergibb 我试过这个projects.spring.io/spring-cloud/docs/1.0.3/…。所有关于优先级的声明都被视为正常的弹簧启动行为适用。
  • 这个documentation 似乎包含一个关于覆盖配置服务器属性的部分。

标签: java spring spring-boot spring-cloud spring-cloud-config


【解决方案1】:

在 git repo 中定义以下属性(作为配置服务器的来源)[对于给定的配置文件]: spring.cloud.config: overrideSystemProperties: false overrideNone: true

请记住,bootsrap.yml 中的属性(尤其是 overrideSystemProperties 和 overrideNone)默认被 config-server 中的属性覆盖

【讨论】:

  • 仅供参考,对我来说,当我将其放入单个应用程序(配置客户端)的 git repo 配置文件中时,这有效,而当我将其放入 git repo 配置文件中时不起作用配置服务器
  • 经过一番思考,我意识到可以做到这一点很酷,但是,这可能不是一个好主意。引入 centralized 配置组件的全部意义在于获得 - centralized 配置。如果您开始允许它成为 分布式 配置,那么有 101 种方法会出错。考虑一下如果您需要更改通过 env var 提供的 API 密钥会发生什么。您将需要重新启动服务。那么配置服务器有什么意义呢?谨慎使用!
  • 有些变量必须通过覆盖配置服务器来注入。例如,假设您有一个 Kubernetes 部署,它指向一个具有动态名称的服务(每次部署 Helm 图表时都会更改)。配置服务器永远不会知道正确的名称,每次动态名称更改时都必须手动更改配置会很糟糕。虽然可以使用 Jenkins 管道来更改存储库的代码并提交,但它太复杂了。
猜你喜欢
  • 2016-10-24
  • 1970-01-01
  • 1970-01-01
  • 2018-06-10
  • 2018-08-14
  • 2016-02-18
  • 2018-12-30
  • 2018-12-01
  • 1970-01-01
相关资源
最近更新 更多