spring クラウド構成サーバーを使用するときの環境変数の優先順位について質問があります
私のサービスには、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
スプリングブートドキュメントのこの部分で読んだことから、環境変数は構成ファイルよりも優先される必要があります-また、スプリングクラウド構成ドキュメントにはsthの違いは記載されていません-したがって、結果は次のようになると予想されます。
{
"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
リポジトリの README には、ユース ケース 3としてここで説明されている問題がリストされています。