Nacos でマルチ環境管理を構成する方法の概要 (詳細な手順)

この記事では、Nacos でマルチ環境管理を構成する方法の概要 (詳細な手順) を紹介します。必要な方は参考にしていただければ幸いです。あなたに。

複数の環境管理

Nacos には、データ ID、グループ、名前空間など、さまざまな管理レベルの複数の概念があります。これらの階層概念間の関係をうまく利用すれば、独自のニーズに応じたマルチ環境管理を実現できます。

次に、使用できるいくつかの実装方法を紹介します。

Data ID とプロファイルを使用して Nacos に実装する

Data ID はそのまま理解できます。 Spring Cloud アプリケーションの構成ファイル名。前回の記事「Spring Cloud Alibaba 基本チュートリアル: Nacos 設定読み込みルールの詳細な説明」から、デフォルトではデータ ID の名前形式が ${spring.application.name}.properties、つまり Spring であることがわかりました。クラウド アプリケーションの名前付きプロパティ ファイル。

実際、データ ID ルールには、Spring Cloud Config の設計に似た環境ロジックも含まれています。アプリケーションが起動すると、spring.profiles.active を通じて特定の環境名を指定できます。このとき、クライアントはデータ ID を整理して、${spring.application.name}-${spring.profiles として構成を取得します。 .active}.properties.

実際、より独創的で最も一般的な一致ルールは次のとおりです: ${spring.cloud.nacos.config.prefix}-${spring.profile.active}.${spring.cloud.nacos.config .ファイル拡張子}。上記の結果は、${spring.cloud.nacos.config.prefix} と ${spring.cloud.nacos.config.file-extension} の両方がデフォルト値を使用しているためです。

試してみましょう

記事「Spring Cloud Alibaba Basic Tutorial: Using Nacos as the Configuration Center」(次のウェアハウスで入手可能) の例を使用できます。記事終わり） 基本として、環境を区別するこの設定方法を体験してみましょう。

ステップ 1: まず、Nacos で、このルールに基づいて 2 つの異なる環境の構成コンテンツを作成します。例:

上記のように、alibaba-nacos-config-client アプリケーションの DEV と TEST に対して 2 つの独立した環境構成を定義しました。後で正しい構成が実際にロードされているかどうかを確認できるように、その中でさまざまなコンテンツ値を定義できます。

ステップ 2: alibaba-nacos-config-client アプリケーションの構成ファイルに、環境構成を追加します: spring.profiles.active=DEV

ステップ 3: アプリケーションを起動します。ロードされた設定ファイルがログに出力されているのを確認できますか:

2019-01-30 15:25:18.216  INFO 96958 --- [           main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client-DEV.properties', group: 'DEFAULT_GROUP'

グループを使用した実装

グループは、Nacos でのデータ ID のコレクション管理に使用される重要な概念です。したがって、環境の構成をセットとして捉えると、異なる環境の構成管理を実現できます。 Groupの利用に関しては決まった規定がないため、実際に利用する際には、アーキテクチャの運用・保守といった複数の環境の管理や、異なるモジュールのパラメータ管理など、ニーズに合わせて利用する必要があります。ビジネスで。競合を避けるために、アーキテクチャ設計の開始時に特定の計画を立てる必要があります。ここではまず、Group を使用して複数環境の構成管理を実装する方法の具体的な実装について説明します。

自分で試してみる

ステップ 1: まず、Nacos で、グループを区別して 2 つの異なる環境の構成コンテンツを作成します。例:

上に示すように、alibaba-nacos-config-client アプリケーションに対して DEV 環境と TEST 環境の 2 つの独立した構成を定義しました。これら 2 つの一致は前の方法とは異なります。それらのデータ ID はまったく同じですが、GROUP のみが異なります。

ステップ 2: alibaba-nacos-config-client アプリケーションの構成ファイルに、グループの指定された構成を追加します: spring.cloud.nacos.config.group=DEV_GROUP

Step 3 : アプリケーションを起動すると、読み込まれた設定ファイルがログに出力されることがわかります。

2019-01-30 15:55:23.718  INFO 3216 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client.properties', group: 'DEV_GROUP'

Using Namespace toimplement

Namespace は、この一連のチュートリアルで初めて登場します。まずは公式の概念説明を見てみましょう。テナント単位の詳細な構成の分離に使用されます。同じグループまたはデータ ID の構成は、異なる名前空間に存在できます。ネームスペースの一般的なシナリオの 1 つは、開発およびテスト環境と運用環境の間でのリソース (構成やサービスなど) の分離など、さまざまな環境における構成の区別と分離です。

公式の紹介では環境隔離として使えると紹介されていましたので試してみましょう。

最初に試してみる

ステップ 1: まず、Nacos の環境名に基づいて複数の名前空間を作成します。例:

ステップ 2: 構成リストの上部には、Public に加えて、作成されたばかりの Namepsace がさらにいくつかあることがわかります。 alibaba-nacos-config-client アプリケーションの構成コンテンツを DEV スペースと TEST スペースにそれぞれ作成します:

ステップ 3: alibaba-nacos-config-client アプリケーションの構成ファイルに、指定された名前空間の構成を追加します (例: spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a)。 。

ここで、名前空間の設定では名前は使用されず、名前空間の ID が使用されることに注意してください。

ステップ 4: アプリケーションを起動し、localhost:8001/test インターフェイスにアクセスして、返されたコンテンツが正しいかどうかを確認します。このように、現在のバージョンのログでは名前空間に関する情報が出力されないため、ロードする内容を決定する根拠として使用することができません。

詳細な考え方

上記では、Nacos 構成管理機能のいくつかの異なる次元を使用して、マルチ環境構成管理を実現しました。結果的にはどの方法を使ってもニーズは満たせますが、どれが一番良いのでしょうか？

最初のタイプ: データ ID とプロファイルによって実現されます。

利点: この方法は Spring Cloud Config の実装に非常に似ています。Spring Cloud Config を使用していたユーザーは、名前付けルールが似ているため、Spring Cloud Config から開始する必要があります。クラウド構成の移行も非常に簡単です。

欠点: この方法では、プロジェクトや環境が多数ある場合、構成内容が非常にわかりにくくなります。構成リストにはさまざまなアプリケーションが表示され、さまざまな環境の構成が絡み合っており、管理上非常に不利です。

提案: プロジェクトの数がそれほど多くない場合に使用するか、グループと組み合わせて、ビジネスまたは組織構造に応じてプロジェクトの分割計画を立てることができます。

2 番目のタイプ: グループを通じて実装されます。

利点: 各アプリケーションの構成は、グループを通じて環境ごとに分離されます。データ ID とグループの検索機能を使用すると、それぞれアプリケーション ラチチュードと環境ラチチュードから構成を表示することができ、非常に便利です。

欠点: グループの範囲を占有するため、ビジネス内の一部の構成グループと競合する可能性があるため、グループの使用を計画する必要があります。

提案: この方法は以前の方法よりも構造的には優れていますが、依然として混乱を引き起こす可能性があります。重要なのは、グループの経営を計画し、管理することです。

3 番目のタイプ: 名前空間を通じて実装されます。

利点: 公式に推奨されている方法では、名前空間を使用してさまざまな環境を区別し、グループの自由を解放し、グループの使用をビジネス レベルでのグループ管理に集中できるようにします。同時に、Nacos コントロール ページでは、名前空間もグループで表示され、検索せずに異なる環境構成を分離することができ、非常に使いやすくなります。

短所: 欠点はありません。おそらく、もう 1 つの概念が導入され、ユーザーがそれを理解する必要があります。

提案: この方法を直接使用した方が、長期的にはより安心です。小規模なチームの場合、プロジェクトの数はそれほど多くないかもしれないので、1 番目と 2 番目の方法で十分ですが、後で規模が大きくなった場合はどうなるでしょうか。

注: それを達成するためにどの方法が使用されても構いません。指定された環境 (spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a) の構成については、次のようにします。アプリケーションの bootstrap.properties で設定しないでください。代わりに、 -Dspring.profiles.active=DEV を使用して、リリース スクリプトの起動コマンドで動的に指定します。これにより、より柔軟になります。

以上がNacos でマルチ環境管理を構成する方法の概要 (詳細な手順)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。