OpenShift での AMQ Broker のデプロイ

手順

1. Web ブラウザーで、AMQ Broker 7.12.1 リリース の Software Downloads ページに移動します。
2. Version ドロップダウンリストの値が 7.12.1 に設定され、Releases タブが選択されていることを確認します。

3. 最新の AMQ Broker 7.12.1 Operator Installation and Example Files の横にある Download をクリックします。

   amq-broker-operator-7.12.1-ocp-install-examples.zip 圧縮アーカイブのダウンロードが自動的に開始されます。

4. アーカイブを選択したディレクトリーに移動します。以下の例では、アーカイブを ~/broker/operator という名前のディレクトリーに移動します。

   $ mkdir ~/broker/operator
   $ mv amq-broker-operator-7.12.3-ocp-install-examples-rhel8.zip ~/broker/operator

5. 選択したディレクトリーで、アーカイブの内容を抽出します。以下に例を示します。

   $ cd ~/broker/operator
   $ unzip amq-broker-operator-7.12.3-ocp-install-examples-rhel8.zip

6. アーカイブのデプロイメント時に作成されたディレクトリーに移動します。以下に例を示します。

   $ cd amq-broker-operator-7.12.3-ocp-install-examples

7. クラスター管理者として OpenShift Container Platform にログインします。以下に例を示します。

   $ oc login -u system:admin

8. Operator をインストールするプロジェクトを指定します。新規プロジェクトを作成するか、既存プロジェクトに切り替えることができます。

   1. 新しいプロジェクトを作成します。

      $ oc new-project <project_name>

   2. または、既存のプロジェクトに切り替えます。

      $ oc project <project_name>

9. Operator で使用するサービスアカウントを指定します。

   1. デプロイメントした Operator アーカイブの deploy ディレクトリーで、service_account.yaml ファイルを開きます。
   2. kind 要素が ServiceAccount に設定されていることを確認します。
   3. デフォルトのサービスアカウント名を変更する場合は、metadata セクションで amq-broker-controller-manager をカスタム名に置き換えます。

   4. プロジェクトにサービスアカウントを作成します。

      $ oc create -f deploy/service_account.yaml

10. Operator のロール名を指定します。

    1. role.yaml ファイルを開きます。このファイルは、Operator が使用できるリソースを指定し、変更します。
    2. kind 要素が Role に設定されていることを確認します。
    3. デフォルトのロール名を変更する場合は、metadata セクションで amq-broker-operator-role をカスタム名に置き換えます。

    4. プロジェクトにロールを作成します。

       $ oc create -f deploy/role.yaml

11. Operator のロールバインディングを指定します。ロールバインディングは、指定した名前に基づいて、事前に作成されたサービスアカウントを Operator ロールにバインドします。

    1. role_binding.yaml ファイルを開きます。

    2. ServiceAccount と Role の name の値が service_account.yaml および role.yaml ファイルで指定された値と一致していることを確認します。以下に例を示します。

       metadata:
           name: amq-broker-operator-rolebinding
       subjects:
           kind: ServiceAccount
           name: amq-broker-controller-manager
       roleRef:
           kind: Role
           name: amq-broker-operator-role

    3. プロジェクトでロールバインディングを作成します。

       $ oc create -f deploy/role_binding.yaml

12. Operator のリーダー選出ロールバインディングを指定します。ロールバインディングは、指定した名前に基づいて、事前に作成されたサービスアカウントをリーダー選出ロールにバインドします。

    1. Operator のリーダー選出ロールを作成します。

       $ oc create -f deploy/election_role.yaml

    2. プロジェクトでリーダー選出ロールバインディングを作成します。

       $ oc create -f deploy/election_role_binding.yaml

13. (オプション) Operator が複数の名前空間を監視するようにする場合は、以下の手順を実行します。

    注記

    OpenShift Container Platform クラスターに、インストール済みの Operators for AMQ Broker がすでに含まれている場合は、新しい Operator が既存の Operator と同じ名前空間を監視しないようにする必要があります。既存の Operator によって監視されている名前空間を識別する方法については、Identifying namespaces watched by existing Operators を参照してください。

    1. ダウンロードした Operator アーカイブの deploy ディレクトリーで、operator_yaml ファイルを開きます。

    2. Operator がクラスター内のすべての名前空間を監視するようにする場合は、WATCH_NAMESPACE セクションで value 属性を追加し、値をアスタリスクに設定します。WATCH_NAMESPACE セクションの既存の属性をコメントアウトします。以下に例を示します。

       - name: WATCH_NAMESPACE
         value: "*"
       # valueFrom:
       #   fieldRef:
       #     fieldPath: metadata.namespace

       注記

       競合を避けるために、複数の Operator が同じ名前空間を監視しないようにしてください。たとえば、Operator をデプロイしてクラスター上の すべての 名前空間を監視する場合は、別の Operator をデプロイして個々の名前空間を監視することはできません。Operator がすでにクラスターにデプロイされている場合、次のステップで説明するように、新しい Operator が監視する名前空間のリストを指定できます。

    3. Operator がクラスター上のすべての名前空間ではなく、複数の名前空間を監視するようにする場合は、WATCH_NAMESPACE セクションで、名前空間のリストを指定します。既存の Operator によって監視されている名前空間を除外していることを確認してください。以下に例を示します。

       - name: WATCH_NAMESPACE
         value: "namespace1, namespace2"`.

    4. ダウンロードして展開した Operator アーカイブの deploy ディレクトリーで、cluster_role_binding.yaml ファイルを開きます。

    5. Subjects セクションで、Operator を デプロイする OpenShift Container Platform プロジェクトに対応する名前空間を指定します。以下に例を示します。

       Subjects:
       - kind: ServiceAccount
         name: amq-broker-controller-manager
         namespace: operator-project

       注記

       古いバージョンの Operator を使用してブローカーを以前にデプロイし、Operator をデプロイして複数の名前空間を監視する場合は、アップグレードする前に を参照してください。

    6. プロジェクトにクラスターロールを作成します。

       $ oc create -f deploy/cluster_role.yaml

    7. プロジェクトにクラスターロールバインディングを作成します。

       $ oc create -f deploy/cluster_role_binding.yaml

手順

1. OpenShift コマンドラインインターフェイス (CLI) で、クラスター管理者として OpenShift にログインします。以下に例を示します。

   $ oc login -u system:admin

2. Operator デプロイメント用に以前に準備したプロジェクトに切り替えます。以下に例を示します。

   $ oc project <project_name>

3. 以前の手順で Operator インストールアーカイブをデプロイメントする際に作成されたディレクトリーに移動します。以下に例を示します。

   $ cd ~/broker/operator/amq-broker-operator-7.12.3-ocp-install-examples

4. Operator に含まれる CRD をデプロイします。Operator をデプロイし、起動する前に CRD を OpenShift クラスターにインストールする必要があります。

   1. メインブローカー CRD をデプロイします。

      $ oc create -f deploy/crds/broker_activemqartemis_crd.yaml

   2. アドレス CRD をデプロイします。

      $ oc create -f deploy/crds/broker_activemqartemisaddress_crd.yaml

   3. スケールダウンコントローラー CRD をデプロイします。

      $ oc create -f deploy/crds/broker_activemqartemisscaledown_crd.yaml

   4. セキュリティー CRD をデプロイします。

      $ oc create -f deploy/crds/broker_activemqartemissecurity_crd.yaml

5. Red Hat Ecosystem Catalog での認証に使用されるアカウントに関連付けられたプルシークレットを、OpenShift プロジェクトの default、deployer、および builder サービスアカウントにリンクします。

   $ oc secrets link --for=pull default <secret_name>
   $ oc secrets link --for=pull deployer <secret_name>
   $ oc secrets link --for=pull builder <secret_name>

6. ダウンロードした Operator アーカイブの deploy ディレクトリーで、operator.yaml ファイルを開きます。以下に示すように、spec.containers.image プロパティーの値が Operator のバージョン 7.12.1-opr-1 に対応していることを確認します。

   spec:
       template:
           spec:
               containers:
                   #image: registry.redhat.io/amq7/amq-broker-rhel8-operator:7.10
                   image: registry.redhat.io/amq7/amq-broker-rhel8-operator@sha256:1fd01079ad519e1a47b886893a0635491759ace2f73eda7615a9c8c2f454ba89

   注記

   operator.yaml ファイルでは、Operator は Secure Hash Algorithm (SHA) 値で表されるイメージを使用します。数字記号 (#) 記号で始まるコメント行は、SHA 値が特定のコンテナーイメージタグに対応していることを示します。

7. Operator をデプロイします。

   $ oc create -f deploy/operator.yaml

   OpenShift プロジェクトで、Operator は新規 Pod で起動します。

   OpenShift Container Platform Web コンソールで、Operator Pod の Events タブにある情報により、OpenShift が指定した Operator イメージがデプロイされ、新規コンテナーが OpenShift クラスターのノードに割り当てられ、新規コンテナーが起動されていることを確認します。

   さらに、Pod 内の Logs タブをクリックしても、出力には、以下のような行が含まれるはずです。

   ...
   {"level":"info","ts":1553619035.8302743,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemisaddress-controller"}
   {"level":"info","ts":1553619035.830541,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemis-controller"}
   {"level":"info","ts":1553619035.9306898,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemisaddress-controller","worker count":1}
   {"level":"info","ts":1553619035.9311671,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemis-controller","worker count":1}

   上記の出力では、新たにデプロイされた Operator が Kubernetes と通信していること、ブローカーおよびアドレス指定のコントローラーが実行されていることと、これらのコントローラーが一部のワーカーを起動していることを確認します。

手順

1. クラスター管理者として OpenShift Container Platform Web コンソールにログインします。
2. 左側のナビゲーションメニューで、Operators → OperatorHub をクリックします。
3. OperatorHub ページ上部の Project ドロップダウンメニューで、Operator をデプロイするプロジェクトを選択します。

4. OperatorHub ページで、Filter by keyword…​ ボックスを使用して Red Hat Integration - AMQ Broker Operator for RHEL 8 (Multiarch) を見つけます。

   注記

   OperatorHub では、名前に AMQ Broker が含まれているよりも多くの Operator を見つける可能性があります。Red Hat Integration-AMQ Broker for RHEL 8(Multiarch) Operator をクリックしてください。この Operator をクリックしたら、開いている情報ペインを確認します。AMQ Broker 7.12 の場合、この Operator の最新マイナーバージョンタグは 7.12.1-opr-1 です。

5. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator をクリックします。表示されるダイアログボックスで、Install をクリックします。

6. Install Operator ページで以下を行います。

   1. Update Channel で、バージョン 7.11 のみの更新を受信する 7.11.x チャネルを選択します。7.11.x チャネルは長期サポート (LTS) チャネルです。

      OpenShift Container Platform クラスターがインストールされた時期によっては、古いバージョンの AMQ Broker のチャネルが表示される場合もあります。他にサポートされているチャネルは 7.10.x のみで、これも LTS チャネルです。

   2. インストールモードで、Operator が監視する名前空間を選択します。

      • クラスター上の特定の名前空間: Operator は対象の名前空間にインストールされ、CR に変更がないか、対象の名前空間のみを監視します。
      • すべての名前空間 - Operator は、CR の変更がないか、すべての名前空間を監視します。
      注記

      以前のバージョンの Operator を使用してブローカーをデプロイし、Operator をデプロイして多くの名前空間を監視する場合は、アップグレードする前に を参照してください。

7. Installed Namespace ドロップダウンメニューから、Operator をインストールするプロジェクトを選択します。

8. Approval Strategy で、Automatic のラジオボタンが選択されていることを確認します。このオプションは、インストールを実行するために Operator への更新を手動で承認する必要がないように指定します。

   注記

   承認ストラテジーは、Operator のマイクロバージョン間の更新にのみ適用されます。マイナー Operator バージョン間の自動更新はサポートされていません。たとえば、現在の Operator がバージョン 7.11.7 の場合、バージョン 7.12.x への自動更新はできません。Operator のマイナーバージョン間で更新するには、現在の Operator を手動でアンインストールし、そのマイナーバージョンの Operator が利用可能になるチャネルから新規 Operator をインストールする必要があります。詳細は、「OperatorHub を使用した Operator の手動によるアップグレード」 を参照してください。

9. Install をクリックします。

1. ブローカーデプロイメントのカスタムリソース (CR) インスタンスの設定を開始します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. デプロイメントを作成するプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

         oc login -u <user> -p <password> --server=<host:port>

      2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemis_cr.yaml というサンプル CR ファイルを開きます。

   2. OpenShift Container Platform Web コンソールの使用

      1. デプロイメントを作成するプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. メインブローカー CRD に基づいて新規 CR インスタンスを起動します。左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。

      5. Create ActiveMQArtemis をクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

   基本的なブローカーデプロイメントの場合、設定が以下のように表示される可能性があります。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true

   broker_activemqartemis_cr.yaml サンプル CR ファイルで、image プロパティーが placeholder のデフォルト値に設定されていることを確認します。この値はデフォルトで、image プロパティーによってデプロイメントに使用するブローカーコンテナーイメージが指定されていないことを示します。Operator が使用する適切なブローカーコンテナーイメージを判別する方法については、「Operator によるコンテナーイメージの選択方法」 を参照してください。

   注記

   broker_activemqartemis_cr.yaml サンプル CR は、ex-aao の命名規則を使用します。この命名規則は、CR が AMQ Broker Operator のリソースの例になります。AMQ Broker は ActiveMQ Artemis プロジェクトをベースにしています。このサンプル CR をデプロイする場合、生成される StatefulSet は ex-aao-ss の名前を使用します。さらに、デプロイメントのブローカー Pod は StatefulSet 名に基づいて直接使用されます (例: ex-aao-ss-0、ex-aao-ss-1 など)。CR のアプリケーション名が StatefulSet のラベルとしてデプロイメントに表示されます。このラベルは Pod セレクターで使用できます。

2. size プロパティーはデプロイするブローカーの数を指定します。2 以上の値は、クラスターブローカーデプロイメントを指定します。ただし、単一のブローカーインスタンスをデプロイするには、値が 1 に設定されていることを確認します。

3. CR インスタンスをデプロイします。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. CR ファイルを保存します。

      2. ブローカーデプロイメントを作成するプロジェクトに切り替えます。

         $ oc project <project_name>

      3. CR インスタンスを作成します。

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. OpenShift Web コンソールの使用

      1. CR の設定が完了したら、Create をクリックします。

4. Open Shift Container Platform Web コンソールで、Workloads → StatefulSets をクリックします。ex-aao-ss という新しい StatefulSet が表示されます。

   1. ex-aao-ss StatefulSet をクリックします。CR で定義される単一ブローカーに対応する Pod が 1 つあることが分かります。
   2. StatefulSet 内で Pods タブをクリックします。ex-aao-ss Pod をクリックします。実行中の Pod の Events タブで、ブローカーコンテナーが起動したことを確認できます。Logs タブには、ブローカー自体が実行中であることを示します。

5. ブローカーは通常実行されていることをテストするには、ブローカー Pod のシェルにアクセスしてテストメッセージを送信します。

   1. OpenShift Container Platform Web コンソールの使用

      1. Workloads → Pods をクリックします。
      2. ex-aao-ss Pod をクリックします。
      3. Terminal タブをクリックします。

   2. OpenShift コマンドラインインターフェイスの使用:

      1. プロジェクトの Pod 名および内部 IP アドレスを取得します。

         $ oc get pods -o wide
         
         NAME                          STATUS   IP
         amq-broker-operator-54d996c   Running  10.129.2.14
         ex-aao-ss-0                   Running  10.129.2.15

      2. ブローカー Pod のシェルにアクセスします。

         $ oc rsh ex-aao-ss-0

6. シェルから artemis コマンドを使用して、一部のテストメッセージを送信します。URL にブローカー Pod の内部 IP アドレスを指定します。以下に例を示します。

   sh-4.2$ ./amq-broker/bin/artemis producer --url tcp://10.129.2.15:61616 --destination queue://demoQueue

   上記のコマンドは、ブローカーに demoQueue というキューを自動的に作成し、デフォルトの数量 1000 のメッセージをキューに送信します。

   以下のような出力が表示されるはずです。

   Connection brokerURL = tcp://10.129.2.15:61616
   Producer ActiveMQQueue[demoQueue], thread=0 Started to calculate elapsed time ...
   
   Producer ActiveMQQueue[demoQueue], thread=0 Produced: 1000 messages
   Producer ActiveMQQueue[demoQueue], thread=0 Elapsed time in second : 3 s
   Producer ActiveMQQueue[demoQueue], thread=0 Elapsed time in milli second : 3492 milli seconds

手順

1. 基本的なブローカーデプロイメントに使用した CR ファイルを開きます。

2. クラスター化したデプロイメントの場合は、deploymentPlan.size の値が 2 以上であることを確認します。以下に例を示します。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 4
       image: placeholder
       ...

   注記

   metadata セクションで、namespace プロパティーを追加し、OpenShift Container Platform Web コンソールを使用して CR インスタンスを作成する場合にのみ値を指定する必要があります。指定する値は、ブローカーデプロイメントの OpenShift プロジェクトの名前です。

3. 変更された CR ファイルを保存します。

4. 基本的なブローカーデプロイメントを作成したプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

   $ oc login -u <user> -p <password> --server=<host:port>

5. 基本的なブローカーデプロイメントを先に作成したプロジェクトに切り替えます。

   $ oc project <project_name>

6. コマンドラインで変更を適用します。

   $ oc apply -f <path/to/custom_resource_instance>.yaml

   OpenShift Container Platform Web コンソールで、追加のブローカー Pod は CR で指定される数に基づいてプロジェクトで起動します。デフォルトで、プロジェクトで実行されているブローカーはクラスター化されます。

7. 各 Pod の Logs タブを開きます。ログには、OpenShift が各ブローカーでクラスター接続ブリッジが確立されていることが示されています。具体的には、ログ出力には以下のような行が含まれます。

   targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@6f13fb88

1. Operator は、ブローカーのアプリケーションコンテナーの前に Init コンテナーを実行します。Init コンテナーはデフォルトのアドレス設定を生成します。デフォルトのアドレス設定を以下に示します。

   <address-settings>
       <!--
       if you define auto-create on certain queues, management has to be auto-create
       -->
       <address-setting match="activemq.management#">
           <dead-letter-address>DLQ</dead-letter-address>
           <expiry-address>ExpiryQueue</expiry-address>
           <redelivery-delay>0</redelivery-delay>
           <!--
           with -1 only the global-max-size is in use for limiting
           -->
           <max-size-bytes>-1</max-size-bytes>
           <message-counter-history-day-limit>10</message-counter-history-day-limit>
           <address-full-policy>PAGE</address-full-policy>
           <auto-create-queues>true</auto-create-queues>
           <auto-create-addresses>true</auto-create-addresses>
           <auto-create-jms-queues>true</auto-create-jms-queues>
           <auto-create-jms-topics>true</auto-create-jms-topics>
       </address-setting>
   
       <!-- default for catch all -->
       <address-setting match="#">
           <dead-letter-address>DLQ</dead-letter-address>
           <expiry-address>ExpiryQueue</expiry-address>
           <redelivery-delay>0</redelivery-delay>
           <!--
           with -1 only the global-max-size is in use for limiting
           -->
           <max-size-bytes>-1</max-size-bytes>
           <message-counter-history-day-limit>10</message-counter-history-day-limit>
           <address-full-policy>PAGE</address-full-policy>
           <auto-create-queues>true</auto-create-queues>
           <auto-create-addresses>true</auto-create-addresses>
           <auto-create-jms-queues>true</auto-create-jms-queues>
           <auto-create-jms-topics>true</auto-create-jms-topics>
       </address-setting>
   <address-settings>

2. カスタムリソース (CR) インスタンスでアドレス設定も指定している場合、init コンテナーはその設定を処理して XML に変換します。
3. CR の applyRule プロパティーの値に基づいて、init コンテナーは、上記のデフォルトのアドレス設定を CR で指定した設定と マージ するか、置き換え ます。このマージまたは置換の結果は、ブローカーが使用する最終アドレス設定になります。
4. Init コンテナーがブローカー設定の生成が終了すると (アドレス設定を含む)、ブローカーのアプリケーションコンテナーが起動します。起動時に、ブローカーコンテナーは以前に init コンテナーによって使用されたインストールディレクトリーから設定をコピーします。broker.xml 設定ファイルでアドレス設定を確認できます。実行中のブローカーの場合、このファイルは /home/jboss/amq-broker/etc ディレクトリーにあります。

手順

1. ブローカーデプロイメントの ActiveMQArtemis CR インスタンスを編集します。

2. CR の spec セクションに、brokerProperties 属性が CR にない場合、それを追加します。

   spec:
     ...
     brokerProperties:
     ...

3. 次の形式でアドレスを設定します。

   - addressConfigurations.<address name>.routingTypes=<routing type>

   以下に例を示します。

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news-address.routingTypes=MULTICAST
     ...

4. 作成したアドレスのキューを形式で設定します。

   -addressConfigurations.<address name>.queueConfigs.<queue name>.address< address >

   重要

   .address 設定の <address> の値は、作成する各キューの <アドレス名> と一致する必要があります。これらの値が異なる場合は、それぞれに個別のアドレスが作成されます。以下の例では、アドレス名と .address 設定の両方に、usa-news-address の値が同じになります。

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.address=usa-news-address
     ...

5. キューに設定する各設定に別々の行を追加します。

   • addressConfigurations.<address name>.queueConfigs.<queue name>.<queue setting>

   以下に例を示します。

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.routingType=ANYCAST
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.purgeOnNoConsumers=true
     - addressConfigurations.usa-news-address.queueConfigs.usa-news-queue.maxConsumers=20
     ...

6. CR を保存します。
7. ActiveMQArtemis CR の status セクションを確認して、brokerProperties 設定でエラーが検出されていないことを確認します。詳細は、「カスタムリソース定義(CRD)で公開されていない項目の設定」 を参照してください。

手順

1. カスタムリソース (CR) インスタンスの設定を開始し、ブローカーデプロイメントのアドレスおよびキューを定義します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

         oc login -u <user> -p <password> --server=<host:port>

      2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemisaddress_cr.yaml というサンプル CR ファイルを開きます。

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. アドレス CRD に基づいて新規 CR インスタンスを起動します。左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemisAddresss CRD をクリックします。
      4. Instances タブをクリックします。

      5. Create ActiveMQArtemisAddress をクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

2. CR の spec セクションで、行を追加してアドレス、キュー、およびルーティングタイプを定義します。以下に例を示します。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemisAddress
   metadata:
       name: myAddressDeployment0
       namespace: myProject
   spec:
       ...
       addressName: myAddress0
       queueName: myQueue0
       routingType: anycast
       ...

   上記の設定では、myQueue0 という名前のキューと anycast ルーティングタイプを持つ myAddress0 という名前のアドレスが定義されます。

   注記

   metadata セクションで、namespace プロパティーを追加し、OpenShift Container Platform Web コンソールを使用して CR インスタンスを作成する場合にのみ値を指定する必要があります。指定する値は、ブローカーデプロイメントの OpenShift プロジェクトの名前です。

3. CR インスタンスをデプロイします。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. CR ファイルを保存します。

      2. ブローカーデプロイメントのプロジェクトに切り替えます。

         $ oc project <project_name>

      3. CR インスタンスを作成します。

         $ oc create -f <path/to/address_custom_resource_instance>.yaml

   2. OpenShift Web コンソールの使用

      1. CR の設定が完了したら、Create をクリックします。

1. ブローカーデプロイメントの ActiveMQArtemis CR インスタンスを編集します。

2. dead letter アドレスおよびキューを作成して、未配信のメッセージを受信します。以下に例を示します。

   spec:
     ...
     brokerProperties:
     ...
     - addressConfigurations.usDeadLetter.routingTypes=MULTICAST
     - addressConfigurations.usDeadLetter.queueConfigs.usDeadLetter-queue.address=usDeadLetter

   brokerProperties を使用してアドレスおよびキューを作成する方法の詳細については、「アドレスおよびキューの設定」 を参照してください。

3. addressSettings.<アドレス名 >.<アドレス設定> 形式の brokerProperties 属性の下に、個別の行を追加します。

   • 配信不能メッセージの dead letter アドレスを、作成した dead letter アドレスに設定します。

   • 一致するアドレスに配信できないメッセージをデッドレターアドレスに送信するまでの配信試行回数を指定します。

     以下に例を示します。

     spec:
       ...
       brokerProperties:
       ...
       - addressSettings.usa-news.deadLetterAddress=usDeadLetter
       - addressSettings.usa-news.maxDeliveryAttempts=5
       ...

     ワイルドカードとしてアスタリスク(*)または数字記号(#)文字を使用して、アドレスパターンを作成できます。パターンの一致は、ピリオド(.)で表される各区切り文字境界で実行されます。数字記号は、ゼロ以上の単語のシーケンスと一致し、アドレス文字列の最後に使用できます。アスタリスク文字は 1 つの単語と一致し、アドレス文字列内の任意の場所で使用できます。以下に例を示します。

     spec:
       ...
       brokerProperties:
       ...
       - addressSettings."usa-news.*".deadLetterAddress=usDeadLetter
       - addressSettings."europe-news.#".deadLetterAddress=euDeadLetter
       ...

     上記の例では、次のアドレスが一致します。

   • usa-news.* アドレスパターンは、usa-news.domestic および usa-news. intl など、usa-news.domestic.politics の単語と一致しますが、usa-news.domestic.politics ではありません。

   • europe-news.# アドレスパターンは、europe-news、europe-news.politics、 europe-news.politics.fr など、europe-news、europe-news.politics.fr で始まるアドレスと一致します。

     注記

     brokerProperties エントリーでは、ピリオド(.)は予約文字です。ピリオドを含むアドレスパターンを作成する場合は、アドレスを引用符で囲む必要があります。たとえば、usa-news.*" です。

4. CR を保存します。
5. ActiveMQArtemis CR の status セクションを確認して、brokerProperties 設定でエラーが検出されていないことを確認します。詳細は、「カスタムリソース定義(CRD)で公開されていない項目の設定」 を参照してください。

手順

1. ブローカーデプロイメントの ActiveMQArtemis CR インスタンスを編集します。

    oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   1. OpenShift Container Platform Web コンソールの使用
2. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
3. 左側のペインで、Operators → Installed Operator をクリックします。
4. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator をクリックします。
5. AMQ Broker タブをクリックします。
6. ActiveMQArtemis インスタンス名をクリックします。

7. YAML タブをクリックします。

   コンソールで、YAML エディターが開き、CR インスタンスを編集できるようになります。

   注記

   metadata セクションで、namespace プロパティーを追加し、OpenShift Container Platform Web コンソールを使用して CR インスタンスを作成する場合にのみ値を指定する必要があります。指定する値は、ブローカーデプロイメントの OpenShift プロジェクトの名前です。

   1. CR の spec セクションに、次に示すように、単一の addressSetting セクションを含む新しい addressSettings セクションを追加します。

      spec:
        ...
        addressSettings:
          addressSetting:

   2. addressSetting ブロックに match プロパティーのインスタンスを 1 つ追加します。アドレス一致式を指定します。以下に例を示します。

      spec:
        ...
        addressSettings:
          addressSetting:
          - match: myAddress

      match

      ブローカーが以下の設定を適用するアドレスまたはアドレスのセットを指定します。この例では、match プロパティーの値は myAddress と呼ばれる単一のアドレスに対応します。

   3. 未配信メッセージに関連するプロパティーを追加し、値を指定します。以下に例を示します。

      spec:
        ...
        addressSettings:
          addressSetting:
          - match: myAddress
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 5

      deadLetterAddress

      ブローカーが未達のメッセージを送信するアドレス。

      maxDeliveryAttempts

      メッセージを設定済みのデッドレターアドレスに移動する前にブローカーが行う最大配信試行数。

      上記の例では、ブローカーによって、myAddress で始まるアドレスにメッセージの配信が 5 回失敗する場合、ブローカーはメッセージを指定の dead letter address (myDeadLetterAddress) に移動します。

   4. (オプション) 別のアドレスまたはアドレスセットに同様の設定を適用します。以下に例を示します。

      spec:
        ...
        addressSettings:
          addressSetting:
          - match: myAddress
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 5
          - match: 'myOtherAddresses#'
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 3

      この例では、2 つ目の match プロパティーの値にはハッシュワイルドカード文字が含まれます。ワイルドカード文字では、上記の設定が文字列 myOtherAddresses で始まる任意のアドレスに適用されることを意味します。

      注記

      ワイルドカード式を match プロパティーの値として使用する場合には、値を単一引用符で囲む必要があります (例: 'myOtherAddresses#')。

   5. addressSettings セクションの最初に applyRule プロパティーを追加し、値を指定します。以下に例を示します。

      spec:
        ...
          applyRule: merge_all
          addressSetting:
          - match: myAddress
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 5
          - match: 'myOtherAddresses#'
            deadLetterAddress: myDeadLetterAddress
            maxDeliveryAttempts: 3

      applyRule プロパティーは、Operator を一致するアドレスまたはアドレスのセットごとに CR に追加する設定を適用する方法を指定します。指定できる値は次のとおりです。

      merge_all

      • CR で指定されるアドレス設定と、同じアドレスまたはアドレスのセットに一致するデフォルト設定の両方の場合:

        • デフォルト設定で指定されるプロパティー値を CR で指定されたプロパティー値に置き換えます。
        • CR またはデフォルト設定で一意で指定されるプロパティー値を保持します。これらはそれぞれ最終マージされた設定の組み込みます。
      • CR で指定されるアドレス設定または特定のアドレスセットに一意になるデフォルト設定の場合は、これらを最終でマージされた設定に含めます。

      merge_replace

      • CR に指定されたアドレス設定と、同じアドレスまたはアドレスセットに一致するデフォルト設定について、最終的なマージされた設定の CR に指定された設定を含めます。それらのプロパティーが CR で指定されていない場合でも、デフォルト設定に指定されたプロパティーを含めないでください。
      • CR で指定されるアドレス設定または特定のアドレスセットに一意になるデフォルト設定の場合は、これらを最終でマージされた設定に含めます。

      replace_all

      デフォルト設定に指定されたすべてのアドレス設定を CR で指定されたアドレス設定に置き換えます。最後にマージされた設定は、CR で指定したものと完全に対応します。

      注記

      CR に applyRule プロパティーを明示的に含ない場合、Operator は merge_all のデフォルト値を使用します。

   6. CR インスタンスを保存します。

手順

1. ブローカーデプロイメントの ActiveMQArtemis CR インスタンスを編集します。

2. 以下の brokerProperties エントリーを追加して、ブローカーが、番号記号(#)で表現された任意のアドレスと、CR で検出しなくなった関連キューを削除できるようにします。

   spec:
     ...
     brokerProperties:
     - addressSettings.#.configDeleteAddresses=FORCE
     - addressSettings.#.configDeleteQueues=FORCE
     ...

3. brokerProperties 属性で、削除するアドレスおよびキューを参照するすべての行を削除します。たとえば、このアドレスとキューを削除するために usa-news アドレスを参照するすべての行を削除します。

   spec:
     ...
     brokerProperties:
     - addressConfigurations.usa-news.queueConfigs.usa-news-queue.routingType=MULTICAST
     - addressConfigurations.usa-news.queueConfigs.usa-news-queue.purgeOnNoConsumers=true
     - addressConfigurations.usa-news.queueConfigs.usa-news-queue.maxConsumers=20
     ...

4. CR を保存します。

   ブローカーが更新された設定を適用すると、CR から削除されたアドレスとキューを削除します。

手順

1. 削除するアドレスとキューの詳細 (name、addressName、queueName など) が記載されたアドレス CR ファイルがあることを確認してください。以下に例を示します。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemisAddress
   metadata:
       name: myAddressDeployment0
       namespace: myProject
   spec:
       ...
       addressName: myAddress0
       queueName: myQueue0
       routingType: anycast
       ...

2. アドレス CR の spec セクションに、removeFromBrokerOnDelete 属性を追加し、値を true に設定します。

   ..
   spec:
      addressName: myAddress1
      queueName: myQueue1
      routingType: anycast
      removeFromBrokerOnDelete: true

   removeFromBrokerOnDelete 属性を true に設定すると、アドレス CR を削除するときに、Operator はデプロイメント内のすべてのブローカーのアドレスと関連するメッセージを削除します。

3. 更新されたアドレス CR を適用して、削除するアドレスの removeFromBrokerOnDelete 属性を設定します。

   $ oc apply -f <path/to/address_custom_resource_instance>.yaml

4. アドレス CR を削除して、デプロイメント内のブローカーからアドレスを削除します。

   $ oc delete -f <path/to/address_custom_resource_instance>.yaml

手順

1. 新しい JAAS ログインモジュール設定を含むテキストファイルを作成し、そのファイルを login.config として保存します。ファイルを login.config として保存すると、テキストファイルから作成したシークレットに正しいキーが挿入されます。次に、ログインモジュールの設定例を示します。

   activemq {
      org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient
         reload=true
         org.apache.activemq.jaas.properties.user="new-users.properties"
         org.apache.activemq.jaas.properties.role="new-roles.properties";
   
      org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient
         reload=false
         org.apache.activemq.jaas.properties.user="artemis-users.properties"
         org.apache.activemq.jaas.properties.role="artemis-roles.properties"
         baseDir="/home/jboss/amq-broker/etc";
   };

   シークレットで JAAS ログインモジュールを設定し、CR でシークレットへの参照を追加すると、デフォルトのログインモジュールは AMQ Broker で使用されなくなります。ただし、デフォルトのログインモジュールで参照される artemis-users.properties ファイル内のユーザーは、Operator がブローカーで認証する必要があります。新しい JAAS ログインモジュールを設定した後、Operator がブローカーで認証できることを確認するには、次のいずれかを行う必要があります。

   • 上の例に示すように、新しいログインモジュール設定にデフォルトのプロパティーログインモジュールを含めます。この例では、デフォルトのプロパティーログインモジュールは artemis-users.properties ファイルと artemis-roles.properties ファイルを使用します。新しいログインモジュール設定にデフォルトのログインモジュールを含める場合は、baseDir を /home/jboss/amq-broker/etc ディレクトリーに設定する必要があります。このディレクトリーには、各ブローカー Pod のデフォルトのプロパティーファイルが含まれています。

   • オペレーターがブローカーで認証するために必要なユーザーとロールの情報を、新しいログインモジュール設定で参照されるプロパティーファイルに追加します。この情報は、ブローカー Pod の /home/jboss/amq-broker/etc directory にあるデフォルトの artemis-users.properties ファイルおよび artemis-roles.properties ファイルからコピーできます。

     注記

     ログインモジュールで参照されるプロパティーファイルは、ブローカーが初めてログインモジュールを呼び出したときにのみロードされます。ブローカーは、ユーザーを認証するためのログインモジュールが見つかるまで、login.config ファイルにリストされている順序でログインモジュールを呼び出します。Operator が使用する認証情報を含むログインモジュールを login.config ファイルの最後に配置すると、ブローカーが Operator を認証するときに、先行するすべてのログインモジュールが呼び出されます。その結果、プロパティーファイルがブローカー上で表示されないことを示すステータスメッセージはすべてクリアされます。

2. 作成した login.config ファイルにプロパティーログインモジュールが含まれている場合は、モジュール内で指定されたユーザーおよびロールファイルにユーザーおよびロールの情報が含まれていることを確認してください。以下に例を示します。

   new-users.properties

   ruben=ruben01!
   anne=anne01!
   rick=rick01!
   bob=bob01!

   new-roles.properties

   admin=ruben, rick
   group1=bob
   group2=anne

3. oc create secret コマンドを使用して、新しいログインモジュール設定で作成したテキストファイルからシークレットを作成します。ログインモジュール設定にプロパティーログインモジュールが含まれている場合は、関連するユーザーとロールファイルもシークレットに含めます。以下に例を示します。

   oc create secret generic custom-jaas-config --from-file=login.config --from-file=new-users.properties --from-file=new-roles.properties

   注記

   シークレットにログインモジュール設定が含まれていることを Operator が認識し、更新を各ブローカー Pod に伝播できるように、シークレット名には接尾辞 -jaas-config が必要です。

   シークレットを作成する方法の詳細は、Kubernetes ドキュメントの Secrets を参照してください。

4. 作成したシークレットをブローカーデプロイメントのカスタムリソース (CR) インスタンスに追加します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

      2. デプロイメントの CR を編集します。

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. 左側のペインで、Operators → Installed Operator をクリックします。
      3. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator をクリックします。
      4. AMQ Broker タブをクリックします。
      5. ActiveMQArtemis インスタンス名をクリックします。

      6. YAML タブをクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

5. extraMounts 要素と secrets 要素を作成し、シークレットの名前を追加します。次の例では、custom-jaas-config という名前のシークレットを CR に追加します。

   deploymentPlan:
     ...
     extraMounts:
       secrets:
       - "custom-jaas-config"
     ...

6. CR で、ブローカー上で設定されているロールに権限を付与します。

   1. CR の spec セクションで、brokerProperties 要素を追加し、権限を追加します。単一のアドレスにロール権限を付与できます。または、# 記号を使用してワイルドカード一致を指定し、すべてのアドレスにロールの権限を付与することもできます。以下に例を示します。

      spec:
        ...
        brokerProperties:
        - securityRoles.#.group2.send=true
        - securityRoles.#.group1.consume=true
        - securityRoles.#.group1.createAddress=true
        - securityRoles.#.group1.createNonDurableQueue=true
        - securityRoles.#.group1.browse=true
        ...

      この例では、group2 ロールにはすべてのアドレスへの send 権限が割り当てられ、group1 ロールにはすべてのアドレスへの consume、createAddress、createNonDurableQueue および browse 権限が割り当てられます。

      注記

      Java プロパティーファイルでは、コロン (:) は、キー/値ペア内のキーと値を区切るために使用される予約文字です。コロン (::) で区切られたアドレス名とキュー名で構成される完全修飾キュー名 (FQQN) に権限を付与する場合は、FQQN 内のコロンをエスケープするためにバックスラッシュ (\) を使用する必要があります。以下に例を示します。

      spec:
        ...
        brokerProperties:
        - 'securityRoles."my-address\:\:my-queue".group2.send=true'

7. CR を保存します。

   Operator は、/amq/extra/secrets/secret name ディレクトリー内のシークレットの login.config ファイルを各 Pod にマウントし、デフォルトの login.config ファイルの代わりに、マウントされた login.config ファイルを読み取るようにブローカー JVM を設定します。login.config ファイルにプロパティーログインモジュールが含まれている場合、参照されるユーザーとロールのプロパティーファイルも各 Pod にマウントされます。

8. CR のステータス情報を表示して、デプロイメント内のブローカーが認証にシークレット内の JAAS ログインモジュールを使用していることを確認します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーの CR でステータス条件を取得します。

         $ oc get activemqartemis -o yaml

   2. OpenShift Web コンソールの使用

      1. CR で、status セクションに移動します。

   3. ステータス情報に JaasPropertiesApplied タイプが存在することを確認します。これは、ブローカーがシークレットで設定された JAAS ログインモジュールを使用していることを示します。以下に例を示します。

      - lastTransitionTime: "2023-02-06T20:50:01Z"
        message: ""
        reason: Applied
        status: "True"
        type: JaasPropertiesApplied

      シークレット内のいずれかのファイルを更新すると、OpenShift Container Platform がシークレット内の最新のファイルを各ブローカー Pod に伝播するまで、reason フィールドの値に OutofSync が表示されます。たとえば、新しいユーザーを new-users-properties ファイルに追加してシークレットを更新すると、更新されたファイルが各 Pod に伝播されるまで、次のステータス情報が表示されます。

      - lastTransitionTime: "2023-02-06T20:55:20Z"
        message: 'new-users.properties status out of sync, expected: 287641156, current: 2177044732'
        reason: OutOfSync
        status: "False"
        type: JaasPropertiesApplied

9. シークレットで参照されるプロパティーファイル内のユーザーまたはロール情報を更新する場合は、oc set data コマンドを使用してシークレットを更新します。login.config ファイルを含むすべてのファイルをシークレットに再度追加する必要があります。たとえば、この手順の前半で作成した new-users.properties ファイルに新しいユーザーを追加する場合は、次のコマンドを使用して、custom-jaas-config シークレットを更新します。

   oc set data secret/custom-jaas-config --from-file=login.config=login.config --from-file=new-users.properties=new-users.properties --from-file=new-roles.properties=new-roles.properties

手順

1. oc create secret コマンドを使用して、追加するサードパーティーの JAR ファイルを含むシークレットを作成します。以下に例を示します。

   oc create secret generic log4j-template --from-file=log4j-layout-template-json-2.22.1.jar

   シークレットを作成する方法の詳細は、Kubernetes ドキュメントの Secrets を参照してください。

2. ブローカーデプロイメントの CR を編集し、各ブローカー Pod にサードパーティーの JAR ファイルを含むシークレットをマウントするように Operator を設定します。たとえば、次の設定では、log4j-template という名前のシークレットをマウントします。

   deploymentPlan:
     ...
     extraMounts:
       secrets:
       - "log4j-template"
     ...

   JAR ファイルは、各ブローカー Pod の /amq/extra/secrets/secret name ディレクトリーにマウントされます。たとえば、/amq/extra/secrets/postgresql-driver/log4j-template.jar です。

3. ARTEMIS_EXTRA_LIBS 環境変数を作成してブローカーの Java クラスパスを拡張し、ブローカーが各 Pod のマウントされたディレクトリーから JAR ファイルをロードできるようにします。以下に例を示します。

   spec:
     ...
     env:
     - name: ARTEMIS_EXTRA_LIBS
       value: /amq/extra/secrets/log4j-template

4. CR を保存します。

手順

1. ブローカーデプロイメントの ActiveMQArtemis CR を編集します。

2. ブローカー CR で、extraVolumes および extraVolumeMounts 属性を使用して永続ボリュームを追加し、各ブローカー Pod にボリュームをマウントします。以下に例を示します。

   deploymentPlan:
     ...
     extraVolumes:
     - name: extra-volume
       persistentVolumeClaim:
         claimName: extra-jars
     extraVolumeMounts:
     - name: extra-volume
       mountPath: /opt/extra-lib
     ...

3. resourceTemplates 属性を使用して、デプロイメントの StatefulSet リソースをカスタマイズします。このカスタマイズでは、init コンテナーを使用して、各 Pod に作成した extra-volume をマウントし、JAR ファイルをボリュームにダウンロードします。以下に例を示します。

   spec:
     ...
     resourceTemplates:
     - selector:
         kind: StatefulSet
       patch:
         kind: StatefulSet
         spec:
           template:
             spec:
               initContainers:
               - name: mysql-jdbc-driver-init
                 volumeMounts:
                 - mountPath: /opt/extra-lib
                   name: extra-volume
                 image: curlimages/curl:8.6.0
                 command:
                 - /bin/sh
                 args:
                 - -c
                 - "if ! [ -f /opt/extra-lib/mysql-connector.jar ]; then curl https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.23/mysql-connector-java-8.0.23.jar --output /opt/extra-lib/mysql-connector.jar ; fi"

   この例では、ファイルがボリューム上にまだ存在しない場合に、curl イメージを使用して、ボリュームのマウントされたパス /opt/extra-lib に mysql-connector.jar ファイルをダウンロードします。

4. ARTEMIS_EXTRA_LIBS 環境変数を作成してブローカーの Java クラスパスを拡張し、ブローカーが共有ボリュームから JAR ファイルをロードできるようにします。以下に例を示します。

   spec:
     ...
     env:
     - name: ARTEMIS_EXTRA_LIBS
       value: /opt/extra-lib

5. CR を保存します。

手順

1. ブローカーデプロイメントの ActiveMQArtemis カスタムリソース (CR) を編集します。

2. persistenceEnabled 属性を true に設定します。以下に例を示します。

   spec:
     ...
     deploymentPlan:
       persistenceEnabled: true
     ...

3. CR を保存します。

手順

1. ブローカーデプロイメントの ActiveMQArtemis カスタムリソース (CR) を編集します。

2. brokerProperties 属性を使用して、JDBC データベースの永続性を有効にします。以下に例を示します。

   spec:
     ...
     brokerProperties:
     - storeConfiguration=DATABASE
     - storeConfiguration.jdbcDriverClassName=<class name>
     - storeConfiguration.jdbcConnectionUrl=jdbc:<URL>
     - HAPolicyConfiguration=SHARED_STORE_PRIMARY
     ...

   storeConfiguration

   メッセージを JDBC データベースに永続化するには、DATABASE の値を指定します。

   storeConfiguration.jdbcDriverClassName

   JDBC データベースドライバーの完全修飾クラス名。たとえば、org.postgresql.Driver です。

   サポートされるデータベースの詳細は、Red Hat カスタマーポータルの Red Hat AMQ 7 Supported Configurations を参照してください。

   storeConfiguration.jdbcConnectionUrl

   データベース名とすべての設定パラメーターを含む、データベースサーバーの完全な JDBC 接続 URL。以下に例を示します。

   jdbc:postgresql://postgresql-service.default.svc.cluster.local:5432/postgres?user=postgres&password=postgres

   この例では、データベース名は postgres です。

   HAPolicyConfiguration

   ブローカーで JDBC リースロックを使用して、複数のブローカーによる同時アクセスからデータベーステーブルを保護するには、SHARED_STORE_PRIMARY に設定します。2 番目のブローカーインスタンスが意図せずにデプロイされても、リースロックにより、2 番目のブローカーによるデータベースへの書き込みが防止されます。

3. (オプション) 必要に応じて、次の属性のデフォルト値を変更します。

   storeConfiguration.jdbcNetworkTimeout

   JDBC ネットワーク接続のタイムアウト (ミリ秒単位)。デフォルト値は 20000 ミリ秒です。

   storeConfiguration.jdbcLockRenewPeriod

   現在の JDBC ロックの更新期間の長さ (ミリ秒単位)。この時間が経過すると、ブローカーはロックを更新できます。storeConfiguration.jdbcLockExpiration の値より数倍小さい値を設定すると、ブローカーがリースを延長するのに十分な時間を確保できます。また、接続の問題が発生した場合にロックの更新を試行する時間も確保できます。デフォルト値は 2000 ミリ秒です。

   storeConfiguration.jdbcLockExpiration

   storeConfiguration.jdbcLockRenewPeriod の値が経過した場合でも、現在の JDBC ロックが所有されている (取得または更新されている) と見なされる時間 (ミリ秒単位)。ブローカーは、storeConfiguration.jdbcLockRenewPeriod の値に従って、所有するロックを定期的な更新を試行します。(接続の問題などにより) ブローカーがロックの更新に失敗した場合、ブローカーはロックが最後に正常に取得または更新されてから storeConfiguration.jdbcLockExpiration の値が経過するまでロックの更新を試み続けます。上記の更新動作の例外は、別のブローカーがロックを取得する場合です。これは、Database Management System (DBMS) とブローカー間の時間の不整合が発生した場合や、ガベージコレクションの一時停止期間が長い場合に発生する可能性があります。この場合、最初にロックを所有していたブローカーは、ロックが失われたと判断し、更新を試行しません。有効期限の経過後、現在 JDBC ロックを所有しているブローカーによって JDBC ロックが更新されない場合、別のブローカーが JDBC ロックを確立できます。デフォルト値は 20000 ミリ秒です。

   storeConfiguration.jdbcJournalSyncPeriod

   ブローカージャーナルが JDBC と同期する期間 (ミリ秒単位)。デフォルト値は 5 ミリ秒です。

   storeConfiguration.jdbcMaxPageSizeBytes

   AMQ Broker がメッセージを JDBC データベースで永続化するときの各ページファイルの最大サイズ (バイト単位)。デフォルト値は 102400、つまり 100 KB です。指定する値は、K、MB、GB などのバイト表記もサポートします。

4. CR を保存します。

手順

1. ブローカーデプロイメントのカスタムリソース (CR) インスタンスの設定を開始します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. デプロイメントを作成するプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

         oc login -u <user> -p <password> --server=<host:port>

      2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemis_cr.yaml というサンプル CR ファイルを開きます。

   2. OpenShift Container Platform Web コンソールの使用

      1. デプロイメントを作成するプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. メインブローカー CRD に基づいて新規 CR インスタンスを起動します。左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。

      5. Create ActiveMQArtemis をクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

   基本的なブローカーデプロイメントの場合、設定が以下のように表示される可能性があります。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true

   broker_activemqartemis_cr.yaml サンプル CR ファイルで、image プロパティーが placeholder のデフォルト値に設定されていることを確認します。この値はデフォルトで、image プロパティーによってデプロイメントに使用するブローカーコンテナーイメージが指定されていないことを示します。Operator が使用する適切なブローカーコンテナーイメージを判別する方法については、「Operator によるコンテナーイメージの選択方法」 を参照してください。

2. ブローカーのストレージサイズを指定するには、CR の deploymentPlan セクションに storage セクションを追加します。size プロパティーを追加し、値を指定します。以下に例を示します。

   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true
       storage:
         size: 4Gi

   storage.size

   各ブローカー Pod が永続ストレージに必要な Persistent Volume Claim (永続ボリューム要求、PVC) のサイズ (バイト単位)。このプロパティーは、persistenceEnabled が true に設定されている場合にのみ適用されます。指定する値には、バイト表記 (K、M、G など) を使用する単位、または同等の 2 進数 (Ki、Mi、Gi) が含まれている 必要 があります。

3. 各ブローカー Pod が永続ストレージに必要なストレージクラスを指定するには、storage セクションで storageClassName プロパティーを追加し、値を指定します。以下に例を示します。

   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true
       storage:
         size: 4Gi
         storageClassName: gp3

   storage.storageClassName

   永続ボリューム要求 (PVC) で要求するストレージクラスの名前。ストレージクラスは、管理者が使用可能なストレージを記述および分類する方法を提供します。たとえば、さまざまなストレージクラスが、特定のサービス品質レベル、バックアップポリシーなどにマッピングされる場合があります。

   ストレージクラスを指定しない場合、クラスター用に設定されたデフォルトのストレージクラスを持つ永続ボリュームが PVC によって要求されます。

   注記

   ストレージクラスを指定すると、ボリュームのストレージクラスが指定されたストレージクラスと一致する場合にのみ、PVC によって永続ボリュームが要求されます。

4. CR インスタンスをデプロイします。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. CR ファイルを保存します。

      2. ブローカーデプロイメントを作成するプロジェクトに切り替えます。

         $ oc project <project_name>

      3. CR インスタンスを作成します。

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. OpenShift Web コンソールの使用

      1. CR の設定が完了したら、Create をクリックします。

手順

1. ブローカーデプロイメントのカスタムリソース (CR) インスタンスの設定を開始します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. デプロイメントを作成するプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

         oc login -u <user> -p <password> --server=<host:port>

      2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemis_cr.yaml というサンプル CR ファイルを開きます。

   2. OpenShift Container Platform Web コンソールの使用

      1. デプロイメントを作成するプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. メインブローカー CRD に基づいて新規 CR インスタンスを起動します。左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。

      5. Create ActiveMQArtemis をクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

   基本的なブローカーデプロイメントの場合、設定が以下のように表示される可能性があります。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true

   broker_activemqartemis_cr.yaml サンプル CR ファイルで、image プロパティーが placeholder のデフォルト値に設定されていることを確認します。この値はデフォルトで、image プロパティーによってデプロイメントに使用するブローカーコンテナーイメージが指定されていないことを示します。Operator が使用する適切なブローカーコンテナーイメージを判別する方法については、「Operator によるコンテナーイメージの選択方法」 を参照してください。

2. CR の deploymentPlan セクションで、resources セクションを追加します。limits および requests サブセクションを追加します。各サブセクションで cpu および memory プロパティーを追加し、値を指定します。以下に例を示します。

   spec:
     deploymentPlan:
       size: 1
       image: placeholder
       requireLogin: false
       persistenceEnabled: true
       journalType: nio
       messageMigration: true
       resources:
         limits:
           cpu: "500m"
           memory: "1024M"
         requests:
           cpu: "250m"
           memory: "512M"

   limits.cpu

   デプロイメントで Pod で実行される各ブローカーコンテナーは、このホストノードの CPU 使用率を超過することはできません。

   limits.memory

   デプロイメントで Pod で実行される各ブローカーコンテナーは、このホストノードのメモリー使用率を超過することはできません。

   requests.cpu

   デプロイメントで Pod で実行される各ブローカーコンテナーはこのホストノード CPU の量を要求します。この値は、ブローカーコンテナーの実行に必要な CPU の最小量です。

   requests.memory

   デプロイメントで Pod で実行される各ブローカーコンテナーはこのホストノードメモリーを要求します。この値は、ブローカーコンテナーの実行に必要なメモリーの最小量です。

   注記

   リソースの 制限 を指定し、要求 を指定しない場合、ブローカーコンテナーはそのリソースに設定された 制限 値を要求します。たとえば、以下の設定では、ブローカーコンテナーは 500m cpu および 1024M メモリーに設定された 制限 値を要求します。

   spec:
     deploymentPlan:
       size: 3
       ...
       resources:
         limits:
           cpu: "500m"
           memory: "1024M"

   重要

   デプロイメントに複数のブローカーがある場合は、要求 を設定して要求されるメモリーおよび CPU の量を制御し、ブローカーコンテナーに同じ値が要求されるように 制限 を設定します。

3. CR インスタンスをデプロイします。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. CR ファイルを保存します。

      2. ブローカーデプロイメントを作成するプロジェクトに切り替えます。

         $ oc project <project_name>

      3. CR インスタンスを作成します。

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. OpenShift Web コンソールの使用

      1. CR の設定が完了したら、Create をクリックします。

手順

1. ブローカーデプロイメントの ActiveMQArtemis カスタムリソース (CR) を編集します。

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

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

   設定されたアクセプターはポート 5672 を AMQP クライアントに公開します。protocols 属性に指定できるすべて値を表に示します。

   表4.4 アクセプタープロトコル

   プロトコル	値
   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 管理コンソールへの接続 を参照してください。

3. 同じアクセプターで別のプロトコルを使用するには、protocol 属性を変更します。プロトコルのコンマ区切りリストを指定します。以下に例を示します。

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

   設定されたアクセプターはポート 5672 を AMQP および OpenWire クライアントに公開するようになりました。

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

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

5. デフォルトでは、アクセプターはブローカーデプロイメントと同じ OpenShift クラスターのクライアントにのみ公開されます。アクセプターを OpenShift 外部のクライアントにも公開するには、expose 属性と sslEnabled 属性の両方を true に設定します。

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

   アクセプター (またはコネクター) で SSL (Secure Sockets Layer) セキュリティーを有効にすると、以下のような関連する設定を追加できます。

   • OpenShift クラスターに認証情報を保存するために使用されるシークレット名。アクセプターで SSL を有効にする場合は、シークレットが必要です。
   • セキュアなネットワーク通信に使用する TLS (Transport Layer Security) プロトコル。TLS は、よりセキュアな SSL バージョンで更新されています。TLS プロトコルは enabledProtocols 属性で指定します。
   • アクセプターがブローカーとクライアント間で mTLS (相互認証とも呼ばれる) を使用するかどうか。これを指定するには、needClientAuth 属性の値を true に設定します。

   これらのタスクの詳細は、「ブローカークライアント接続のセキュリティー保護」 を参照してください。

   OpenShift 外部のクライアントにアクセプターを公開すると、Operator が、デプロイメント内のブローカー Pod ごとにアクセプター専用のサービスと Openshift ルートを自動的に作成します。

6. 各 Pod のアクセプター用に公開するルートのホスト名を、Openshift クラスターの内部ルーティング設定に合わせてカスタマイズする場合は、次のいずれかまたは両方を実行します。

   • ingressHost 属性を使用して、デフォルトのホスト名を特定のアクセプターのカスタムホスト名に置き換えます。

   • ingressDomain 属性を使用して、ホスト名にカスタムドメインを追加します。カスタムドメインは、CR 設定によって公開される他のアクセプターやコンソールのルートなど、他のすべてのルートにも適用されます。

     1. アクセプタールートのカスタムホスト名を設定するには、ingressHost 属性を追加し、ホスト文字列を指定します。以下に例を示します。

        spec:
          ...
          acceptors:
          - name: my-acceptor
            protocols: amqp,openwire
            port: 5672
            connectionsAllowed: 5
            expose: true
            ingressHost: my-acceptor-production.my-subdomain.com
          ...

        注記

        ingressHost 値は Openshift クラスター上で一意である必要があります。ブローカークラスターに複数のブローカー Pod がある場合は、ingressHost 値に $(BROKER_ORDINAL) 変数を含めることで、値を一意にすることができます。各ブローカー Pod のこの変数は、Operator によって、StatefulSet が Pod に割り当てた序数に置き換えられます。たとえば、ingressHost 値が my-acceptor-$(BROKER_ORDINAL)-production.my-subdomain.com の場合、ルートのホスト名は、最初の Pod では my-acceptor-0-production.my-subdomain に設定され、2 番目の Pod では my-acceptor-1-production.my-subdomain に設定されます。

        アクセプタールートのカスタムホスト名文字列に以下の変数を含めることができます。

        表4.5 アクセプタールートのカスタムホスト名の文字列の変数

        名前	説明
        $(CR_NAME)	CR 内の metadata.name 属性の値。
        $(CR_NAMESPACE)	カスタムリソースの namespace。
        $(BROKER_ORDINAL)	StatefulSet によってブローカー Pod に割り当てられた序数。
        $(ITEM_NAME)	アクセプターの名前。
        $(RES_TYPE)	リソースの種類。ルートのリソースタイプは rte です。Ingress のリソースタイプは ing です。
        $(INGRESS_DOMAIN)	spec.ingressDomain 属性の値 (CR で設定されている場合)。

     2. ルート内のホスト名にカスタムドメインを追加するには、spec.ingressDomain 属性を追加し、カスタム文字列を指定します。以下に例を示します。

        spec:
          ...
          ingressDomain: my.domain.com

7. 組織のネットワークポリシーにより、ルートではなく Ingress を使用してアクセプターを公開することが求められる場合は、次の手順を実行します。

   1. exposeMode 属性を追加し、値を ingress に設定します。

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

   2. アクセプター用に公開する Ingress のホスト名を、Openshift クラスターの内部ルーティング設定に合わせてカスタマイズする場合は、次のいずれかまたは両方を実行します。

      • ingressHost 属性を使用して、デフォルトのホスト名をカスタムホスト名に置き換えます。

      • ingressDomain 属性を使用して、ホスト名にカスタムドメインを追加します。カスタムドメインは、CR 設定によって公開される他のアクセプターやコンソールの Ingress など、その他すべての Ingress にも適用されます。

        1. アクセプターの Ingress にカスタムホスト名を設定するには、ingressHost 属性を追加し、ホスト文字列を指定します。以下に例を示します。

           spec:
             ...
             acceptors:
             - name: my-acceptor
               protocols: amqp,openwire
               port: 5672
               connectionsAllowed: 5
               expose: true
               exposeMode: ingress
               ingressHost: my-acceptor-production.my-subdomain.com
             ...

           この手順で前述したものと同じ変数を使用して、Ingress ホストをルートホストとしてカスタマイズできます。

        2. Ingress 内のホスト名にカスタムドメインを追加するには、spec.ingressDomain 属性を追加し、カスタム文字列を指定します。以下に例を示します。

           spec:
             ...
             ingressDomain: my-subdomain.domain.com

           アクセプターの場合、Ingress のデフォルトのホスト名は、<cr-name>-<acceptor name>-<ordinal>-svc-ing-<namespace> という形式になります。たとえば、amqbroker namespace に production という名前の CR があり、ingressDomain 値が mydomain.com である場合、Pod 0 に作成される Ingress のホスト値は、production-wconsj-0-svc-ing-mynamespace.amqbroker.com になります。

手順

1. AMQP アクセプターを定義したカスタムリソース (CR) インスタンスを開きます。

   1. OpenShift コマンドラインインターフェイスの使用:

      $ oc edit -f <path/to/custom_resource_instance>.yaml

   2. OpenShift Container Platform Web コンソールの使用

      1. 左側のナビゲーションメニューで、Administration → Custom Resource Definitions をクリックします。
      2. ActiveMQArtemis CRD をクリックします。
      3. Instances タブをクリックします。
      4. プロジェクトの namespace に対応する CR インスタンスを見つけます。

   以前に設定された AMQP アクセプターは、以下のようになります。

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp
       port: 5672
       connectionsAllowed: 5
       expose: true
       sslEnabled: true
   ...

2. ブローカーが大きいメッセージとして処理する AMQP メッセージの最小サイズをバイト単位で指定します。以下に例を示します。

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp
       port: 5672
       connectionsAllowed: 5
       expose: true
       sslEnabled: true
       amqpMinLargeMessageSize: 204800
       ...
   ...

   上記の例では、ブローカーはポート 5672 で AMQP メッセージを受け入れるように設定されます。amqpMinLargeMessageSize の値に基づいて、アクセプターが 204800 バイトよりも大きい AMQP メッセージ (200 キロバイト以上) を受信する場合、ブローカーはメッセージを大きなメッセージとして格納します。

   ブローカーはメッセージを、メッセージストレージ用にブローカーが使用する永続ボリューム (PV) の永続ボリューム (デフォルトでは /opt/<custom_resource_name>/data/large-messages) にメッセージを保存します。

   amqpMinLargeMessageSize プロパティーの値を明示的に指定しないと、ブローカーは 102400 (つまり 100 キロバイト) のデフォルト値を使用します。

   amqpMinLargeMessageSize を -1 に設定すると、AMQP メッセージに対する大きなメッセージ処理が無効になります。

手順

1. ブローカーデプロイメントの CR インスタンスを編集します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift Container Platform にログインします。

      2. デプロイメントの CR を編集します。

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift Container Platform にログインします。
      2. 左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。
      5. ブローカーデプロイメントのインスタンスをクリックします。

      6. YAML タブをクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを編集できるようになります。

2. CR の deploymentPlan セクションに、startupProbe セクションを追加します。以下に例を示します。

   spec:
     deploymentPlan:
       startupProbe:
         exec:
           command:
             - /bin/bash
             - '-c'
             - /opt/amq/bin/artemis
             - 'check'
             - 'node'
             - '--up'
             - '--url'
             - 'tcp://$HOSTNAME:61616'
         initialDelaySeconds: 5
         periodSeconds: 10
         timeoutSeconds: 3
         failureThreshold: 30

   command

   コンテナー内で実行する startup プローブコマンド。この例では、startup プローブは artemis check node コマンドを使用して、AMQ Broker がブローカー Pod のコンテナー内で起動していることを確認します。

   initialDelaySeconds

   コンテナーの起動後にプローブが実行されるまでの遅延 (秒単位)。デフォルトは 0 です。

   periodSeconds

   プローブが実行される間隔 (秒単位)。デフォルトは 10 です。

   timeoutSeconds

   startup プローブコマンドがブローカーからの応答を待つ時間 (秒単位)。コマンドに対する応答が受信されない場合、コマンドは終了します。デフォルト値は 1 です。

   failureThreshold

   startup プローブが失敗したとみなされるまでの、startup プローブの連続失敗回数の最小値 (タイムアウトを含む)。プローブが失敗したとみなされると、Pod が再起動されます。デフォルト値は 3 です。

   クラスターのリソースとブローカージャーナルのサイズによっては、ブローカーが起動してプローブチェックに合格するのに十分な時間を確保するために、失敗しきい値を引き上げる必要がある場合があります。そうしなければ、ブローカーはループ状態に入って繰り返し失敗しきい値に達し、そのたびに startup プローブによって再起動されることになります。たとえば、failureThreshold を 30 に設定し、プローブがデフォルトの 10 秒間隔で実行される場合、ブローカーが起動してプローブチェックに合格するまでに 300 秒が確保されます。

3. CR を保存します。

手順

1. ブローカーデプロイメントの CR インスタンスを編集します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift Container Platform にログインします。

      2. デプロイメントの CR を編集します。

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift Container Platform にログインします。
      2. 左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。
      5. ブローカーデプロイメントのインスタンスをクリックします。
      6. YAML タブをクリックします。

2. liveness プローブを設定するには、CR の deploymentPlan セクションに livenessProbe セクションを追加します。以下に例を示します。

   spec:
     deploymentPlan:
       livenessProbe:
         initialDelaySeconds: 5
         periodSeconds: 5
         failureThreshold: 30

   initialDelaySeconds

   コンテナーの起動後にプローブが実行されるまでの遅延 (秒単位)。デフォルトは 5 です。

   注記

   デプロイメントに startup プローブも設定されている場合は、liveness プローブと readiness プローブの両方で遅延を 0 に設定できます。これらのプローブは両方とも、startup プローブに合格した後にのみ実行されます。startup プローブにすでに合格している場合は、ブローカーが正常に起動したことが確認できるため、liveness プローブと readiness プローブの実行を遅らせる必要はありません。

   periodSeconds

   プローブが実行される間隔 (秒単位)。デフォルトは 5 です。

   failureThreshold

   プローブが失敗したことを示す、liveness プローブの連続失敗回数の最小値 (タイムアウトを含む)。プローブが失敗すると、Pod が再起動されます。デフォルト値は 3 です。

   デプロイメントに、liveness プローブの実行前にブローカーアプリケーションが起動していることを確認する startup プローブが設定されていない場合は、ブローカーが起動して liveness プローブのチェックに合格するのに十分な時間を確保するために、失敗しきい値を引き上げる必要がある場合があります。そうしなければ、ブローカーがループ状態に入って繰り返し失敗しきい値に達し、そのたびにブローカー Pod が liveness プローブによって再起動される可能性があります。

   ブローカーが起動して liveness プローブのチェックに合格するまでに必要な時間は、クラスターのリソースとブローカージャーナルのサイズによって異なります。たとえば、failureThreshold を 30 に設定し、プローブがデフォルトの 5 秒間隔で実行される場合、ブローカーが起動して liveness プローブのチェックに合格するまでに 150 秒が確保されます。

   注記

   liveness プローブを設定していない場合、または設定されたプローブからハンドラーが欠落している場合、AMQ Broker Operator は次の設定を持つデフォルトの TCP プローブを作成します。デフォルトの TCP プローブは、指定されたポートでブローカーコンテナーへのソケットを開こうとします。

   spec:
     deploymentPlan:
       livenessProbe:
         tcpSocket:
           port: 8181
         initialDelaySeconds: 30
         timeoutSeconds: 5

3. readiness プローブを設定するには、CR の deploymentPlan セクションに、readinessProbe セクションを追加します。以下に例を示します。

   spec:
     deploymentPlan:
       readinessProbe:
         initialDelaySeconds: 5
         periodSeconds: 5

   readiness プローブを設定しない場合、ビルトイン スクリプト は、すべてのアクセプターが接続を受け入れることができるかどうかをチェックします。

4. より包括的な可用性チェックを設定する場合は、artemis check コマンドラインユーティリティーを liveness または readiness プローブの設定に追加します。

   1. ブローカーへの完全なクライアント接続を作成する可用性チェックを設定する場合は、livenessProbe または readinessProbe セクションに exec セクションを追加します。exec セクションに、command セクションを追加します。command セクションで、artemis check node コマンド構文を追加します。以下に例を示します。

      spec:
        deploymentPlan:
          readinessProbe:
            exec:
              command:
                - bash
                - '-c'
                - /home/jboss/amq-broker/bin/artemis
                - check
                - node
                - '--silent'
                - '--acceptor'
                - <acceptor name>
                - '--user'
                - $AMQ_USER
                - '--password'
                - $AMQ_PASSWORD
            initialDelaySeconds: 30
            timeoutSeconds: 5

      デフォルトでは、artemis check node コマンドは artemis と呼ばれるアクセプターの URI を使用します。ブローカーに artemis というアクセプターがある場合は、コマンドから --acceptor <acceptor name> オプションを除外できます。

      注記

      $AMQ_USER および $AMQ_PASSWORD は、AMQ Operator によって設定される環境変数です。

   2. メッセージを生成および消費する可用性チェックを設定し、ブローカーのファイルシステムの可用性も検証する場合は、livenessProbe または readinessProbe セクションに exec セクションを追加します。exec セクションに、command セクションを追加します。command セクションで、artemis check queue コマンド構文を追加します。以下に例を示します。

      spec:
        deploymentPlan:
          readinessProbe:
            exec:
              command:
                - bash
                - '-c'
                - /home/jboss/amq-broker/bin/artemis
                - check
                - queue
                - '--name'
                - livenessqueue
                - '--produce'
                - "1"
                - '--consume'
                - "1"
                - '--silent'
                - '--user'
                - $AMQ_USER
                - '--password'
                - $AMQ_PASSWORD
            initialDelaySeconds: 30
            timeoutSeconds: 5

      注記

      指定するキュー名は、ブローカーで設定され、anycast の routingType を持っている必要があります。以下に例を示します。

      apiVersion: broker.amq.io/v1beta1
      kind: ActiveMQArtemisAddress
      metadata:
        name: livenessqueue
        namespace: activemq-artemis-operator
      spec:
        addressName: livenessqueue
        queueConfiguration:
          purgeOnNoConsumers: false
          maxConsumers: -1
          durable: true
          enabled: true
        queueName: livenessqueue
        routingType: anycast

5. CR を保存します。

1. デプロイメントの意図的なスケールダウンにより、デプロイメント内のブローカー Pod がシャットダウンすると、Operator は自動的にスケールダウンカスタムリソースをデプロイして、メッセージ移行の準備をします。

2. 孤立した永続ボリューム (PV) の有無を確認するには、縮小コントローラーはボリューム要求上の序数を探します。コントローラーは、ボリューム要求の序数を、プロジェクトの StatefulSet (ブローカークラスター) で実行されているブローカー Pod と比較します。

   ボリューム要求の序数がブローカー Pod の序数よりも高くなる場合、スケールダウンコントローラーは、その序数のブローカー Pod がシャットダウンされ、メッセージングデータが別のブローカー Pod に移行する必要があるかどうかを判断します。

3. 縮小コントローラーはドレイン Pod を起動します。ドレイン Pod は、クラスター内の他のライブブローカー Pod の 1 つに接続し、メッセージをそのライブブローカー Pod に移行します。

手順

1. ブローカーデプロイメントの CR インスタンスを編集します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift Container Platform にログインします。

      2. デプロイメントの CR を編集します。

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift Container Platform にログインします。
      2. 左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。
      5. ブローカーデプロイメントのインスタンスをクリックします。

      6. YAML タブをクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを編集できるようになります。

2. CR の deploymentPlan セクションで、messageMigration 属性を追加し、true に設定します。設定されていない場合は、persistenceEnabled 属性を追加し、true に設定します。以下に例を示します。

   spec:
     deploymentPlan:
       messageMigration: true
       persistenceEnabled: true
     ...

   これらの設定は、クラスターブローカーデプロイメントのサイズを後でスケールダウンすると、Operator はスケールダウンコントローラーが自動的に起動し、メッセージを実行中のブローカー Pod に移行することができます。

3. CR を保存します。

4. (オプション) 以下の手順を実行してクラスターをスケールダウンし、メッセージ移行プロセスを表示します。

   1. 既存のブローカーデプロイメントで、実行中の Pod を確認します。

      $ oc get pods

      以下のような出力が表示されます。

      activemq-artemis-operator-8566d9bf58-9g25l   1/1   Running   0   3m38s
      ex-aao-ss-0                                  1/1   Running   0   112s
      ex-aao-ss-1                                  1/1   Running   0   8s

      上記の出力では、3 つの Pod が実行されていることが示されています。1 つはブローカー Operator 自体用で、デプロイメントの各ブローカーに個別の Pod が実行されていることを示しています。

   2. 各 Pod にログインし、各ブローカーにメッセージを送信します。

      1. Pod ex-aao-ss-0 にクラスター IP アドレスが 172.17.0.6 である場合は、以下のコマンドを実行します。

         $ /opt/amq/bin/artemis producer --url tcp://172.17.0.6:61616 --user admin --password admin

   3. Pod ex-aao-ss-1 にクラスター IP アドレスが 172.17.0.7 である場合は、以下のコマンドを実行します。

      $ /opt/amq/bin/artemis producer --url tcp://172.17.0.7:61616 --user admin --password admin

      前述のコマンドは、各ブローカーに TEST というキューを作成し、各キューに 1000 個のメッセージを追加します。

   4. クラスターを 2 つのブローカーにスケールダウンします。

      1. メインブローカー CR broker_activemqartemis_cr.yaml を開きます。
      2. CR で、deploymentPlan.size を 1 に設定します。

      3. コマンドラインで変更を適用します。

         $ oc apply -f deploy/crs/broker_activemqartemis_cr.yaml

         Pod ex-aao-ss-1 がシャットダウンを開始したことを確認します。縮小コントローラーは、同じ名前の新しいドレイン Pod を起動します。このドレイン Pod は、ブローカー Pod ex-aao-ss-1 からクラスター内の他のブローカー Pod にすべてのメッセージを移行した後にシャットダウンします (ex-aao-ss-0)。

   5. ドレイン Pod がシャットダウンされたら、ブローカー Pod ex-aao-ss-0 の TEST キューのメッセージ数を確認します。キューのメッセージ数が 2000 であることを確認できます。これは、ドレイン Pod がシャットダウンするブローカー Pod から 1000 個のメッセージを正常に移行しました。

手順

1. メインブローカー CRD に基づいてカスタムリソース (CR) インスタンスを作成します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

         oc login -u <user> -p <password> --server=<host:port>

      2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemis_cr.yaml というサンプル CR ファイルを開きます。

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. メインブローカー CRD に基づいて新規 CR インスタンスを起動します。左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。

      5. Create ActiveMQArtemis をクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

2. CR の deploymentPlan セクションで、nodeSelector セクションを追加し、Pod のノードを選択するために一致させたいノードラベルを追加します。以下に例を示します。

   spec:
       deploymentPlan:
         nodeSelector:
           app: broker1

   この例では、ブローカー Pod は app: broker1 ラベルを持つノードでスケジュールされます。

3. CR インスタンスをデプロイします。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. CR ファイルを保存します。

      2. ブローカーデプロイメントを作成するプロジェクトに切り替えます。

         $ oc project <project_name>

      3. CR インスタンスを作成します。

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. OpenShift Web コンソールの使用

      1. CR の設定が完了したら、Create をクリックします。

手順

1. メインブローカー CRD に基づいてカスタムリソース (CR) インスタンスを作成します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

         oc login -u <user> -p <password> --server=<host:port>

      2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemis_cr.yaml というサンプル CR ファイルを開きます。

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. メインブローカー CRD に基づいて新規 CR インスタンスを起動します。左側のペインで、Administration → Custom Resource Definitions をクリックします。
      3. ActiveMQArtemis CRD をクリックします。
      4. Instances タブをクリックします。

      5. Create ActiveMQArtemis をクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

2. CR の deploymentPlan セクションに、tolerations セクションを追加します。tolerations セクションで、一致させたいノードテイントの容認を追加します。以下に例を示します。

   spec:
        deploymentPlan:
           tolerations:
           - key: "app"
             value: "amq-broker"
             effect: "NoSchedule"

   この例では、容認は app=amq-broker:NoSchedule のノードテイントと一致するため、このテイントが設定されているノードで Pod をスケジュールできます。

1. CR インスタンスをデプロイします。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. CR ファイルを保存します。

      2. ブローカーデプロイメントを作成するプロジェクトに切り替えます。

         $ oc project <project_name>

      3. CR インスタンスを作成します。

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. OpenShift Web コンソールの使用

      1. CR の設定が完了したら、Create をクリックします。

手順

1. ブローカーに適用する brokerProperties 設定を含む Java プロパティー形式のファイルを作成します。各プロパティーをプロパティーファイルに個別の行に追加します。以下に例を示します。

   securityRoles.address1.group2.send=true
   securityRoles.address2.group1.consume=true
   securityRoles.address2.group2.createAddress=true

2. ファイルを .properties 拡張子で保存します (例: securityRoles.properties)。

3. 作成した .properties ファイルが含まれるシークレットを作成します。

   oc create secret generic address-settings-bp --from-file=securityRoles.properties

   注記

   シークレット名には -bp という接尾辞が必要です。シークレットに -bp 接尾辞が付いている場合、Operator によって、ブローカー Pod 上のシークレットがマウントされているディレクトリーでプロパティーファイルを検索するようにブローカーが設定されます。

4. extraMounts 属性にシークレットへの参照を追加して、Operator が各ブローカー Pod 上のシークレットにあるプロパティーファイルをマウントできるようにします。

   deploymentPlan:
     ...
     extraMounts:
       secrets:
       - "address-settings-bp"
     ...

   Operator は、各ブローカー Pod の /amq/extra/secrets/<secret name> ディレクトリー内のシークレットにある .properties ファイルをマウントします。

   起動時に、ブローカーはマウントされた各ディレクトリーで .properties 拡張子を持つファイルを検索し、ファイルをアルファベット順に並べ替えて、ファイル内の設定を順々に適用します。プロパティーファイル内で、ブローカーはリストされている順序でプロパティーを適用します。

手順

1. クラスター管理者として OpenShift Container Platform Web コンソールにログインします。
2. プロジェクトから既存の AMQ Broker Operator をアンインストールします。
3. 左側のナビゲーションメニューで、Operators → Installed Operators をクリックします。
4. ページ上部の Project ドロップダウンメニューから、Operator をアンインストールするプロジェクトを選択します。
5. アンインストールする Red Hat Integration - AMQ Broker インスタンスを見つけます。

6. Operator インスタンスの場合は、右側の More Options アイコン (3 つの点) をクリックします。Uninstall Operator を選択します。

   警告

   Delete all operand instances for this operator チェックボックスが選択されてい ない ことを確認します。このチェックボックスが選択されている場合、Operator によって管理されるブローカーインスタンスは Operator をアンインストールすると削除されます。

7. 確認ダイアログボックスで、Uninstall をクリックします。
8. OperatorHub を使用して、Operator for AMQ Broker 7.12 の最新バージョンをインストールします。詳細は、「OperatorHub からの Operator のデプロイ」 を参照してください。
9. 左側のナビゲーションメニューで、Operators → Installed Operators をクリックします。
10. 正しいバージョン番号が、インストールされている Red Hat Integration - AMQ Broker インスタンスに表示されることを確認します。

手順

1. クラスター管理者として OpenShift Container Platform Web コンソールにログインします。

2. プロジェクトから既存の AMQ Broker Operator をアンインストールします。

   1. 左側のナビゲーションメニューで、Operators → Installed Operators をクリックします。
   2. ページ上部の Project ドロップダウンメニューから、Operator をアンインストールするプロジェクトを選択します。
   3. アンインストールする Red Hat Integration - AMQ Broker インスタンスを見つけます。
   4. Operator インスタンスの場合は、右側の More Options アイコン (3 つの点) をクリックします。Uninstall Operator を選択します。
   5. 確認ダイアログボックスで、Uninstall をクリックします。

3. 7.10.0 Operator をアップグレードすると、新しい Operator は StatefulSet を削除して、7.10.0 で Operator により StatefulSet セレクターに誤って追加されたカスタムと Operator メータリングラベルを削除します。Operator が StatefulSet を削除すると、既存のブローカー Pod も削除されるため、一時的なブローカーの停止が発生します。停止を回避するには、次の手順を実行して StatefulSet を削除し、ブローカー Pod を孤立させて、引き続き実行されるようにします。

   1. 既存の Operator デプロイメントが含まれるプロジェクトの管理者として OpenShift Container Platform CLI にログインします。

      $ oc login -u <user>

   2. Operator バージョンをアップグレードする OpenShift プロジェクトに切り替えます。

      $ oc project <project-name>

   3. --cascade=orphan オプションを指定して StatefulSet を削除し、ブローカー Pod を孤立させます。孤立したブローカー Pod は、StatefulSet が削除された後も引き続き実行されます。

      $ oc delete statefulset <statefulset-name> --cascade=orphan

4. メインブローカー CR に application または ActiveMQArtemis というラベルが deploymentPlan.labels 属性で設定されているか確認します。

   7.10.0 では、CR でこれらのカスタムラベルを設定できました。これらのラベルは、Operator が Pod にラベルを割り当てるために予約されており、7.10.0 以降ではカスタムラベルとして追加できません。これらのカスタムラベルが 7.10.0 のメインブローカー CR で設定されていた場合、Operator が割り当てた Pod のラベルはカスタムラベルによって上書きされました。CR にこれらのラベルのいずれかがある場合は、次の手順を実行して Pod で正しいラベルを復元し、CR からラベルを削除します。

   1. OpenShift コマンドラインインターフェイス (CLI) で、次のコマンドを実行して正しい Pod ラベルを復元します。次の例では、ex-aao はデプロイされた StatefulSet の名前です。

      $ for pod in $(oc get pods | grep -o '^ex-aao[^ ]*'); do oc label --overwrite pods $pod ActiveMQArtemis=ex-aao application=ex-aao-app; done

   2. CR の deploymentPlan.labels 属性から、application ラベルと ActiveMQArtemis ラベルを削除します。

      1. OpenShift コマンドラインインターフェイスの使用:

         1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

            oc login -u <user> -p <password> --server=<host:port>

         2. デプロイメントの CR を編集します。

            oc edit ActiveMQArtemis <statefulset name> -n <namespace>

         3. CR の deploymentPlan.labels 要素で、application または ActiveMQArtemis という名前のカスタムラベルをすべて削除します。
         4. CR を保存します。

      2. OpenShift Container Platform Web コンソールの使用

         1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
         2. 左側のペインで、Administration → Custom Resource Definitions をクリックします。
         3. ActiveMQArtemis CRD をクリックします。
         4. Instances タブをクリックします。
         5. ブローカーデプロイメントのインスタンスをクリックします。

         6. YAML タブをクリックします。

            コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

         7. CR の deploymentPlan.labels 要素で、application または ActiveMQArtemis という名前のカスタムラベルをすべて削除します。
         8. Save をクリックします。

5. OperatorHub を使用して、Operator for AMQ Broker 7.12 の最新バージョンをインストールします。詳細は、「OperatorHub からの Operator のデプロイ」 を参照してください。

   新しい Operator は、以前のブローカーのデプロイメントを認識して管理できます。CR の image または version フィールドに値を設定すると、Operator の調整プロセスは、Operator の起動時に、ブローカー Pod を対応するイメージにアップグレードします。詳細は、「ブローカーコンテナーイメージの自動アップグレードの制限」 を参照してください。それ以外の場合、Operator は各ブローカー Pod を最新のコンテナーイメージにアップグレードします。

   注記

   調整プロセスが開始されない場合は、デプロイをスケーリングすることでプロセスを開始できます。詳細は、「基本的なブローカーインスタンスのデプロイ」 を参照してください。

6. 必要に応じて、アップグレードされたブローカーで利用可能な新機能の CR に属性を追加します。

手順

1. クラスター管理者として OpenShift Container Platform Web コンソールにログインします。

2. メインブローカー CR に application または ActiveMQArtemis というラベルが deploymentPlan.labels 属性で設定されているか確認します。

   これらのラベルは、Operator が Pod にラベルを割り当てるために予約されており、7.10.1 以降では使用できません。これらのカスタムラベルがメインブローカー CR で設定されていた場合、Operator が割り当てた Pod のラベルはカスタムラベルによって上書きされました。

3. これらのカスタムラベルがメインブローカー CR で設定されていない場合は、OperatorHub を使用して、Operator for AMQ Broker 7.12 の最新バージョンをインストールします。詳細は、「OperatorHub からの Operator のデプロイ」 を参照してください。

4. これらのカスタムラベルのいずれかがメインブローカー CR で設定されている場合、新しい Operator をインストールする前に、以下の手順を実行して既存の Operator をアンインストールし、正しい Pod ラベルを復元して CR からラベルを削除します。

   注記

   Operator をアンインストールすると、Operator が StatefulSet を削除しなくてもカスタムラベルを削除できます。これにより、既存のブローカー Pod も削除され、ブローカーが一時的に停止します。

   1. プロジェクトから既存の AMQ Broker Operator をアンインストールします。

      1. 左側のナビゲーションメニューで、Operators → Installed Operators をクリックします。
      2. ページ上部の Project ドロップダウンメニューから、Operator をアンインストールするプロジェクトを選択します。
      3. アンインストールする Red Hat Integration - AMQ Broker インスタンスを見つけます。
      4. Operator インスタンスの場合は、右側の More Options アイコン (3 つの点) をクリックします。Uninstall Operator を選択します。
      5. 確認ダイアログボックスで、Uninstall をクリックします。

   2. OpenShift コマンドラインインターフェイス (CLI) で、次のコマンドを実行して正しい Pod ラベルを復元します。次の例では、ex-aao はデプロイされた StatefulSet の名前です。

      $ for pod in $(oc get pods | grep -o '^ex-aao[^ ]*'); do oc label --overwrite pods $pod ActiveMQArtemis=ex-aao application=ex-aao-app; done

   3. CR の deploymentPlan.labels 属性から、application ラベルと ActiveMQArtemis ラベルを削除します。

      1. OpenShift コマンドラインインターフェイスの使用:

         1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

            oc login -u <user> -p <password> --server=<host:port>

         2. デプロイメントの CR を編集します。

            oc edit ActiveMQArtemis <statefulset name> -n <namespace>

         3. CR の deploymentPlan.labels 属性で、application または ActiveMQArtemis というカスタムラベルをすべて削除します。
         4. CR ファイルを保存します。

      2. OpenShift Container Platform Web コンソールの使用

         1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
         2. 左側のペインで、Administration → Custom Resource Definitions をクリックします。
         3. ActiveMQArtemis CRD をクリックします。
         4. Instances タブをクリックします。
         5. ブローカーデプロイメントのインスタンスをクリックします。

         6. YAML タブをクリックします。

            コンソールで、YAML エディターが開き、CR インスタンスを設定できます。

         7. CR の deploymentPlan.labels 属性で、application または ActiveMQArtemis というカスタムラベルをすべて削除します。
         8. Save をクリックします。

5. OperatorHub を使用して、Operator for AMQ Broker 7.12 の最新バージョンをインストールします。詳細は、「OperatorHub からの Operator のデプロイ」 を参照してください。

   新しい Operator は、以前のブローカーのデプロイメントを認識して管理できます。CR の image または version フィールドに値を設定すると、Operator の調整プロセスは、Operator の起動時に、ブローカー Pod を対応するイメージにアップグレードします。詳細は、「ブローカーコンテナーイメージの自動アップグレードの制限」 を参照してください。それ以外の場合、Operator は各ブローカー Pod を最新のコンテナーイメージにアップグレードします。

   注記

   調整プロセスが開始されない場合は、デプロイをスケーリングすることでプロセスを開始できます。詳細は、「基本的なブローカーインスタンスのデプロイ」 を参照してください。

6. 必要に応じて、アップグレードされたブローカーで利用可能な新機能の CR に属性を追加します。

手順

1. Web ブラウザーで、AMQ Broker 7.12.1 の Software Downloads ページに移動します。
2. Version ドロップダウンリストの値が 7.12.1 に設定され、Releases タブが選択されていることを確認します。

3. AMQ Broker 7.12.1 Operator Installation and Example Files の横にある Download をクリックします。

   amq-broker-operator-7.12.1-ocp-install-examples.zip 圧縮アーカイブのダウンロードが自動的に開始されます。

4. ダウンロードが完了したら、アーカイブを選択したインストールディレクトリーに移動します。以下の例では、アーカイブを ~/broker/operator という名前のディレクトリーに移動します。

   $ mkdir ~/broker/operator
   $ mv amq-broker-operator-7.12.3-ocp-install-examples-rhel8.zip ~/broker/operator

5. 選択したインストールディレクトリーで、アーカイブの内容をデプロイメントします。以下に例を示します。

   $ cd ~/broker/operator
   $ unzip amq-broker-operator-operator-7.12.3-ocp-install-examples-rhel8.zip

6. 既存の Operator デプロイメントが含まれるプロジェクトの管理者として OpenShift Container Platform にログインします。

   $ oc login -u <user>

7. Operator バージョンをアップグレードする OpenShift プロジェクトに切り替えます。

   $ oc project <project-name>

8. ダウンロードした最新の Operator アーカイブの deploy ディレクトリーで、operator.yaml ファイルを開きます。

   注記

   operator.yaml ファイルでは、Operator は Secure Hash Algorithm (SHA) 値で表されるイメージを使用します。数字記号 (#) 記号で始まるコメント行は、SHA 値が特定のコンテナーイメージタグに対応していることを示します。

9. 以前 の Operator デプロイメントの operator.yaml ファイルを開きます。以前の設定で指定したデフォルト以外の値が新しい operator.yaml 設定ファイルに複製されていることを確認します。

10. 新しい operator.yaml ファイルでは、Operator の名前はデフォルトで amq-broker-controller-manager です。以前のデプロイメントの Operator の名前が amq-broker-controller-manager ではない場合は、amq-broker-controller-manager のすべてのインスタンスを以前の Operator 名に置き換えます。以下に例を示します。

    spec:
      ...
      selector
        matchLabels
          name: amq-broker-operator
      ...

11. 新しい operator.yaml ファイルでは、Operator のサービスアカウントの名前は amq-broker-controller-manager です。以前のバージョンでは、Operator のサービスアカウントの名前は amq-broker-operator でした。

    1. 以前のデプロイメントのサービスアカウント名を使用する場合は、新しい operator.yaml ファイル内のサービスアカウントの名前を、以前のデプロイメントで使用されていた名前に置き換えます。以下に例を示します。

       spec:
         ...
         serviceAccountName: amq-broker-operator
         ...

    2. Operator に新しいサービスアカウント名 amq-broker-controller-manager を使用する場合は、プロジェクト内のサービスアカウント、ロール、ロールバインディングを更新します。

       $ oc apply -f deploy/service_account.yaml

       $ oc apply -f deploy/role.yaml

       $ oc apply -f deploy/role_binding.yaml

12. Operator に含まれる CRD を更新します。

    1. メインブローカー CRD を更新します。

       $ oc apply -f deploy/crds/broker_activemqartemis_crd.yaml

    2. アドレス CRD を更新します。

       $ oc apply -f deploy/crds/broker_activemqartemisaddress_crd.yaml

    3. スケールダウンコントローラー CRD を更新します。

       $ oc apply -f deploy/crds/broker_activemqartemisscaledown_crd.yaml

    4. セキュリティー CRD を更新します。

       $ oc apply -f deploy/crds/broker_activemqartemissecurity_crd.yaml

13. AMQ Broker Operator 7.10.0 からのアップグレードのみの場合は、Operator と StatefulSet を削除します。

    デフォルトでは、新しい Operator は StatefulSet を削除して、7.10.0 で Operator により StatefulSet セレクターに誤って追加されたカスタムと Operator メータリングラベルを削除します。Operator が StatefulSet を削除すると、既存のブローカー Pod も削除されるため、一時的なブローカーの停止が発生します。停止を回避するには、以下の手順を実行して、ブローカー Pod を削除せずに Operator と StatefulSet を削除します。

    1. Operator を削除します。

       $ oc delete -f deploy/operator.yaml

       注記

       Operator を削除しても、Operator で管理されるブローカーインスタンスは削除されません。

    2. --cascade=orphan オプションを指定して StatefulSet を削除し、ブローカー Pod を孤立させます。孤立したブローカー Pod は、StatefulSet が削除された後も引き続き実行されます。

       $ oc delete statefulset <statefulset-name> --cascade=orphan

14. AMQ Broker Operator 7.10.0 または 7.10.1 からアップグレードする場合は、メインブローカー CR に application または ActiveMQArtemis というラベルが deploymentPlan.labels 属性で設定されているか確認します。

    これらのラベルは、Operator が Pod にラベルを割り当てるために予約されており、7.10.1 以降ではカスタムラベルとして許可されていません。これらのカスタムラベルがメインブローカー CR で設定されていた場合、Operator が割り当てた Pod のラベルはカスタムラベルによって上書きされました。これらのカスタムラベルのいずれかがメインブローカー CR で設定されている場合は、次の手順を実行して Pod で正しいラベルを復元し、CR からラベルを削除します。

    1. 7.10.0 からアップグレードする場合は、前の手順で Operator を削除しています。7.10.1 からアップグレードする場合は、Operator を削除します。

       $ oc delete -f deploy/operator.yaml

    2. 次のコマンドを実行して、正しい Pod ラベルを復元します。次の例では、ex-aao はデプロイされた StatefulSet の名前です。

       $ for pod in $(oc get pods | grep -o '^ex-aao[^ ]*'); do oc label --overwrite pods $pod ActiveMQArtemis=ex-aao application=ex-aao-app; done

    3. CR の deploymentPlan.labels 属性から、application ラベルと ActiveMQArtemis ラベルを削除します。

       1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとして OpenShift にログインします。

          oc login -u <user> -p <password> --server=<host:port>

       2. ダウンロードした Operator インストールアーカイブの deploy/crs ディレクトリーに含まれる broker_activemqartemis_cr.yaml というサンプル CR ファイルを開きます。
       3. CR の deploymentPlan.labels 属性で、application または ActiveMQArtemis というカスタムラベルをすべて削除します。
       4. CR ファイルを保存します。

       5. CR インスタンスをデプロイします。

          1. ブローカーデプロイメントのプロジェクトに切り替えます。

             $ oc project <project_name>

          2. CR を適用します。

             $ oc apply -f <path/to/broker_custom_resource_instance>.yaml

    4. 以前の Operator を削除した場合は、新しい Operator をデプロイします。

        $ oc create -f deploy/operator.yaml

15. 更新された Operator 設定を適用します。

    $ oc apply -f deploy/operator.yaml

16. 必要に応じて、アップグレードされたブローカーで利用可能な新機能の CR に属性を追加します。

手順

1. ブローカーデプロイメントのメインブローカー CR インスタンスを編集します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトで CR を編集およびデプロイする権限を持つユーザーとして OpenShift にログインします。

         $ oc login -u <user> -p <password> --server=<host:port>

      2. CR を編集します。

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. 左側のペインで、Operators → Installed Operator をクリックします。
      3. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator をクリックします。
      4. AMQ Broker タブをクリックします。
      5. ActiveMQArtemis インスタンス名をクリックします。

      6. YAML タブをクリックします。

         コンソールで、YAML エディターが開き、CR インスタンスを編集できるようになります。

         注記

         CR の status セクションの .status.version.brokerVersion フィールドには、現在デプロイされている AMQ Broker のバージョンが表示されます。

2. spec.version 属性で、Operator がデプロイメント内のブローカーおよび init コンテナーイメージをアップグレードできるバージョンを指定します。指定できる値の例を次に示します。

   例

   次の例では、Operator がデプロイメント内の現在のコンテナーイメージを 7.12.0 にアップグレードします。

   spec:
      version: '7.12.0'
       ...

   次の例では、Operator は、デプロイメント内の現在のコンテナーイメージを利用可能な最新の 7.11.x イメージにアップグレードします。たとえば、デプロイメントで 7.11.1 コンテナーイメージを使用している場合、Operator はイメージを 7.12.1 ではなく 7.11.6 に自動的にアップグレードします。

   spec:
       version: '7.11'
       ...

   次の例では、Operator がデプロイメント内の現在のコンテナーイメージを最新の 7.x.x イメージにアップグレードします。たとえば、デプロイメントで 7.11.6 イメージを使用している場合、Operator はイメージを 7.12.1 に自動的にアップグレードします。

   spec:
       version: '7'
       ...

   注記

   コンテナーイメージのマイナーバージョン間で (たとえば、7.11.x から 7.12.x に) アップグレードするには、新しいコンテナーイメージと同じマイナーバージョンを持つ Operator が必要です。たとえば、7.11.6 から 7.12.1 にアップグレードするには、7.12.x Operator をインストールする必要があります。

3. CR を保存します。

手順

1. Operator が現在のイメージをアップグレードできるブローカーおよび init コンテナーイメージの URL を取得します。

   1. Red Hat カタログで、ブローカーコンテナーコンポーネントページ AMQ Broker for RHEL 8 (Multiarch) を開きます。
   2. Architecture ドロップダウンで、アーキテクチャーを選択します。
   3. Tag ドロップダウンで、インストールするイメージに対応するタグを選択します。タグはリリース日に基づいて時系列に表示されます。タグは、リリースバージョンと割り当てられたタグで構成されます。
   4. Get this image タブを開きます。
   5. Manifest フィールドで、Copy アイコンをクリックします。
   6. URL をテキストファイルに貼り付けます。
   7. Red Hat カタログで、init コンテナーコンポーネントページ AMQ Broker Init for RHEL 8 (Multiarch) を開きます。
   8. init コンテナーイメージの URL を取得するには、ブローカーコンテナーイメージの URL を取得するために実行した手順を繰り返します。

2. ブローカーデプロイメントのメインブローカー CR インスタンスを編集します。

   1. OpenShift コマンドラインインターフェイスの使用:

      1. ブローカーデプロイメントのプロジェクトで CR を編集およびデプロイする権限を持つユーザーとして OpenShift にログインします。

         $ oc login -u <user> -p <password> --server=<host:port>

      2. CR を編集します。

          oc edit ActiveMQArtemis <CR instance name> -n <namespace>

   2. OpenShift Container Platform Web コンソールの使用

      1. ブローカーデプロイメントのプロジェクトに CR をデプロイする権限を持つユーザーとしてコンソールにログインします。
      2. 左側のペインで、Operators → Installed Operator をクリックします。
      3. Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator をクリックします。
      4. AMQ Broker タブをクリックします。
      5. ActiveMQArtemis インスタンス名をクリックします。

      6. YAML タブをクリックします。

         コンソール内で YAML エディターが開き、CR インスタンスを設定できるようになります。

   3. テキストファイルに記録したブローカーと init コンテナーイメージの URL をコピーし、CR の spec.deploymentPlan.image フィールドと spec.deploymentPlan.initImage フィールドに挿入します。以下に例を示します。

      spec:
        ...
        deploymentPlan:
          image: registry.redhat.io/amq7/amq-broker-rhel8@55ae4e28b100534d63c34ab86f69230d274c999d46d1493f26fe3e75ba7a0cec
          initImage: registry.redhat.io/amq7/amq-broker-init-rhel8@442339c33549f2be9fe3b5c71184a753a3cf10b000b2ecc5bc9a062dd91c8def
        ...

3. CR を保存します。

   CR を保存すると、Operator は新しいイメージを使用するようにブローカーをアップグレードし、spec.deploymentPlan.image 属性および spec.deploymentPlan.initImage 属性の値が再度更新されるまで、これらのイメージを使用します。

4. 今後の Operator のアップグレードによってデプロイメント内のブローカーが再起動するのを防ぐには、CR を編集し、spec.version 属性でデプロイされるブローカーのバージョン番号を指定します。

   spec.version 属性が CR に設定されていない場合、今後の Operator のアップグレードによってブローカー Pod が再起動します。spec.version 属性にバージョン番号が明示的に設定されていない限り、新しい Operator はサポートされている最新のブローカーバージョンを StatefulSet のラベルに追加するため、Pod の再起動が必要です。

   ブローカーの起動後、CR の status セクションで、spec.version 属性に指定するバージョン番号の値を確認できます。詳細は、ブローカーデプロイメントのステータス情報の表示 を参照してください。

手順

1. ブローカーのデプロイメントに使用する CR インスタンスを開きます。たとえば、基本的なデプロイメントの CR は次のようになります。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 4
       image: registry.redhat.io/amq7/amq-broker-rhel8:7.12
     ...

2. 次に示すように、 deployment Plan セクションで、enable Metrics Plugin プロパティーを追加し、値を true に設定します。

   apiVersion: broker.amq.io/v1beta1
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
   spec:
     deploymentPlan:
       size: 4
       image: registry.redhat.io/amq7/amq-broker-rhel8:7.12
       ...
       enableMetricsPlugin: true

   enableMetricsPlugin

   デプロイメント内のブローカーに対して Prometheus プラグインを有効にするかどうかを指定します。

3. CR インスタンスを保存します。

4. ブローカーデプロイメントを先に作成したプロジェクトに切り替えます。

   $ oc project <project_name>

5. コマンドラインで変更を適用します。

   $ oc apply -f <path/to/custom_resource_instance>.yaml

   メトリックプラグインは、Prometheus 形式でブローカーランタイムメトリックの収集を開始します。

手順

1. ブローカーのデプロイメントなどのプロジェクトに対する管理者権限で、OpenShift Container Platform Web コンソールにログインします。
2. Web コンソールで、Home → Projects をクリックします。ブローカーのデプロイメントが含まれるプロジェクトを選択します。
3. プロジェクトの StatefulSets または DeploymentConfigs を表示するには、Workloads → StatefulSets または Workloads → DeploymentConfigs をクリックします。
4. ブローカーのデプロイメントに対応する StatefulSet または DeploymentConfig をクリックします。
5. ブローカーデプロイメントの環境変数にアクセスするには、環境 タブをクリックします。

6. 新しい環境変数 AMQ_ENABLE_METRICS_PLUGIN を追加します。変数の値を true に設定します。

   AMQ_ENABLE_METRICS_PLUGIN 環境変数を設定すると、OpenShift は StatefulSet または DeploymentConfig で各ブローカー Pod を再起動します。デプロイメントに複数の Pod がある場合、OpenShift は各 Pod を順番に再起動します。各ブローカー Pod が再起動すると、そのブローカーの Prometheus プラグインがブローカーのランタイムメトリックの収集を開始します。

手順

1. メトリックのアクセス先のブローカー Pod では、以前に Pod への接続用に作成したルートを特定して、AMQ Broker 管理コンソールに接続する必要があります。メトリックへのアクセスに必要な URL の一部に、ルート名が含まれます。

   1. Networking → Routes をクリックします。

   2. 選択したブローカー Pod で、AMQ Broker 管理コンソールへの Pod の接続用に作成されたルートを特定します。ホスト名に表示される完全な URL をメモします。以下に例を示します。

      http://rte-console-access-pod1.openshiftdomain

2. Prometheus メトリックにアクセスするには、Web ブラウザーで、先程メモをしたルート名に / metrics が付けて入力します。以下に例を示します。

   http://rte-console-access-pod1.openshiftdomain/metrics