10

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としてここで説明されている問題がリストされています。

4

1 に答える 1