Spring Cloud Config Server环境变量的优先级

Question

在使用spring cloud配置服务器时,我对环境变量的优先级有疑问

在我的服务中,我有一个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.bar并foo.joe使用环境变量.

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

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

从我在spring boot文档的这一部分中读到的内容,环境变量应优先于配置文件 - 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内部的本地配置文件的配置被环境变量覆盖 - 来自config repo的属性似乎优先于环境变量.

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

请在此处找到示例代码:

存储库中的README将此处描述的问题列为用例3

Answer 1

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

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

仅供参考,对我而言,当我将它放在单个应用程序(配置客户端)的git repo配置文件中时,这种方式有效,当我将它放在配置服务器的git repo配置文件中时,它无法正常工作 (2认同)
经过一番思考，我意识到有可能做到这一点很酷，但是，这可能不是一个好主意。引入* centralized *配置组件的全部目的就是获得-* centralized *配置。如果您开始允许它成为* distributed *配置，那么有101种方法会出错。考虑如果需要更改通过env var提供的API密钥，会发生什么情况。您将需要重新启动服务。那到配置服务器有什么意义呢？请谨慎使用！ (2认同)
必须通过覆盖配置服务器来注入变量。例如，假设您有一个 Kubernetes 部署，它指向一个具有动态名称的服务（每次部署 Helm 图表时都会更改）。configserver 永远不会知道正确的名称，每次动态名称更改时都必须手动更改配置是很糟糕的。虽然，它可以通过更改存储库代码和提交的 Jenkins 管道来完成，但它太复杂了。 (2认同)