第7章 上級者向けチュートリアル
7.1. ワークフローの例: クラスターをスケールダウンするときの自動化トランザクションリカバリー機能
この機能はテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は本番環境での使用はサポートされず、今後大きな変更がある場合があります。テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジプレビュー機能のサポート範囲」を参照してください。
このチュートリアルでは、クラスターをスケールダウンするときに JBoss EAP for OpenShift イメージの自動化トランザクションリカバリー機能を実行します。ここでは、jta-crash-rec-eap7
クイックスタートサンプルと eap72-tx-recovery-s2i
アプリケーションテンプレートは、クラスターのスケールダウンによって OpenShift Pod が終了されたときに XA トランザクションの問題が、どのように専用のマイグレーション Pod によってリカバリーされるかを示すために使用されます。
jta-crash-rec-eap7
クイックスタートは、JBoss EAP に含まれる H2 データベースを使用します。これは、例でのみ使用される、ライトウェイトなリレーショナルデータソースのサンプルです。堅牢でもスケーラブルでもなく、サポートされないため、本番環境では使用しないでください。
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
永続ボリュームクレーム
のデータを保持するため eap72-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 メソッドを使用して
eap72-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. デプロイメント
-
eap72-tx-recovery-s2i アプリケーションテンプレートを使用して、
クイックスタートをデプロイします。以下を指定します。jta-crash-rec-eap7
例: eap72-tx-recovery-s2i
アプリケーションテンプレート
+
$ oc new-app --template=eap72-tx-recovery-s2i \ -p SOURCE_REPOSITORY_URL=https://github.com/jboss-openshift/openshift-quickstarts \ -p SOURCE_REPOSITORY_REF=master \ -p CONTEXT_DIR=jta-crash-rec-eap7 \ -e CUSTOM_INSTALL_DIRECTORIES=extensions/* \ --name=eap-app --> Deploying template "openshift/eap72-tx-recovery-s2i" to project eap-tx-demo JBoss EAP 7.0 (tx recovery) --------- An example EAP 7 application. For more information about using this template, see https://github.com/jboss-openshift/application-templates. A new EAP 7 based application has been created in your project. * With parameters: * Application Name=eap-app * Custom http Route Hostname= * Git Repository URL=https://github.com/jboss-openshift/openshift-quickstarts * Git Reference=master * Context Directory=jta-crash-rec-eap7 * Queues= * Topics= * A-MQ cluster password=nyneOXUm # generated * Github Webhook Secret=PUW8Tmov # generated * Generic Webhook Secret=o7uD7qrG # generated * ImageStream Namespace=openshift * JGroups Cluster Password=MoR1Jthf # generated * Deploy Exploded Archives=false * Maven mirror URL= * ARTIFACT_DIR= * MEMORY_LIMIT=1Gi * EAP Volume Size=1Gi * Split the data directory?=true --> Creating resources ... service "eap-app" created service "eap-app-ping" created route "eap-app" created imagestream "eap-app" created buildconfig "eap-app" created deploymentconfig "eap-app" created deploymentconfig "eap-app-migration" created persistentvolumeclaim "eap-app-eap-claim" created --> Success Build scheduled, use 'oc logs -f bc/eap-app' to track its progress. Run 'oc status' to view your app.
以上の例では、JDK 11 イメージストリームは JDK 8 イメージストリームで使用される eap72-tx-recovery-s2i
の代わりに、eap72-openjdk11-tx-recovery-s2i
アプリケーションテンプレートを使用します。
-
ビルドが完了するまで待ちます。
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-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-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-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 がトランザクションリカバリーを実行し、トランザクションが正常に完了したことを示しています。