DockerでRabbitMqの共通クラスタとミラークラスタを構築する詳細な操作

通常のクラスター: 複数のノードで構成される通常のクラスター。メッセージは、いずれかのノードのキューにランダムに送信されます。他のノードはメタデータのみを保持します。各ノードには、キュー構造、スイッチ構造、vhost など、同じメタデータのみが含まれます。コンシューマーがメッセージを消費する場合、さまざまなノードからメッセージをプルします。メッセージを格納するノードに障害が発生すると、メッセージは消費できません。メッセージが永続化されている場合、消費する前にノードが回復するまで待つ必要があります。永続化されていない場合、メッセージは失われます。

ミラークラスター: 通常モードに基づいて、必要なキューがミラーキューに作成され、複数のノードに存在して高可用性 (HA) を実現します。このモードは上記の問題を解決します。ブローカーはミラーノード間でメッセージエンティティをアクティブに同期し、コンシューマーがデータを取得するときに一時的にデータをプルする必要がなくなります。このモードの副作用も明らかです。システムパフォーマンスが低下するだけでなく、ミラーキューが多すぎて大量のメッセージが入ると、クラスター内のネットワーク帯域幅が大量に消費されます。一般的に、信頼性要件が高いシナリオではミラーリングモードが推奨されます。

1. RabbitMqの動作環境を構築する

私のコンピューターはwindow10で、docker経由で2つのrabbitmqノードを構築しました。

1.検索を通じてrabbitmqイメージを照会する

docker 検索 rabbitmq

2. pullでrabbitmqの最新の公式イメージを取得する

タグ管理のあるバージョンをここに持ってくるのがベストです。そうしないと、最新バージョンをプルしたときに、Web管理ページでバージョン全体を表示できず、概要: 管理のみモードが表示されます。

docker pull rabbitmq:3.8.25-management

3. コンテナを作成する

docker run -d --name rabbitmq1 -p 5672:5672 -p 15672:15672 --hostname myRabbit1 -e RABBITMQ_DEFAULT_VHOST=my_vhost1 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin a4eb038c2ecb

--name: コンテナ名

-p: エンドポイントマッピング

--hostname: rabbitmq ノード名

-e RABBITMQ_DEFAULT_VHOST: 仮想ホスト名

-e RABBITMQ_DEFAULT_USER: ログインアカウント

-e RABBITMQ_DEFAULT_PASS: ログインパスワード

a4eb038c2ecb はイメージ ID です。状況に応じて置き換えてください。

4. 管理ページを起動する

このイメージでは、Web 管理ページがデフォルトで有効になっていないため、exec コマンドを使用してコンテナーに入り、起動します。このイメージの環境は Ubuntu です。

PS C:\> docker exec -it 639a151c5440 /bin/bash
root@myRabbit:/# rabbitmq-plugins は rabbitmq_management を有効にします

ブラウザで http://localhost:15672/ にアクセスして開きます。他の rabbitmq でも同じ操作を行います。違いは、ポートが 5673 や 15673 などに変更され、コンテナを作成するときに最初の rabbitmq ノードに接続するために --link が使用されることです (ブリッジネットワーク接続を作成することもできます)。

docker run -d --name rabbitmq2 -p 5673:5672 -p 15673:15672 --hostname myRabbit2 -e RABBITMQ_DEFAULT_VHOST=my_vhost2 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --link rabbitmq1:myRabbit1 a4eb038c2ecb

5. Erlangクッキーを設定する

元々、コンテナの実行時にパラメータ -e RABBITMQ_ERLANG_COOKIE を設定することで erlang クッキーを設定できましたが、現在は非推奨となっています。

まず、docker logsコマンドを使用してコンテナの実行ログを表示し、次のようにホームディレクトリパラメータを見つけます。

PS D:\> docker ログ rabbitmq1
//.....ここでは開始ブローカーは省略されています...2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0>
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> ノード: rabbit@myRabbit1
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> ホームディレクトリ: /var/lib/rabbitmq
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> 設定ファイル: /etc/rabbitmq/conf.d/10-default-guest-user.conf
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> : /etc/rabbitmq/conf.d/management_agent.disable_metrics_collector.conf
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> クッキーハッシュ: Aed9pjd9vYWw3hng7Gjmkg==
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> ログ: /var/log/rabbitmq/rabbit@myRabbit1_upgrade.log
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> : <標準出力>
2021-11-17 02:19:55.859245+00:00 [情報] <0.222.0> データベースディレクトリ: /var/lib/rabbitmq/mnesia/rabbit@myRabbit1

.erlang.cookieファイルはこのパスにあり、コンテナに入るとこのファイルを見ることができます。

root@myRabbit1:~# ls -a /var/lib/rabbitmq
. .. .bash_history .erlang.cookie mnesia

次に、Erlang クッキーの権限を設定し、コンテナ内で次のコードを実行します。権限が不十分な場合、後続の操作でエラーが報告されます。

chmod 600 /var/lib/rabbitmq/.erlang.cookie

次に、docker cp コマンドを使用して、rabbitmq1 の .erlang.cookie ファイルを物理マシンにコピーし、それを rabbitmq2 コンテナーにコピーします。物理マシンとコンテナー間のコピーコマンドは次のとおりです。

コンテナは物理マシンにファイルをコピーします: docker cp コンテナ名: コンテナディレクトリ
物理マシンのディレクトリ物理マシンはコンテナにファイルをコピーします: docker cp 物理マシンのディレクトリコンテナ名: コンテナのディレクトリ

具体的なコードは次のとおりです。

docker cp rabbitmq1:/var/lib/rabbitmq/ d:\workspace\
docker cp d:\workspace\rabbitmq\.erlang.cookie rabbitmq2:/var/lib/rabbitmq/

コピー後、rabbitmq2 コンテナを再起動する必要があります。そうしないと、rabbitmqctl コマンドの実行時に次のエラーが報告されます。

[エラー] Cookie ファイル /var/lib/rabbitmq/.erlang.cookie には所有者のみがアクセスできる必要があります

2. 通常モード

再起動後、コンテナに入り、rabbitmq1 に rabbitmq2 ノードを追加して通常のクラスターを作成します。それぞれ次のコードを実行します。

rabbitmqctl stop_app
rabbitmqctl リセット
rabbitmqctl join_cluster --ram rabbit@myRabbit1 //myRabbitmq1 は rabbitmq1 コンテナ内の rabbitmq のホスト名です
rabbitmqctl スタートアプリ

その後、Web 管理ページに 2 つのノードが表示されます。

いずれかのノードにキューを作成すると、他のノードにも同じキューが生成されます。また、rabbitmq2 の vhost が my_vhost2 から my_vhost1 に変更されていることがわかります。これは rabbitmq と同じです。

3. ミラーモード

ミラーモードは、通常モードに基づいて rabbitmq1 コンテナーに入り、次のコマンドを入力します。

rabbitmqctl set_policy -p my_vhost1 ha-all "^" '{"ha-mode":"all"}' --すべてに適用

具体的なフォーマットは

rabbitmqctl set_policy [-p Vhost] 名前 パターン 定義 [優先度]
-p Vhost: 指定された vhost の下のキューに設定されるオプションのパラメータ 名前: ポリシー名 パターン: キューの一致パターン (正規表現)
定義: イメージ定義。3 つの部分 (ha-mode、ha-params、ha-sync-mode) を含む
        ha-mode: ミラーキューモードを指定します。有効な値は all/exactly/nodes です。
            all: クラスター内のすべてのノードでミラーリングすることを示します。exactly: 指定された数のノードでミラーリングすることを示します。ノードの数は ha-params で指定します。nodes: 指定されたノードでミラーリングすることを示します。ノード名は ha-params で指定します。ha-params: パラメーターとして、ha-mode の補足となります。ha-sync-mode: キュー内のメッセージの同期モード。有効な値は自動と手動です。
優先度: オプションパラメータ、ポリシー優先度 rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}' --apply-to all

または、rabbitmq管理ページにログイン -> 管理 -> ポリシー -> ポリシーの追加/更新

名前: ポリシー名

パターン: ^ 一致文字。^ が 1 つだけの場合はすべてが一致することを意味します。 ^message は「message」で始まるキュー名を指します

定義: ha-mode=all はマッチングタイプであり、3 つのモードに分かれています: all (すべてのキューを示します)

優先度: まず、 priorityで並べ替えます。値が大きいほど、優先度が高くなります。同じpriorityの場合は、作成時間で並べ替えます。作成が遅いほど、優先度が高くなります。

オペレータポリシーとユーザーポリシーの違いを簡単に説明します。

オペレータポリシーは、サービスプロバイダーまたは企業のインフラストラクチャ部門によって、適用する必要がある特定の一般的なルールを設定するために使用されます。
ユーザーポリシーはビジネスアプリケーションのルールを設定するために使用されます

オペレータポリシーとユーザーポリシーが結合され、キューに適用されます。オペレータポリシーがDead Letter Exchange交換などのキューの特定の主要属性を上書きしてビジネスアプリケーションで予期しない結果が発生するのを防ぐため、オペレータポリシーでは、 expire 、 message-ttl 、 max-length 、およびmax-length-bytes 4 つのパラメータのみがサポートされます。

参考学習:

https://www.cnblogs.com/knowledgesea/p/6535766.html

https://blog.csdn.net/belonghuang157405/article/details/83540148

これで、Docker で RabbitMq の通常クラスタとミラークラスタを構築する方法についての記事は終了です。Docker で RabbitMq クラスタを構築する方法についての詳細は、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: