web-dev-qa-db-ja.com

Spring Cloud ConfigServerから複数の構成ファイルを読み取る方法

Springクラウド構成サーバーは、${spring.application.name}.propertiesという名前のプロパティファイルの読み取りをサポートしています。ただし、アプリケーションには2つのプロパティファイルがあります。

a.properties
b.properties

構成サーバーにこれらの両方のプロパティファイルを読み取らせることはできますか？

spring-cloudspring-cloud-config
10
David.Wang

構成サーバーが参照しているgitまたはファイルシステムでプロパティファイルの名前を変更します。

a.properties -> <your_application_name>.properties
a.properties -> <your_application_name>-<profile-name>.properties

たとえば、アプリケーション名がtestで、アプリケーションをdevプロファイルで実行している場合、以下の2つのプロパティが一緒に使用されます。

test.properties
test-dev.properties

また、構成クライアントのbootstrap.propertiesで追加のプロファイルを指定して、以下のようにさらに多くのプロパティファイルを取得することもできます。例えば、

spring:
  profiles: dev
  cloud:
    config:
      uri: http://yourconfigserver.com:8888
      profile: dev,dev-db,dev-mq

上記のように指定すると、以下のすべてのファイルが一緒に使用されます。

test.properties
test-dev.properties
test-dev-db.prpoerties
test-dev-mq.properties
14
yongsung.yoon

提供された回答は、プロパティファイルが異なる実行プロファイルに対応していることを前提としていることに注意してください。そうでない場合、つまり、プロパティが他の理由で異なるファイルに分割されている場合、たとえば、メンテナンス目的、ビジネス/機能ドメインで分割されている場合、またはニーズに合ったその他の理由で、そのようなファイルごとにプロファイルを定義することによって、目標（アプリごとに複数のプロパティファイル）を達成するために、プロファイル機能を「乱用」しているだけです。

次に、「OK、それで何が問題なのか」と尋ねることができます。問題は、他の方法では持つ可能性のあるさまざまな可能性から身を守ることです。実際にプロファイルごとにアプリケーション構成をカスタマイズする場合は、ファイル名がすでにプロファイルであるため、そのための疑似、サブ、プロファイルを作成する必要があります。例：

アプリケーション構成は、springbootアプリケーション内で使用するさまざまなプロファイル（@Profile（）アノテーションなど）によってカスタマイズできます。それらをdev、uat、prod。さまざまなプロファイルをアクティブとして設定して、アプリケーションを起動できます。 'dev' vs'uat '、そしてあなたが望むプロパティのグループを取得します。 a.properties b.propertiesおよびc.propertiesファイルの場合異なるファイル名がサポートされている場合、-dev。properties b-dev。propertiesおよびc-dev。propertiesファイルとa-uat。properties b-uat。propertiesおよびc-uat。propertiesファイル「dev」および「uat」プロファイル。

それでも、提供されたソリューションでは、ファイルごとにappname-a.properties appname-b.properties、およびappname-cの3つのプロファイルがすでに定義されています。 .properties：a、b、およびc。ここで、プロファイルごとに異なるプロファイルを作成する必要があると想像してください...プロファイル（！ここではすでに問題が発生していることが示されています）！最終的に多くのプロファイル順列になります（ファイルが増えると悪化します）：ファイルはappname-a-dev。properties、appname-b-dev。properties、app-c-dev。properties vs appname-a-uat。properties、appname-b-uat。properties、app-c-uat。propertiesですが、プロファイルは['dev'、 'uat']から['a-dev'、 'b-dev'、 'c-dev'、 'a-uat'、 ' b-uat '、' c-uat '] !!!

さらに悪いことに、コード内のこれらすべてのプロファイル、より具体的には@Profile（）アノテーションにどのように対処しますか？ 1つまたは2つの異なるプロパティファイルを追加したいという理由だけで、コードスペースを「人工」プロファイルで乱雑にしますか？該当する場合は、devまたはuatプロファイルを定義し、別の場所に該当するプロパティファイル名を定義するだけで十分です（これは、他の構成アクションなしで、プロファイルによってさらにサポートされる可能性があります） 個々のspringbootアプリの外部化されたプロパティ構成

引数を完全にするために、提供されているプロファイルベースの命名ソリューションを使用して、いつか。ymlプロパティファイルに切り替えたい場合は、ここに追加します。また、同じ.ymlファイル内で異なる「プロファイルごとのyamlドキュメントセクション」を定義する機能も失われます（はい、.ymlでは1つのプロパティファイルを内部に複数の論理ymlドキュメントを定義できます。これは通常、プロパティをカスタマイズするために行われます。関連するすべてのプロパティを1か所にまとめながら、さまざまなプロファイル）。ファイル名（appname-profile.yml）でプロファイルを既に使用しているため、機能が失われます

spring-cloud-config-server 1.4.xのマイナーな修正を含むプルリクエスト を発行しました。これにより、追加でサポートされるファイル名（「application [-profile]」および「{appname」からのアパート）を定義できます。 } [-profile] "、現在サポートされています）spring.cloud.congif.server.searchNames環境プロパティを提供することによって-springに類似しています。 SpringBootアプリのconfig.name。私はそれがレビューされ、受け入れられることを願っています。

6
user2435660

最近、同じ要件に遭遇しましたが、環境プロファイルを操作することは許可されていないというもう少し制約があります。だから私は受け入れられた答えとしてすることを許されませんでした。私と同じケースを持っているかもしれない人々の代わりとして、私がそれをどのようにしたかを共有しています。

私のアプリケーションには、次のようなプロパティがあります。

appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties

application.properties // for my use, contains local properties only
bootstrap.properties // for my use, contains management properties only

私のapplicationには、必要なことを達成できるようにするこれらの特定のプロパティが設定されています。ただし、残りの必要な構成もあることに注意してください（クラウド構成、アクチュエーターの更新、eurekaサービス検出などを有効にします）。これらを強調するために強調表示します。

spring.application.name=appxyz
spring.cloud.config.name=appxyz-data-soures,appxyz-interfaces,appxyz-feature

アプリケーション名をいじりたくなかったのに、代わりに構成プロパティファイルのプレフィックスとして使用したことがわかります。

私の構成サーバー私はapplication.ymlでpattern: 'appxyz-*'をキャプチャするように構成しました：

spring:
  cloud:
    config:
      server:
        git:
          uri: <git repo default>
          repos:
            appxyz:
              pattern: 'appxyz-*'
              uri: <another git repo if you have 1 repo per app>
              private-key: ${git.appxyz.pk}
          strict-Host-key-checking: false
          ignore-local-ssh-settings: true
          private-key: ${git.default.pk}

私のGitリポジトリには、次のものがあります。 application.propertiesとbootstrapは、外部で公開およびオーバーライド/更新されたくなかったためですが、必要に応じて実行できます。

appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties

一致するファイルをキャプチャしてgitリポジトリから返すのは、パターンマッチングpattern: 'appxyz-*'になります。プロファイルも適用され、それに応じて正しいプロパティファイルがフェッチされます。値の優先順位付けも保持されます。

さらに、アプリケーションにファイルを追加したい場合（たとえば、appxyz-circuit-breaker.properties）、次のことを行うだけで済みます。

  1. spring.cloud.config.name=...,appxyz-circuit-breakerに名前のパターンを追加します
  2. ファイルのコピーをローカルおよび外部（gitリポジトリ内）に追加します。

さらに追加/変更したり、後で構成サーバーを再起動したりする必要はありません。新しいアプリケーションの場合、application.ymlのreposの下にエントリを追加するのは1回限りの登録のようなものです。

それが何らかの形で役立つことを願っています！

1
mOchi