第7章 上級者向けチュートリアル
7.1. ワークフローの例: クラスターをスケールダウンするときの自動化トランザクションリカバリー機能
この機能はテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は本番環境での使用はサポートされず、今後大きな変更がある場合があります。テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの テクノロジープレビュー機能のサポート範囲 を参照してください。
このチュートリアルでは、OpenShift 3 と、EAP オペレーターを使用せずにトランザクションを復元する場合にのみ該当します。
このチュートリアルでは、クラスターをスケールダウンするときに JBoss EAP for OpenShift イメージの自動化トランザクションリカバリー機能を実行します。このチュートリアルでは、jta-crash-rec-eap
クイックスタートサンプルと eap73-tx-recovery-s2i
アプリケーションテンプレートを使用して、クラスターのスケールダウンによって OpenShift Pod で終了されたときに XA トランザクションがどのように専用の移行 Pod によってリカバリーされるかを示します。JDK 11 イメージのアプリケーションテンプレートは eap73-openjdk11-tx-recovery-s2i
です。
このチュートリアルでは、amq-broker-72-openshift:1.1
イメージストリームを使用して JMS 準拠のメッセージブローカーを提供します。初期ブローカー Pod を設定すると、OpenShift Container Platform 機能を使用してクイックスタートを迅速にデプロイできます。
クイックスタートを使用するための前提条件として、AMQ Long Term Support (LTS)イメージからイメージストリームを作成し、イメージストリーム amq-broker-72-openshift:1.1
という名前を指定する必要があります。Red Hat Ecosystem Catalog から amq7/amq-broker-lts-rhel7:7.4
コンテナーイメージをダウンロードして LTS イメージにアクセスできます。AMQ Broker のインストールに関する詳細は、基本ブローカーのデプロイ を参照してください。
jta-crash-rec-eap7
クイックスタートは、JBoss EAP に含まれる H2 データベースを使用します。これは、例でのみ使用される、ライトウェイトなリレーショナルデータソースのサンプルです。堅牢でもスケーラブルでもなく、サポートされないため、本番環境では使用しないでください。
その他のリソース
- 基本的な AMQ Broker の作成に関する詳細は、OpenShift Container Platform での AMQ Broker のデプロイの 基本的なブローカーのデプロイ を参照してください。
7.1.1. デプロイメントの準備
-
oc login
コマンドを使用して、OpenShift インスタンスにログインします。 新しいプロジェクトを作成します。
$ oc new-project eap-tx-demo
基盤の Pod の実行に使用される
default
サービスアカウントに view ロールを追加します。これにより、サービスアカウントがeap-tx-demo
namespace のすべてのリソースを確認できるようになります。 これは、クラスターの管理に必要です。$ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
自動化トランザクションリカバリーが機能するには、JBoss EAP アプリケーションは
ReadWriteMany
永続ボリューム を使用する必要があります。${APPLICATION_NAME}-eap-claim
永続ボリュームクレーム
のデータを保持するため eap73-tx-recovery-s2i アプリケーションテンプレートによって想定される永続ボリュームのプロビジョニングを行います。この例は、以下の定義で NFS メソッドを使用してプロビジョニングされる永続ボリュームオブジェクトを使用します。
$ cat txpv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: txpv spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /mnt/mountpoint server: 192.168.100.175
上記の定義の
path
およびserver
フィールドを環境に合わせて更新し、以下のコマンドを使用して永続ボリュームのプロビジョニングを行います。$ oc create -f txpv.yaml persistentvolume "txpv" created
$ oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE txpv 1Gi RWX Retain Available 26s
重要NFS メソッドを使用して
eap73-tx-recovery-s2i
アプリケーションテンプレートの永続ボリュームオブジェクトのプロビジョニングを行う場合、適切なパーミッションがある状態でマウントポイントをエクスポートするようにしてください。マウントポイントのエクスポート元となるホストで以下を実行します。# chmod -R 777 /mnt/mountpoint
# cat /etc/exports /mnt/mountpoint *(rw,sync,anonuid=185,anongid=185)
# exportfs -va exporting *:/mnt/mountpoint
# setsebool -P virt_use_nfs 1
上記の
/mnt/mountpoint
パスは、環境に合わせて変更してください。
7.1.2. デプロイメント
eap73-tx-recovery-s2i
アプリケーションテンプレートを使用して、jta-crash-rec-eap7
クイックスタートをデプロイします。以下を指定します。例:
eap73-tx-recovery-s2i
アプリケーションテンプレート (JDK 8)$ oc new-app --template=eap73-tx-recovery-s2i \ --name=eap-app
例:
eap73-openjdk11-tx-recovery-s2i
アプリケーションテンプレート (JDK 11)$ oc new-app --template=eap73-openjdk11-tx-recovery-s2i \ --name=eap-app
-
ビルドが完了するまで待ちます。
oc logs -f bc/eap-app
コマンドを使用すると、ビルドの状態を確認できます。 JAVA_OPTS_APPEND
およびJBOSS_MODULES_SYSTEM_PKGS_APPEND
環境変数の定義でeap-app
デプロイメント設定を編集します。$ oc get dc NAME REVISION DESIRED CURRENT TRIGGERED BY eap-app 1 1 1 config,image(eap-app:latest) eap-app-amq 1 1 1 config,image(amq-broker-72-openshift:1.1) eap-app-migration 1 1 1 config,image(eap-app:latest)
$ oc set env dc/eap-app \ -e JBOSS_MODULES_SYSTEM_PKGS_APPEND="org.jboss.byteman" \ -e JAVA_OPTS_APPEND="-javaagent:/tmp/src/extensions/byteman/byteman.jar=script:/tmp/src/src/main/scripts/xa.btm" deploymentconfig "eap-app" updated
この設定は、以下のように XA トランザクションの処理を変更するよう、Byteman のトレースおよび監視ツールに通知します。
- 最初のトランザクションは成功するように常に許可されます。
- XA トラザクションが 2 つ目のトランザクションのフェーズ 2 を実行するとき、特定の Pod の JVM プロセスが停止されます。
7.1.3. JTA クラッシュリカバリーアプリケーションの使用
現在の namespace で実行中の Pod をリストします。
$ oc get pods | grep Running NAME READY STATUS RESTARTS AGE eap-app-2-r00gm 1/1 Running 0 1m eap-app-amq-1-mws7x 1/1 Running 0 2m eap-app-migration-1-lvfdt 1/1 Running 0 2m
新しい XA トラザクションを発行します。
- ブラウザーを開き、http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec にアクセスして、アプリケーションを起動します。
-
Mercedes
を Key フィールド、Benz
を Value フィールドに入力します。Submit ボタンをクリックします。 - しばらく待ち、Refresh Table リンクをクリックします。
Mercedes
エントリーが含まれるテーブル行がどのようにupdated via JMS.
で更新されるか注意してください。まだ更新されない場合は、Refresh Table リンクを数回クリックしてください。この代わりに、eap-app-2-r00gm
Pod のログを調べ、トランザクションが適切に処理されたことを確認することもできます。$ oc logs eap-app-2-r00gm | grep 'updated' INFO [org.jboss.as.quickstarts.xa.DbUpdaterMDB] (Thread-0 (ActiveMQ-client-global-threads-1566836606)) JTA Crash Record Quickstart: key value pair updated via JMS.
ブラウザーを使用し、http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec で 2 つ目の XA トラザクションを発行します。
-
Land
を Key フィールドに、Rover
を Value フィールドに入力します。Submit ボタンをクリックします。 - しばらく待ち、Refresh Table リンクをクリックします。
-
Land Rover
エントリーがupdated via …
接尾辞なしでどのように追加されたかに注目してください。
-
クラスターをスケールダウンします。
$ oc scale --replicas=0 dc/eap-app deploymentconfig "eap-app" scaled
eap-app-2-r00gm
Pod の終了がどのようにスケジュールされたかを確認します。$ oc get pods NAME READY STATUS RESTARTS AGE eap-app-1-build 0/1 Completed 0 4m eap-app-2-r00gm 1/1 Terminating 0 2m eap-app-amq-1-mws7x 1/1 Running 0 3m eap-app-migration-1-lvfdt 1/1 Running 0 3m
マイグレーション Pod のログを確認し、トランザクションリカバリーがどのように実行されるかを確認します。リカバリーの終了まで待機します。
$ oc logs -f eap-app-migration-1-lvfdt Finished Migration Check cycle, pausing for 30 seconds before resuming ... Finished, recovery terminated successfully Migration terminated with status 0 (T) Releasing lock: (/opt/eap/standalone/partitioned_data/split-1) Finished Migration Check cycle, pausing for 30 seconds before resuming ...
クラスターを元にスケールアップします。
$ oc scale --replicas=1 dc/eap-app deploymentconfig "eap-app" scaled
- ブラウザーを使用して再度 http://eap-app-eap-tx-demo.openshift.example.com/jboss-jta-crash-rec にアクセスします。
テーブルに両方のトランザクションのエントリーが含まれることに注意してください。以下の出力と似たものになります。
表7.1 例: データベーステーブルの内容
データベーステーブルの内容 Key
Value
Mercedes
Benz updated via JMS.
Land
Rover updated via JMS.
上記のテーブルの内容は、2 つ目の XA トラザクションが終了する前にクラスターがスケールダウンしたものの、マイグレーション Pod がトランザクションリカバリーを実行し、トランザクションが正常に完了したことを示しています。