ホーム
製品
Red Hat AMQ Broker
7.10
OpenShift での AMQ Broker のデプロイ
4.8. クライアント接続用の Operator ベースのブローカーデプロイメントの設定

4.8. クライアント接続用の Operator ベースのブローカーデプロイメントの設定

4.8.1. アクセプターの設定
リンクのコピー

OpenShift デプロイメントでブローカー Pod へのクライアント接続を有効にするには、デプロイメントのアクセプターを定義します。アクセプターは、ブローカー Pod が接続を受け入れる方法を定義します。ブローカーのデプロイメントに使用されるメインのカスタムリソース (CR) でアクセプターを定義します。アクセプターを作成する場合は、アクセプターを有効にするメッセージングプロトコルや、これらのプロトコルに使用するブローカー Pod のポートなどの情報を指定します。

以下の手順は、ブローカーデプロイメントの CR で新規アクセプターを定義する方法を示しています。

手順

初回インストール時にダウンロードしてデプロイメントした Operator アーカイブの deploy/crs ディレクトリーで、broker_activemqartemis_cr.yaml カスタムリソース (CR) ファイルを開きます。

acceptors 要素に名前付きアクセプターを追加します。protocols および port パラメーターを追加します。値を設定して、アクセプターおよび各ブローカー Pod のポートによってこれらのプロトコル用に公開されるメッセージングプロトコルを指定します。以下に例を示します。

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp
    port: 5672
...

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp
    port: 5672
...

Copy to Clipboard

Toggle word wrap

設定されたアクセプターはポート 5672 を AMQP クライアントに公開します。protocols パラメーターに指定できる値の完全なセットが表に表示されます。

Expand

プロトコル	値
Core Protocol	`core`
AMQP	`amqp`
OpenWire	`openwire`
MQTT	`mqtt`
STOMP	`stomp`
すべてのサポート対象プロトコル	`all`

注記

デプロイメントの各ブローカー Pod に対して、Operator はポート 61616 を使用するデフォルトのアクセプターも作成します。このデフォルトのアクセプターはブローカークラスタリングに必要ですが、Core Protocol は有効になっています。
デフォルトでは、AMQ Broker 管理コンソールはブローカー Pod で 8161 ポートを使用します。デプロイメントの各ブローカー Pod には、コンソールへのアクセスを提供する専用のサービスがあります。詳細は、5章Operator ベースのブローカーデプロイメント用の AMQ 管理コンソールへの接続 を参照してください。

同じアクセプターで別のプロトコルを使用するには、protocol パラメーターを変更します。プロトコルのコンマ区切りリストを指定します。以下に例を示します。
```
spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
...
```
```
spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
...
```
Copy to Clipboard Toggle word wrap
設定されたアクセプターはポート 5672 を AMQP および OpenWire クライアントに公開するようになりました。

アクセプターが許可する同時クライアント接続の数を指定するには、connectionAllowed パラメーターを追加して値を設定します。以下に例を示します。

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
...

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
...

Copy to Clipboard

Toggle word wrap

デフォルトでは、アクセプターはブローカーデプロイメントと同じ OpenShift クラスターのクライアントにのみ公開されます。アクセプターを OpenShift 外部のクライアントに公開するには、expose パラメーターを追加し、値を true に設定します。
```
spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
    expose: true
    ...
...
```
```
spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
    expose: true
    ...
...
```
Copy to Clipboard Toggle word wrap
OpenShift 外部にあるクライアントにアクセプターを公開すると、Operator はデプロイメント内のブローカー Pod ごとに専用のサービスとルートを自動作成します。
OpenShift 外部のクライアントからアクセプターへのセキュアな接続を有効にするには、sslEnabled パラメーターを追加し、値を true に設定します。
```
spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
    expose: true
    sslEnabled: true
    ...
...
```
```
spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    connectionsAllowed: 5
    expose: true
    sslEnabled: true
    ...
...
```
Copy to Clipboard Toggle word wrap
アクセプター (またはコネクター) で SSL (Secure Sockets Layer) セキュリティーを有効にすると、以下のような関連する設定を追加できます。
- OpenShift クラスターに認証情報を保存するために使用されるシークレット名。アクセプターで SSL を有効にする場合は、シークレットが必要です。このシークレットの生成に関する詳細は、「ブローカークライアント接続のセキュリティー保護」を参照してください。
- セキュアなネットワーク通信に使用する TLS (Transport Layer Security) プロトコル。TLS は、よりセキュアな SSL バージョンで更新されています。enabledProtocols パラメーターで TLS プロトコルを指定します。
- ブローカーとクライアント間で、アクセプターが相互認証とも呼ばれる双方向 TLS を使用するかどうか。これは、needClientAuth パラメーターの値を true に設定して指定します。

関連情報

認証情報を保存するシークレットの生成など、ブローカークライアント接続をセキュアにするように TLS を設定する方法は、「ブローカークライアント接続のセキュリティー保護」を参照してください。
アクセプターおよびコネクターの設定を含む完全なカスタムリソース参照については、「カスタムリソース設定リファレンス」を参照してください。

4.8.2. ブローカークライアント接続のセキュリティー保護
リンクのコピー

アクセプターまたはコネクター (sslEnabled を true に設定) でセキュリティーを有効にしている場合、ブローカーとクライアント間での証明書ベースの認証を許可するように Transport Layer Security (TLS) を設定する必要があります。TLS は、よりセキュアな SSL バージョンで更新されています。2 つの主要な TLS 設定があります。

一方向 TLS: ブローカーのみが証明書を表示します。証明書はクライアントによってブローカーを認証するために使用されます。これが最も一般的な設定です。
双方向 TLS: ブローカーとクライアントの両方が証明書を提示します。これは相互認証と呼ばれることもあります。

これ以降のセクションで以下を説明します。

一方向と双方向 TLS の両方の場合、ブローカーとクライアント間の正常な TLS ハンドシェイクに必要な認証情報を保存するシークレットを生成して、設定を完了します。これは、セキュアなアクセプターまたはコネクターの sslSecret パラメーターに指定する必要のあるシークレット名です。シークレットには、Base64 でエンコードされたブローカーキーストア (一方向と双方向 TLS の両方)、Base64 でエンコードされたブローカートラストストア (two-way TLS のみ)、およびこれらのファイルに対応するパスワード (Base64 エンコード) が含まれる必要があります。一方向および双方向 TLS の設定手順では、このシークレットの生成方法を説明します。

注記

セキュアなアクセプターまたはコネクターの sslSecret パラメーターにシークレット名を明示的に指定しないと、アクセプターまたはコネクターはデフォルトのシークレット名を想定します。デフォルトのシークレット名は、 <custom_resource_name>- <acceptor_name>-secret または <custom_resource_name>- <connector_name>-secret の形式を使用します。例: my-broker-deployment-my-acceptor-secret

アクセプターまたはコネクターがデフォルトのシークレット名を想定している場合でも、このシークレットを独自に生成する必要があります。これは自動的に作成されません。

4.8.2.1. ホスト名検証用のブローカー証明書の設定
リンクのコピー

注記

本セクションでは、一方向または双方向 TLS の設定時に生成する必要のあるブローカー証明書の要件をいくつか説明します。

クライアントがデプロイメントでブローカー Pod への接続を試行する場合、クライアント接続 URL の verifyHost オプションはクライアントによって、ブローカーの証明書の Common Name (CN) をホスト名に比較するかどうかを判別し、一致することを確認します。クライアントが、クライアント接続 URL に verifyHost=true や同様の場合、クライアントはこの検証を実行します。

たとえば、ブローカーが分離されたネットワークの OpenShift クラスターにデプロイされる場合など、接続のセキュリティーに懸念がない場合、この検証を省略する場合があります。セキュアな接続では、クライアントがこの検証を実行することが推奨されます。この場合、ブローカーキーストア証明書の正しい設定は、クライアント接続を成功させるために不可欠です。

通常、クライアントがホストの検証を使用している場合、ブローカー証明書の生成時に指定する CN はクライアントが接続しているブローカー Pod の Route の完全なホスト名と一致する必要があります。たとえば、単一のブローカー Pod を持つデプロイメントがある場合、CN は以下のようになります。

CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain

CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain

Copy to Clipboard

Toggle word wrap

CN が複数のブローカーを持つデプロイメントの任意のブローカー Pod に解決するようにするには、ブローカー Pod の ordinal の場所でアスタリスク (*) ワイルドカード文字を指定できます。以下に例を示します。

CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain

CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain

Copy to Clipboard

Toggle word wrap

前述の例に記載されている CN は、my-broker-deployment デプロイメントのブローカー Pod に正常に解決します。

さらに、ブローカー証明書の生成時に指定する SAN (Subject Alternative Name) は、コンマ区切りのリストとして、デプロイメント内のすべてのブローカー Pod を個別にリスト表示する必要があります。以下に例を示します。

"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."

"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."

Copy to Clipboard

Toggle word wrap

4.8.2.2. 一方向 TLS の設定
リンクのコピー

本セクションの手順では、broker-client 接続のセキュリティーを保護するために一方向トランスポート層セキュリティー (TLS) を設定する方法を説明します。

一方向 TLS では、証明書を表示するブローカーのみが表示されます。この証明書は、クライアントがブローカーを認証するために使用されます。

前提条件

クライアントがホスト名の検証を使用する場合のブローカー証明書の生成の要件を理解する必要があります。詳細は、「ホスト名検証用のブローカー証明書の設定」を参照してください。

手順

ブローカーキーストアの自己署名証明書を生成します。

keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks

$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks

Copy to Clipboard

Toggle word wrap

ブローカーキーストアから証明書をエクスポートし、クライアントと共有できるようにします。Base64 エンコードの .pem 形式の証明書をエクスポートします。以下に例を示します。
```
keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
```
```
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
```
Copy to Clipboard Toggle word wrap
クライアントで、ブローカー証明書をインポートするクライアントトラストストアを作成します。
```
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
```
```
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
```
Copy to Clipboard Toggle word wrap
管理者として OpenShift Container Platform にログインします。以下に例を示します。
```
oc login -u system:admin
```
```
$ oc login -u system:admin
```
Copy to Clipboard Toggle word wrap
ブローカーのデプロイメントが含まれるプロジェクトに切り替えます。以下に例を示します。
```
oc project <my_openshift_project>
```
```
$ oc project <my_openshift_project>
```
Copy to Clipboard Toggle word wrap
TLS 認証情報を保存するためのシークレットを作成します。以下に例を示します。
```
oc create secret generic my-tls-secret \
--from-file=broker.ks=~/broker.ks \
--from-file=client.ts=~/client.ks \
--from-literal=keyStorePassword=<password> \
--from-literal=trustStorePassword=<password>
```
```
$ oc create secret generic my-tls-secret \
--from-file=broker.ks=~/broker.ks \
--from-file=client.ts=~/client.ks \
--from-literal=keyStorePassword=<password> \
--from-literal=trustStorePassword=<password>
```
Copy to Clipboard Toggle word wrap
注記
シークレットを生成する際に、OpenShift ではキーストアとトラストストアの両方を指定する必要があります。トラストストアキーは、基本的に client.ts という名前です。ブローカーとクライアント間の一方向 TLS では、トラストストアは実際には必要ありません。ただし、シークレットを正常に生成するには、一部の有効なストアファイルを client.ts の値として指定する必要があります。前述の手順では、以前に生成されたブローカーキーストアファイルを再利用することで、client.ts の dummy 値を指定します。これは、一方向 TLS に必要なすべての認証情報でシークレットを生成するには十分です。
シークレットを Operator のインストール時に作成したサービスアカウントにリンクします。以下に例を示します。
```
oc secrets link sa/amq-broker-operator secret/my-tls-secret
```
```
$ oc secrets link sa/amq-broker-operator secret/my-tls-secret
```
Copy to Clipboard Toggle word wrap

セキュアなアクセプターまたはコネクターの sslSecret パラメーターにシークレット名を指定します。以下に例を示します。

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    sslEnabled: true
    sslSecret: my-tls-secret
    expose: true
    connectionsAllowed: 5
...

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    sslEnabled: true
    sslSecret: my-tls-secret
    expose: true
    connectionsAllowed: 5
...

Copy to Clipboard

Toggle word wrap

4.8.2.3. 双方向 TLS の設定
リンクのコピー

本セクションの手順では、broker-client 接続のセキュリティーを保護するために双方向トランスポート層セキュリティー (TLS) を設定する方法を説明します。

双方向 TLS では、ブローカーとクライアントの両方が証明書を表示します。ブローカーおよびクライアントはこれらの証明書を使用して相互認証と呼ばれることもあります。

前提条件

クライアントがホスト名の検証を使用する場合のブローカー証明書の生成の要件を理解する必要があります。詳細は、「ホスト名検証用のブローカー証明書の設定」を参照してください。

手順

ブローカーキーストアの自己署名証明書を生成します。

keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks

$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks

Copy to Clipboard

Toggle word wrap

ブローカーキーストアから証明書をエクスポートし、クライアントと共有できるようにします。Base64 エンコードの .pem 形式の証明書をエクスポートします。以下に例を示します。
```
keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
```
```
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
```
Copy to Clipboard Toggle word wrap
クライアントで、ブローカー証明書をインポートするクライアントトラストストアを作成します。
```
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
```
```
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
```
Copy to Clipboard Toggle word wrap
クライアントで、クライアントキーストアの自己署名証明書を生成します。
```
keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
```
```
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
```
Copy to Clipboard Toggle word wrap
クライアントで、クライアントキーストアから証明書をエクスポートし、ブローカーと共有できるようにします。Base64 エンコードの .pem 形式の証明書をエクスポートします。以下に例を示します。
```
keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
```
```
$ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
```
Copy to Clipboard Toggle word wrap
クライアント証明書をインポートするブローカートラストストアを作成します。
```
keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
```
```
$ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
```
Copy to Clipboard Toggle word wrap
管理者として OpenShift Container Platform にログインします。以下に例を示します。
```
oc login -u system:admin
```
```
$ oc login -u system:admin
```
Copy to Clipboard Toggle word wrap
ブローカーのデプロイメントが含まれるプロジェクトに切り替えます。以下に例を示します。
```
oc project <my_openshift_project>
```
```
$ oc project <my_openshift_project>
```
Copy to Clipboard Toggle word wrap
TLS 認証情報を保存するためのシークレットを作成します。以下に例を示します。
```
oc create secret generic my-tls-secret \
--from-file=broker.ks=~/broker.ks \
--from-file=client.ts=~/broker.ts \
--from-literal=keyStorePassword=<password> \
--from-literal=trustStorePassword=<password>
```
```
$ oc create secret generic my-tls-secret \
--from-file=broker.ks=~/broker.ks \
--from-file=client.ts=~/broker.ts \
--from-literal=keyStorePassword=<password> \
--from-literal=trustStorePassword=<password>
```
Copy to Clipboard Toggle word wrap
注記
シークレットを生成する際に、OpenShift ではキーストアとトラストストアの両方を指定する必要があります。トラストストアキーは、基本的に client.ts という名前です。ブローカーとクライアント間の双方向 TLS の場合は、クライアント証明書を保持するため、ブローカートラストストアを含むシークレットを生成する必要があります。そのため、前の手順では、client.ts キーに指定した値は実際に ブローカー のトラストストアファイルになります。
シークレットを Operator のインストール時に作成したサービスアカウントにリンクします。以下に例を示します。
```
oc secrets link sa/amq-broker-operator secret/my-tls-secret
```
```
$ oc secrets link sa/amq-broker-operator secret/my-tls-secret
```
Copy to Clipboard Toggle word wrap

セキュアなアクセプターまたはコネクターの sslSecret パラメーターにシークレット名を指定します。以下に例を示します。

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    sslEnabled: true
    sslSecret: my-tls-secret
    expose: true
    connectionsAllowed: 5
...

spec:
...
  acceptors:
  - name: my-acceptor
    protocols: amqp,openwire
    port: 5672
    sslEnabled: true
    sslSecret: my-tls-secret
    expose: true
    connectionsAllowed: 5
...

Copy to Clipboard

Toggle word wrap

4.8.3. ブローカーデプロイメントのネットワークサービス
リンクのコピー

ブローカーデプロイメントの OpenShift Container Platform Web コンソールの Networking ペインで、2 つの実行中のサービスがあり、ヘッドレス サービスと ping サービスが 2 つあります。ヘッドレスサービスのデフォルト名は、<custom_resource_name>-hdls-svc の形式を使用します (例: my-broker-deployment-hdls-svc)。ping サービスのデフォルト名は、<custom_resource_name>-ping-svc の形式を使用します (例: `my-broker-deployment-ping-svc)。

ヘッドレスサービスは、内部ブローカークラスタリングに使用されるポート 61616 へのアクセスを提供します。

ping サービスは検出のブローカーによって使用されます。また、ブローカーは OpenShift 環境内でクラスターを形成できるようにします。内部的には、このサービスはポート 8888 を公開します。

4.8.4. 内部および外部クライアントからのブローカーへの接続
リンクのコピー

このセクションの例では、内部クライアント (つまりブローカーデプロイメントと同じ OpenShift クラスターのクライアント) および外部クライアント (OpenShift クラスター外のクライアント) からブローカーに接続する方法を示しています。

4.8.4.1. 内部クライアントからのブローカーへの接続
リンクのコピー

内部クライアントをブローカーに接続するには、クライアント接続の詳細で、ブローカー Pod の DNS 解決可能な名前を指定します。以下に例を示します。

tcp://ex–aao-ss-0:<port>

$ tcp://ex–aao-ss-0:<port>

Copy to Clipboard

Toggle word wrap

内部クライアントがコアプロトコルを使用していて、useTopologyForLoadBalancing=false キーが接続 URL に設定されていない場合、クライアントがブローカーに初めて接続した後、ブローカーはクラスター内のすべてのブローカーのアドレスをクライアントに通知することができます。その後、クライアントはすべてのブローカー間で接続の負荷を分散できます。

ブローカーに永続的なサブスクリプションキューまたはリクエスト/応答キューがある場合は、クライアント接続の負荷が分散されているときにこれらのキューを使用する場合の注意事項に注意してください。詳細は、「永続的なサブスクリプションキューまたはリクエスト/要求キューがある場合のクライアント接続の負荷分散に関する警告」を参照してください。

4.8.4.2. 外部クライアントからのブローカーへの接続
リンクのコピー

外部クライアントにアクセプターを公開する場合 (つまり expose パラメーターの値を true に設定して)、Operator により、デプロイメントの各ブローカー Pod に専用のサービスと Route が自動的に作成されます。

外部クライアントはブローカー Pod 用に作成される Route の完全なホスト名を指定して、ブローカーに接続できます。基本的な curl コマンドを使用して、この完全なホスト名への外部アクセスをテストできます。以下に例を示します。

curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain

$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain

Copy to Clipboard

Toggle word wrap

ブローカー Pod のルートの完全なホスト名は、OpenShift ルーターをホストしているノードに解決される必要があります。OpenShift ルーターは、ホスト名を使用して、OpenShift 内部ネットワーク内のトラフィックを送信する場所を判別します。デフォルトでは、OpenShift ルーターは、セキュアでないトラフィック (SSL 以外) トラフィックとポート 443 (SSL で暗号化した) トラフィックに対してポート 80 をリッスンします。HTTP 接続の場合、ルーターはセキュアな接続 URL (https) を指定する場合 (https) またはポート 80 を指定する場合は、トラフィックをポート 443 に自動的に転送します。

外部クライアントでクラスター内のブローカー間で接続の負荷を分散する場合は、次のようにします。

各ブローカー Pod の OpenShift ルートで haproxy.router.openshift.io/balance ラウンドロビンオプションを設定して、ロードバランシングを有効にします。
外部クライアントがコアプロトコルを使用する場合、デフォルトでは、useTopologyForLoadBalancing 設定オプションが true に設定されています。接続 URL でこの値が false に設定されていないことを確認してください。

ブローカーに永続的なサブスクリプションキューまたはリクエスト/応答キューがある場合は、クライアント接続の負荷を分散するときにこれらのキューを使用する際の注意事項に注意してください。詳細は、「永続的なサブスクリプションキューまたはリクエスト/要求キューがある場合のクライアント接続の負荷分散に関する警告」を参照してください。

外部クライアントがクラスター内のブローカー間で接続の負荷を分散しないようにする場合は、次のようにします。

各クライアントが使用する接続 URL に useTopologyForLoadBalancing=false キーを設定します。
各クライアントの接続 URL で、各ブローカー Pod のルートの完全なホスト名を指定します。クライアントは、接続 URL の最初のホスト名に接続しようとします。ただし、最初のホスト名が使用できない場合、クライアントは接続 URL の次のホスト名に自動的に接続します。

HTTP 以外の接続の場合:

クライアントは、接続 URL の一部としてポート番号 (ポート 443 など) を明示的に指定する必要があります。
一方向 TLS では、クライアントは接続 URL の一部としてトラストストアと対応するパスワードへのパスを指定する必要があります。
双方向 TLS の場合、クライアントは接続 URL の一部としてそのキーストアと対応するパスワードへのパスも指定する必要があります。

以下は、サポートされるメッセージングプロトコル用のクライアント接続 URL の例は次のとおりです。

一方向 TLS を使用する外部 Core クライアント

tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>

tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>

Copy to Clipboard

Toggle word wrap

注記

外部コアクライアントはブローカーによって返されるトポロジー情報を使用できないため、useTopologyForLoadBalancing キーは接続 URL で false に明示的に設定されます。このキーが true に設定されているか、値を指定しないと、DEBUG ログメッセージが作成されます。

双方向 TLS を使用する外部 Core クライアント

tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&keyStorePath=~/client.ks&keyStorePassword=<password> \
&trustStorePath=~/client.ts&trustStorePassword=<password>

tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&keyStorePath=~/client.ks&keyStorePassword=<password> \
&trustStorePath=~/client.ts&trustStorePassword=<password>

Copy to Clipboard

Toggle word wrap

一方向 TLS を使用する外部 OpenWire クライアント

ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"

# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>

ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"

# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>

Copy to Clipboard

Toggle word wrap

双方向 TLS を使用する外部 OpenWire クライアント

ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"

# Also, specify the following JVM flags
-Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>

ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"

# Also, specify the following JVM flags
-Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>

Copy to Clipboard

Toggle word wrap

一方向 TLS を使用する外部 AMQP クライアント

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>

Copy to Clipboard

Toggle word wrap

双方向 TLS を使用する外部 AMQP クライアント

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>

Copy to Clipboard

Toggle word wrap

4.8.4.3. NodePort を使用したブローカーへの接続
リンクのコピー

Route を使用する代わりに、OpenShift 管理者は NodePort を OpenShift 外部のクライアントからブローカー Pod に接続するように設定できます。NodePort は、ブローカーに設定されたアクセプターによって指定されるプロトコル固有のポートのいずれかにマップする必要があります。

デフォルトで、NodePort は 30000 から 32767 の範囲に置かれます。つまり、NodePort はブローカー Pod の意図されるポートとは一致しません。

NodePort 経由で OpenShift 外のクライアントからブローカーに接続するには、 <protocol>://<ocp_node_ip>:<node_port_number> の形式で URL を指定します。

4.8.4.4. 永続的なサブスクリプションキューまたはリクエスト/要求キューがある場合のクライアント接続の負荷分散に関する警告
リンクのコピー

永続サブスクリプション

永続サブスクリプションはブローカー上のキューとして表され、永続サブスクライバーが最初にブローカーに接続したときに作成されます。このキューは存在し、クライアントがサブスクライブを解除するまでメッセージを受信します。クライアントが別のブローカーに再接続すると、そのブローカーに別の永続サブスクリプションキューが作成されます。これにより、次の問題が発生する可能性があります。

Expand

問題軽減策

問題	軽減策
メッセージは元のサブスクリプションキューで取り残される可能性があります。	メッセージの再配布が有効になっていることを確認します。詳細は、Enabling message redistribution を参照してください。
他のメッセージがまだルーティングされているときにメッセージの再配布中にウィンドウが表示されるため、メッセージが間違った順序で受信される可能性があります。	なし。
クライアントがサブスクライブを解除すると、最後に接続したブローカーでのみキューが削除されます。これは、他のキューがまだ存在してメッセージを受信できることを意味します。	サブスクライブを解除したクライアントに存在する可能性のある他の空のキューを削除するには、次の両方のプロパティーを設定します。 `auto-delete-queues-message-count` プロパティーを `0` に設定して、キューにメッセージがない場合にのみキューを削除できるようにします。`auto-delete-queues-delay` プロパティーを設定して、指定されたミリ秒数の間使用されなかった後にメッセージがないキューを削除します。詳細は、Configuring automatic creation and deletion of addresses and queues を参照してください。

メッセージは元のサブスクリプションキューで取り残される可能性があります。

メッセージの再配布が有効になっていることを確認します。詳細は、Enabling message redistribution を参照してください。

他のメッセージがまだルーティングされているときにメッセージの再配布中にウィンドウが表示されるため、メッセージが間違った順序で受信される可能性があります。

なし。

クライアントがサブスクライブを解除すると、最後に接続したブローカーでのみキューが削除されます。これは、他のキューがまだ存在してメッセージを受信できることを意味します。

サブスクライブを解除したクライアントに存在する可能性のある他の空のキューを削除するには、次の両方のプロパティーを設定します。

auto-delete-queues-message-count プロパティーを 0 に設定して、キューにメッセージがない場合にのみキューを削除できるようにします。auto-delete-queues-delay プロパティーを設定して、指定されたミリ秒数の間使用されなかった後にメッセージがないキューを削除します。

詳細は、Configuring automatic creation and deletion of addresses and queues を参照してください。

リクエスト/応答キュー

JMS プロデューサーが一時応答キューを作成すると、ブローカー上にキューが作成されます。作業キューから消費して一時キューに応答しているクライアントが別のブローカーに接続すると、次の問題が発生する可能性があります。

Expand

問題	軽減策
クライアントが接続しているブローカーに応答キューが存在しないため、クライアントがエラーを生成する可能性があります。	`auto-create-queues` プロパティーが `true` に設定されていることを確認します。詳細は、Configuring automatic creation and deletion of addresses and queues を参照してください。
ワークキューに送信されたメッセージは配信されない場合があります。	`message-load-balancing` プロパティーを `ON-DEMAND` に設定して、メッセージがオンデマンドで負荷分散されるようにします。また、メッセージの再配布が有効になっていることを確認してください。詳細は、Enabling message redistribution を参照してください。

関連情報

クラスターで実行されているサービスを使用して OpenShift クラスター外からの通信を行うために Routes および NodePort などの方法についての詳細は、以下を参照してください。
- OpenShift Container Platform ドキュメントの Ingress クラスタートラフィックの設定の概要。

トップに戻る

4.8. クライアント接続用の Operator ベースのブローカーデプロイメントの設定

4.8.1. アクセプターの設定
リンクのコピー

4.8.2. ブローカークライアント接続のセキュリティー保護
リンクのコピー

4.8.2.1. ホスト名検証用のブローカー証明書の設定
リンクのコピー

4.8.2.2. 一方向 TLS の設定
リンクのコピー

4.8.2.3. 双方向 TLS の設定
リンクのコピー

4.8.3. ブローカーデプロイメントのネットワークサービス
リンクのコピー

4.8.4. 内部および外部クライアントからのブローカーへの接続
リンクのコピー

4.8.4.1. 内部クライアントからのブローカーへの接続
リンクのコピー

4.8.4.2. 外部クライアントからのブローカーへの接続
リンクのコピー

4.8.4.3. NodePort を使用したブローカーへの接続
リンクのコピー

4.8.4.4. 永続的なサブスクリプションキューまたはリクエスト/要求キューがある場合のクライアント接続の負荷分散に関する警告
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.8. クライアント接続用の Operator ベースのブローカーデプロイメントの設定

4.8.1. アクセプターの設定リンクのコピーリンクがクリップボードにコピーされました!

4.8.2. ブローカークライアント接続のセキュリティー保護リンクのコピーリンクがクリップボードにコピーされました!

4.8.2.1. ホスト名検証用のブローカー証明書の設定リンクのコピーリンクがクリップボードにコピーされました!

4.8.2.2. 一方向 TLS の設定リンクのコピーリンクがクリップボードにコピーされました!

4.8.2.3. 双方向 TLS の設定リンクのコピーリンクがクリップボードにコピーされました!

4.8.3. ブローカーデプロイメントのネットワークサービスリンクのコピーリンクがクリップボードにコピーされました!

4.8.4. 内部および外部クライアントからのブローカーへの接続リンクのコピーリンクがクリップボードにコピーされました!

4.8.4.1. 内部クライアントからのブローカーへの接続リンクのコピーリンクがクリップボードにコピーされました!

4.8.4.2. 外部クライアントからのブローカーへの接続リンクのコピーリンクがクリップボードにコピーされました!

4.8.4.3. NodePort を使用したブローカーへの接続リンクのコピーリンクがクリップボードにコピーされました!

4.8.4.4. 永続的なサブスクリプションキューまたはリクエスト/要求キューがある場合のクライアント接続の負荷分散に関する警告リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.8.1. アクセプターの設定
リンクのコピー

4.8.2. ブローカークライアント接続のセキュリティー保護
リンクのコピー

4.8.2.1. ホスト名検証用のブローカー証明書の設定
リンクのコピー

4.8.2.2. 一方向 TLS の設定
リンクのコピー

4.8.2.3. 双方向 TLS の設定
リンクのコピー

4.8.3. ブローカーデプロイメントのネットワークサービス
リンクのコピー

4.8.4. 内部および外部クライアントからのブローカーへの接続
リンクのコピー

4.8.4.1. 内部クライアントからのブローカーへの接続
リンクのコピー

4.8.4.2. 外部クライアントからのブローカーへの接続
リンクのコピー

4.8.4.3. NodePort を使用したブローカーへの接続
リンクのコピー

4.8.4.4. 永続的なサブスクリプションキューまたはリクエスト/要求キューがある場合のクライアント接続の負荷分散に関する警告
リンクのコピー