春のクラウドバス
1. 概要
この記事では、新しいSpringCloudBusプロジェクトについて説明します。 Spring Cloud Busは、軽量メッセージブローカーを使用して分散システムノードをリンクします。 主な用途は、構成の変更またはその他の管理情報をブロードキャストすることです。 分散型アクチュエータと考えることができます。
プロジェクトはトランスポートとしてAMQPブローカーを使用しますが、RabbitMQの代わりにApacheKafkaまたはRedisを利用できます。 他のトランスポートはまだサポートされていません。
このチュートリアルでは、RabbitMQをメインのトランスポートとして使用します。これは当然のことながらすでに実行されています。
2. 前提条件
始める前に、「SpringCloud構成のクイックイントロ」を完了しておくことをお勧めします。 既存のクラウド構成サーバーとクライアントを使用してそれらを拡張し、構成変更に関する自動通知を追加します。
2.1. RabbitMQ
まず、RabbitMQから始めましょう。これは、RabbitMQとしてdockerimageとして実行することをお勧めします。 これはセットアップが非常に簡単です。RabbitMQをローカルで実行するには、 Docker をインストールし、Dockerが正常にインストールされたら次のコマンドを実行する必要があります。
docker pull rabbitmq:3-management
このコマンドは、RabbitMQ Dockerイメージを、デフォルトでインストールおよび有効化されている管理プラグインと一緒にプルします。
次に、RabbitMQを実行できます。
docker run -d --hostname my-rabbit --name some-rabbit -p 15672:15672 -p 5672:5672 rabbitmq:3-management
コマンドを実行したら、Webブラウザーに移動して、 http:// localhost:15672 を開くと、管理コンソールのログインフォームが表示されます。 デフォルトのユーザー名は次のとおりです。‘guest’; パスワード:‘guest’。 RabbitMQはポート5672でもリッスンします。
3. CloudConfigクライアントへのアクチュエータの追加
クラウド構成サーバーとクラウド構成クライアントの両方を実行する必要があります。 構成の変更を更新するには、毎回クライアントを再起動する必要がありますが、これは理想的ではありません。
構成クライアントを停止し、ConfigClientコントローラークラスに@RefreshScopeで注釈を付けましょう。
@SpringBootApplication
@RestController
@RefreshScope
public class SpringCloudConfigClientApplication {
// Code here...
}
最後に、 pom.xml ファイルを更新して、アクチュエーターを追加しましょう。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-actuator</artifactId>
<version>2.2.6.RELEASE</version>
</dependency>
最新バージョンはここにあります。
デフォルトでは、アクチュエータによって追加されたすべての敏感なエンドポイントが保護されます。 これには、‘/refresh’エンドポイントが含まれます。 簡単にするために、application.ymlを更新してセキュリティをオフにします。
management:
security:
enabled: false
さらに、Spring Boot 2以降、アクチュエータエンドポイントはデフォルトでは公開されません。 それらをアクセスできるようにするには、これをapplication.ymlに追加する必要があります。
management:
endpoints:
web:
exposure:
include: "*"
最初にクライアントを起動し、GitHubのプロパティファイルで既存の‘Developer’から‘Programmer’にユーザーロールを更新しましょう。 構成サーバーは、更新された値をすぐに表示します。 ただし、クライアントはそうしません。 クライアントに新しいファイルを表示させるには、アクチュエータによって追加された‘/refresh’エンドポイントに空のPOSTリクエストを送信する必要があります。
$> curl -X POST http://localhost:8080/actuator/refresh
更新されたプロパティを示すJSONファイルが返されます。
[
"user.role"
]
最後に、ユーザーロールが更新されたかどうかを確認できます。
$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Programmer and your password is 'd3v3L'.
ユーザーロールは正常に更新され、‘/refresh’エンドポイントを呼び出しました。 クライアントは再起動せずに構成を更新しました。
4. 春のクラウドバス
Actuatorを使用することで、クライアントを更新できます。 ただし、クラウド環境では、すべてのクライアントに移動し、アクチュエータエンドポイントにアクセスして構成をリロードする必要があります。
この問題を解決するために、SpringCloudBusを使用できます。
4.1. クライアント
RabbitMQ交換にサブスクライブできるように、クラウド構成クライアントを更新する必要があります。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
最新バージョンはここにあります。
構成クライアントの変更を完了するには、RabbitMQの詳細を追加し、application.ymlファイルでクラウドバスを有効にする必要があります。
---
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
cloud:
bus:
enabled: true
refresh:
enabled: true
デフォルトのユーザー名とパスワードを使用していることに注意してください。 これは、実際の実稼働アプリケーション用に更新する必要があります。 このチュートリアルでは、これで問題ありません。
これで、クライアントには別のエンドポイント‘/bus-refresh’があります。 このエンドポイントを呼び出すと、次のようになります。
- 構成サーバーから最新の構成を取得し、@RefreshScopeで注釈が付けられた構成を更新します
- 更新イベントについて通知するメッセージをAMQP交換に送信します
- サブスクライブされたすべてのノードは、構成も更新します
このように、個々のノードに移動して構成の更新をトリガーする必要はありません。
4.2. サーバ
最後に、構成サーバーに2つの依存関係を追加して、構成の変更を完全に自動化します。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-monitor</artifactId>
<version>2.2.2.RELEASE</version>
</dependency>
最新バージョンはここにあります。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
<version>3.0.4.RELEASE</version>
</dependency>
最新バージョンはここにあります。
spring-cloud-config-monitor を使用して、構成の変更を監視し、RabbitMQをトランスポートとして使用してイベントをブロードキャストします。
application.properties を更新し、RabbitMQの詳細を提供する必要があります。
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest
4.3. GitHub Webhook
これですべてが設定されました。 サーバーは構成の変更について通知を受け取ると、これをメッセージとしてRabbitMQにブロードキャストします。 構成変更イベントが送信されると、クライアントはメッセージをリッスンし、構成を更新します。 しかし、サーバーはどのように変更を行うのでしょうか。
GitHubWebhookを構成する必要があります。 GitHubに移動して、構成プロパティを保持しているリポジトリを開きます。 それでは、設定とWebhookを選択しましょう。 Webhookの追加ボタンをクリックしてみましょう。
ペイロードURLは、構成サーバー‘/monitor’エンドポイントのURLです。 この場合、URLは次のようになります。
http:// root:s3cr3t @ REMOTE_IP:8888 / monitor
変更する必要がありますコンテンツタイプドロップダウンメニューで
5. テスト
すべてのアプリケーションが実行されていることを確認しましょう。 戻ってクライアントを確認すると、user.roleは‘Programmer’として、user.passwordは’d3v3L‘として表示されます。
$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Programmer and your password is 'd3v3L'.
以前は、‘/refresh’エンドポイントを使用して構成の変更を再ロードする必要がありました。 プロパティファイルを開き、user.roleをDeveloperに戻し、変更をプッシュしてみましょう。
user.role=Programmer
ここでクライアントを確認すると、次のように表示されます。
$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Developer and your password is 'd3v3L'.
構成クライアントは、再起動せずに、また明示的な更新なしで、構成をほぼ同時に更新しました。 GitHubに戻って、最近作成したWebhookを開くことができます。 一番下には、最近の配信があります。 リストの一番上から1つを選択し(これが最初の変更であると想定します。とにかく1つだけになります)、構成サーバーに送信されたJSONを調べることができます。
構成ログとサーバーログを確認することもでき、次のエントリが表示されます。
o.s.cloud.bus.event.RefreshListener: Received remote refresh request. Keys refreshed []
6. 結論
この記事では、既存のSpring Cloud構成サーバーとクライアントを使用し、アクチュエーターエンドポイントを追加してクライアント構成を更新しました。 次に、Spring Cloud Busを使用して、構成の変更をブロードキャストし、クライアントの更新を自動化しました。 また、GitHub Webhookを構成し、セットアップ全体をテストしました。
いつものように、ディスカッション中に使用されたコードは、GitHubのにあります。