JBoss EAP for OpenShift Container Platform のスタートガイド
Red Hat JBoss Enterprise Application Platform for OpenShift での開発ガイド
概要
第1章 はじめに
1.1. Red Hat JBoss Enterprise Application Platform (JBoss EAP) とは
Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP) は、オープン標準に構築されたミドルウェアプラットフォームで、Java Enterprise Edition 7 仕様に準拠します。JBoss EAP は高可用性クラスタリング、メッセージング、分散キャッシングなどの機能の事前設定オプションを提供します。必要時のみにサービスを有効にできるモジュラー構造が含まれるため、起動速度が改善されます。
web ベースの管理コンソールと管理コマンドラインインターフェース (CLI) により、XML 設定ファイルを編集する必要がなく、タスクをスクリプト化および自動化する機能が追加されます。さらに、JBoss EAP には、セキュアでスケーラブルな Java EE アプリケーションの迅速な開発、デプロイ、および実行を可能にする API と開発フレームワークが含まれています。JBoss EAP 7 は、Java EE 8 full および web プロファイル仕様の認定実装です。
1.2. OpenShift での JBoss EAP の仕組み
Red Hat は、OpenShift と使用するために設計された JBoss EAP のコンテナー化イメージを提供します。このイメージを使用すると、開発者はハイブリッド環境全体にデプロイされたアプリケーションを迅速かつ簡単にビルド、スケール、およびテストできます。
1.3. 比較: JBoss EAP および JBoss EAP for OpenShift
JBoss EAP 製品と JBoss EAP for OpenShift イメージを比較すると、顕著な違いがいくつかあります。以下の表は、これらの違いを説明し、JBoss EAP for OpenShift の現在のバージョンに含まれる機能またはサポートされる機能を示します。
表1.1 JBoss EAP と JBoss EAP for OpenShift の違い
JBoss EAP の機能 | JBoss EAP for OpenShift での状態 | 説明 |
---|---|---|
JBoss EAP 管理コンソール | 含まれない | 本リリースの JBoss EAP for OpenShift には JBoss EAP 管理コンソールは含まれません。 |
JBoss EAP 管理 CLI | 非推奨 | JBoss EAP 管理 CLI は、コンテナー化環境で実行されている JBoss EAP との使用が推奨されません。管理 CLI を使用して実行中のコンテナーで変更した設定内容は、コンテナーの再起動時に失われます。管理 CLI はトラブルシューティングの目的で Pod 内からアクセスできます。 |
管理対象ドメイン | サポート対象外 | JBoss EAP 管理対象ドメインはサポートされませんが、アプリケーションの作成および配布は OpenShift 上のコンテナーで管理されます。 |
デフォルトのルートページ | 無効 |
デフォルトのルートページは無効になっていますが、独自のアプリケーションを |
リモートメッセージング | サポート対象 | inter-Pod およびリモートメッセージングの Red Hat AMQ はサポートされます。ActiveMQ Artemis は、JBoss EAP インスタンスとの単一 Pod 内のメッセージングに対してのみサポートされ、Red Hat AMQ が存在しない場合のみ有効になります。 |
トランザクションリカバリー | 一部サポート対象 | JBoss EAP for OpenShift イメージでトランザクションリカバリーを実行するときに、一部 サポートされないトランザクションリカバリーシナリオおよび警告 があります。 |
1.4. バージョンの互換性とサポート
本ガイドでは、以下の JBoss EAP for OpenShift イメージを取り上げます。
-
jboss-eap-7/eap72-openshift
(JDK 8) -
jboss-eap-7/eap72-openjdk11-openshift-rhel8
(JDK 11)
Red Hat Container Catalog でこれらのイメージの最新タグの情報を確認できます。
Hawkular エージェントは JDK 11 ではアクティブでなく、設定された場合は無視されます。
JBoss EAP for OpenShift は頻繁に更新されます。そのため、イメージのどのバージョンが OpenShift のどのバージョンと互換性があるかを理解することが重要になります。バージョンの互換性とサポートの詳細は、Red Hat カスタマーポータルの「OpenShift Container Platform 3.x のテスト済みインテグレーションを」参照してください。
1.4.1. OpenShift 4.1 サポート
OpenShift 4.1 の変更は Jolokia へのアクセスに影響します。Open Java Console は OpenShift 4.1 Web コンソールで利用できなくなりました。
OpenShift Enterprise Administration (CL280) 以前のリリースの OpenShift では、プロキシー化された特定の kube-apiserver 要求が認証され、クラスターに渡されていました。現在では、この動作は安全ではないと見なされ、サポート対象外になりました。その結果、この方法での Jolokia へのアクセスはサポート対象外になりました。
OpenShift コンソールのコードベースの変更により、Open Java Console へのリンクが利用できなくなりました。
1.5. テクノロジープレビューの機能
自動化トランザクションリカバリー
この機能はテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は本番環境での使用はサポートされず、今後大きな変更がある場合があります。テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジプレビュー機能のサポート範囲」を参照してください。
クラスターがスケールダウンしたとき、トランザクションブランチがインダウトの状態になる可能性があります。JBoss EAP for OpenShift には、このようなブランチを完全にする 自動化トランザクションリカバリー機能 があります。現時点では、この実装の自動化トランザクションリカバリーはテクノロジープレビューとしてのみ提供されます。
アプリケーション Pod のスケールダウンで自動化トランザクションリカバリーを実証するために提供される eap72-tx-recovery-s2i
アプリケーションテンプレートもテクノロジープレビューとしてのみ提供されます。
JDK 11 イメージストリームでは、アプリケーションテンプレートは eap72-openjdk11-tx-recovery-s2i
です。
第2章 JBoss EAP for OpenShift イメージでの Java アプリケーションのビルドおよび実行
以下のワークフローでは、Source-to-Image (S2I) プロセスを使用して JBoss EAP for OpenShift イメージ上で Java アプリケーションをビルドおよび実行します。
たとえば、この手順では kitchensink
クイックスタートが使用されます。これは JSF、CDI、EJB、JPA、および Bean Validation を使用して Java EE の web 対応データベースアプリケーションを実行します。詳細は、JBoss EAP 7 に同梱される kitchensink
クイックスタートを参照してください。
2.1. 要件
このワークフローでは、OpenShift インスタンスがすでにインストールされ、運用されていることを前提とします (OpenShift Primer の OpenShift インスタンスと同様)。
2.2. アプリケーションのデプロイメントに向けた OpenShift の準備
-
oc login
コマンドを使用して、OpenShift インスタンスにログインします。 OpenShift で新しいプロジェクトを作成します。
プロジェクトでは、1 つのユーザーグループが他のグループとは別にコンテンツを整理および管理することができます。以下のコマンドを使用すると OpenShift でプロジェクトを作成できます。
$ oc new-project PROJECT_NAME
たとえば、以下のコマンドを使用して、
kitchensink
クイックスタートでeap-demo
という名前の新規プロジェクトを作成します。$ oc new-project eap-demo
任意の手順: キーストアおよびシークレットを作成します。
注記OpenShift プロジェクトで HTTPS 対応の機能を使用する場合、キーストアとシークレットの作成が必要になります。たとえば、
eap72-https-s2i
テンプレートを使用している場合、キーストアとシークレットを作成する必要があります。kitchensink
クイックスタートのこのワークフローは、HTTPS テンプレートを使用しないため、キーストアとシークレットは必要ありません。キーストアを作成します。
警告以下のコマンドは自己署名証明書を生成しますが、本番環境では信用性が確認された認証局 (CA) から購入した独自の SSL 証明書を SSL で暗号化された接続 (HTTPS) に使用することが推奨されます。
以下のように、Java
keytool
コマンドを使用して、キーストアを生成することができます。$ keytool -genkey -keyalg RSA -alias ALIAS_NAME -keystore KEYSTORE_FILENAME.jks -validity 360 -keysize 2048
たとえば、
kitchensink
クイックスタートでは、以下のコマンドを使用してキーストアを生成します。$ keytool -genkey -keyalg RSA -alias eapdemo-selfsigned -keystore keystore.jks -validity 360 -keysize 2048
キーストアからシークレットを作成します。
以下のコマンドを使用して、作成したキーストアからシークレットを作成します。
$ oc secrets new SECRET_NAME KEYSTORE_FILENAME.jks
たとえば、
kitchensink
クイックスタートでは、以下のコマンドを使用してシークレットを作成します。$ oc secrets new eap7-app-secret keystore.jks
2.3. Red Hat コンテナーレジストリーへの認証の設定
JBoss EAP for OpenShift イメージをインポートおよび使用する前に、最初に Red Hat コンテナーレジストリーへの認証を設定する必要があります。
Red Hat は、レジストリーサービスアカウントを使用して認証トークンを作成し、Red Hat コンテナーレジストリーへのアクセスを設定することを推奨します。こうすると、お持ちの Red Hat アカウントのユーザー名やパスワードを OpenShift 設定に使用または保存する必要がありません。
- Red Hat カスタマーポータルの手順にしたがって、レジストリーサービスアカウントを使用して認証トークンを作成します。
- トークンの OpenShift シークレットが含まれる YAML ファイルをダウンロードします。YAML ファイルは、トークンの Token Information ページの OpenShift Secret タブからダウンロードできます。
ダウンロードした YAML ファイルを使用して、OpenShift プロジェクトの認証トークンシークレットを作成します。
oc create -f 1234567_myserviceaccount-secret.yaml
以下のコマンドを使用して、OpenShift プロジェクトのシークレットを設定します。シークレット名は前のステップで作成したシークレットの名前に置き換えてください。
oc secrets link default 1234567-myserviceaccount-pull-secret --for=pull oc secrets link builder 1234567-myserviceaccount-pull-secret --for=pull
セキュリティー保護されたレジストリーへのアクセス設定方法については、OpenShift ドキュメントを参照してください。
Red Hat コンテナーレジストリーへの認証の設定 に関する詳細は、Red Hat カスタマーポータルを参照してください。
2.4. 最新の JBoss EAP for OpenShift イメージストリームおよびテンプレートのインポート
以下のコマンドを使用して、最新の JBoss EAP for OpenShift のイメージストリームおよびテンプレートを OpenShift プロジェクトの namespace にインポートします。
for resource in \ eap72-image-stream.json \ eap72-amq-persistent-s2i.json \ eap72-amq-s2i.json \ eap72-basic-s2i.json \ eap72-https-s2i.json \ eap72-mongodb-persistent-s2i.json \ eap72-mongodb-s2i.json \ eap72-mysql-persistent-s2i.json \ eap72-mysql-s2i.json \ eap72-postgresql-persistent-s2i.json \ eap72-postgresql-s2i.json \ eap72-third-party-db-s2i.json \ eap72-tx-recovery-s2i.json \ eap72-sso-s2i.json do oc replace --force -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-eap-7-openshift-image/eap72/templates/${resource} done
上記のコマンドを使用してインポートされた JBoss EAP イメージストリームおよびテンプレートは、OpenShift プロジェクト内のみで利用できます。
一般的な openshift
namespace にアクセスできる管理者権限を持っている場合、すべてのプロジェクトがイメージストリームおよびテンプレートにアクセスできるようにするには、コマンドの oc replace
行に -n openshift
を追加します。例を以下に示します。
... oc replace -n openshift --force -f \ ...
2.5. JBoss EAP S2I (Source-to-Image) アプリケーションの OpenShift へのデプロイ
JBoss EAP for OpenShift イメージと Java アプリケーションのソースコードを使用して、新しい OpenShift アプリケーションを作成します。Red Hat は、提供される JBoss EAP for OpenShift テンプレートの 1 つを S2I ビルドに使用することを推奨します。
たとえば、
kitchensink
クイックスタートでは以下のコマンドを使用して、「アプリケーションのデプロイメントに向けた OpenShift の準備
」で GitHub のkitchensink
ソースコードを使用して作成した eap-demo プロジェクトにeap72-basic-s2i
テンプレートを使用します。oc new-app --template=eap72-basic-s2i \1 -p IMAGE_STREAM_NAMESPACE=eap-demo \2 -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \3 -p SOURCE_REPOSITORY_REF=openshift \4 -p CONTEXT_DIR=kitchensink5
注記テンプレートは、多くのテンプレートパラメーターにデフォルト値を指定でき、一部またはすべてのデフォルトをオーバーライドする必要がある場合があります。パラメーターのリストやデフォルト値などのテンプレートの情報を表示するには、コマンド
oc describe template TEMPLATE_NAME
を使用します。注記新しい OpenShift アプリケーションを作成するときに、環境変数を設定 することもあります。
たとえば、
eap72-https-s2i
などの HTTPS テンプレートを使用している場合は、必要な HTTPS 環境変数 であるHTTPS_NAME
、HTTPS_PASSWORD
、およびHTTPS_KEYSTORE
を指定し、キーストアの詳細と一致するようにする必要があります。ビルド設定の名前を取得します。
$ oc get bc -o name
取得したビルド設定の名前を使用し、Maven のビルドの進捗を表示します。
$ oc logs -f buildconfig/BUILD_CONFIG_NAME
たとえば、
kitchensink
クイックスタートでは、以下のコマンドで Maven ビルドの進捗を表示します。$ oc logs -f buildconfig/eap-app
2.6. デプロイメント後のタスク
アプリケーションによっては、OpenShift アプリケーションのビルドおよびデプロイ後に一部のタスクを実行する必要が場合があります。これには、サービスを公開して OpenShift の外部からアプリケーションを閲覧可能にする作業や、アプリケーションを特定数のレプリカにスケーリングする作業などが含まれることがあります。
以下のコマンドを使用してアプリケーションのサービス名を取得します。
$ oc get service
メインサービスをルートとして公開し、OpenShift 外部からアプリケーションにアクセスできるようにします。たとえば、
kitchensink
クイックスタートでは、以下のコマンドを使用して必要なサービスとポートを公開します。$ oc expose service/eap-app --port=8080
注記テンプレートを使用してアプリケーションを作成した場合は、ルートがすでに存在することがあります。存在する場合は次のステップに進みます。
ルートの URL を取得します。
$ oc get route
この URL を使用して web ブラウザーでアプリケーションにアクセスします。URL は前のコマンド出力にある
HOST/PORT
フィールドの値になります。アプリケーションが JBoss EAP ルートコンテキストを使用しない場合、アプリケーションのコンテキストを URL に追加します。たとえば、
kitchensink
クイックスタートでは、URL はhttp://HOST_PORT_VALUE/kitchensink/
のようになります。任意で、以下のコマンドを実行してアプリケーションインスタンスをスケールアップすることもできます。これは、レプリカの数を
3
に増やします。$ oc scale deploymentconfig DEPLOYMENTCONFIG_NAME --replicas=3
たとえば、
kitchensink
クイックスタートでは、以下のコマンドを使用してアプリケーションをスケールアップします。$ oc scale deploymentconfig eap-app --replicas=3
第3章 Java アプリケーションに対して JBoss EAP for OpenShift イメージを設定
JBoss EAP for OpenShift のイメージは、Java アプリケーションとの基本的な使用に対して事前設定されています。しかし、JBoss EAP インスタンスをイメージ内部で設定できます。OpenShift S2I プロセスをアプリケーションテンプレートパラメーターと環境変数とともに使用する方法が推奨されます。
コンテナーが再起動または終了すると、実行中のコンテナーで変更された設定内容はすべて失われます。
これには、add-user.sh
や管理 CLI などの、従来の JBoss EAP インストールに含まれるスクリプトを使用して変更された設定が含まれます。
OpenShift S2I プロセスをアプリケーションテンプレートパラメーターと環境変数とともに使用して、JBoss EAP for OpenShift イメージ内部の JBoss EAP インスタンスの設定を変更することが強く推奨されます。
3.1. JBoss EAP for OpenShift の S2I プロセスの仕組み
変数 EAP_HOME
を使用して、JBoss EAP for OpenShift イメージ内部の JBoss EAP インストールへのパスを示します。
JBoss EAP for OpenShift の S2I プロセスは以下のように動作します。
pom.xml
ファイルがソースコードリポジトリーに存在する場合、Maven のビルドプロセスは$MAVEN_ARGS
環境変数のコンテンツを使用するようトリガーされます。$MAVEN_ARGS
環境変数でカスタム Maven 引数またはオプションを指定することは可能ですが、Red Hat は$MAVEN_ARGS_APPEND
環境変数を使用して指定することを推奨します。$MAVEN_ARGS_APPEND
変数は$MAVEN_ARGS
からデフォルトの引数を取り、$MAVEN_ARGS_APPEND
からのオプションを追加します。デフォルトでは、OpenShift プロファイルは Maven の
package
ゴールを使用します。 これには、テストをスキップするシステムプロパティー (-DskipTests
) や Red Hat GA リポジトリーを有効にするシステムプロパティー (-Dcom.redhat.xpaas.repo
) が含まれます。注記JBoss EAP for OpenShift イメージのプロキシーの背後で Maven を使用するには、
$HTTP_PROXY_HOST
および$HTTP_PROXY_PORT
環境変数を設定します。任意で、$HTTP_PROXY_USERNAME
、HTTP_PROXY_PASSWORD
、およびHTTP_PROXY_NONPROXYHOSTS
変数を設定することもできます。-
成功した Maven ビルドの結果は、JBoss EAP for OpenShift イメージ内の
EAP_HOME/standalone/deployments/
ディレクトリーにコピーされます。これには、$ARTIFACT_DIR
環境変数によって指定されたソースリポジトリーからの JAR、WAR、および EAR ファイルがすべて含まれます。$ARTIFACT_DIR
のデフォルト値は Maven のターゲットディレクトリーです。 -
configuration
ソースリポジトリーディレクトリーのすべてのファイルは、JBoss EAP for OpenShift イメージ内のEAP_HOME/standalone/configuration/
ディレクトリーにコピーされます。カスタムの JBoss EAP 設定ファイルを使用する場合、ファイル名をstandalone-openshift.xml
にする必要があります。 -
modules
ソースリポジトリーディレクトリーのすべてのファイルは、JBoss EAP for OpenShift イメージ内のEAP_HOME/modules/
ディレクトリーにコピーされます。
S2I プロセスを指示してカスタム Maven アーティファクトリポジトリーミラーを利用する方法の追加情報は「アーティファクトリポジトリーミラー」を参照してください。
3.2. 環境変数を使用した JBoss EAP for OpenShift の設定
JBoss EAP for OpenShift イメージを設定する方法として、環境変数の使用が推奨されます。アプリケーションコンテナーおよびビルドコンテナーに 環境変数を指定 する方法については、OpenShift ドキュメントを参照してください。
たとえば、OpenShift アプリケーションの作成時に、環境変数を使用して JBoss EAP インスタンスの管理ユーザー名およびパスワードを設定することができます。
oc new-app --template=eap72-basic-s2i \ -p IMAGE_STREAM_NAMESPACE=eap-demo \ -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \ -p SOURCE_REPOSITORY_REF=openshift \ -p CONTEXT_DIR=kitchensink \ -e ADMIN_USERNAME=myspecialuser \ -e ADMIN_PASSWORD=myspecialp@ssw0rd
JBoss EAP for OpenShift イメージの利用可能な環境変数は、「参考情報」のリストを参照してください。
3.3. ビルド拡張およびプロジェクトアーティファクト
JBoss EAP for OpenShift イメージは、さまざまなアーティファクトを使用して OpenShift のデータベースサポートを拡張します。これらのアーティファクトは異なるメカニズムを介してビルドイメージに含まれます。
- S2I プロセスの間にイメージにインジェクトされる S2I アーティファクト。
- OpenShift シークレットメカニズムを介して提供される環境ファイルからの ランタイムアーティファクト。
Red Hat が提供する内部データソースドライバーを JBoss EAP for OpenShift イメージと使用する場合のサポートは、JDK 8 イメージストリームでは非推奨になりました。データベースベンダーから取得した JDBC ドライバーを JBoss EAP アプリケーションに使用することが推奨されます。
以下の内部データソースは、JBoss EAP for OpenShift の JDK 11 イメージでは提供されないようになりました。
- MySQL
- PostgreSQL
ドライバーのインストールに関する詳細は、「モジュール、ドライバー、および汎用デプロイメント」を参照してください。
JBoss EAP で JDBC ドライバーを設定するための詳細は、『設定ガイド』の「JDBC ドライバー」を参照してください。
3.3.1. S2I アーティファクト
S2I アーティファクトには、モジュール、ドライバー、およびデプロイメントに必要な設定インフラストラクチャーを提供する追加の汎用デプロイメントが含まれます。この設定は S2I プロセスの間にイメージに組み込まれるため、データソースと関連するリソースアダプターのみをランタイムに設定する必要があります。
S2I プロセスを指示してカスタム Maven アーティファクトリポジトリーミラーを利用する方法の追加情報は「アーティファクトリポジトリーミラー」を参照してください。
3.3.1.1. モジュール、ドライバー、および汎用デプロイメント
JBoss EAP for OpenShift イメージにこれらの S2I アーティファクトが含まれるようにする方法はいくつかあります。
- アプリケーションソースデプロイメントディレクトリーにアーティファクトが含まれるようにします。アーティファクトはビルド中にダウンロードされ、イメージにインジェクトされます。これは、JBoss EAP for OpenShift イメージでアプリケーションをデプロイするのと似ています。
CUSTOM_INSTALL_DIRECTORIES
環境変数が含まれるようにします。これは、S2I プロセス中にイメージのアーティファクトのインストールおよび設定に使用されるディレクトリーのコンマ区切りリストです。S2I プロセスにこの情報が含まれるようにする方法は 2 つあります。指定されたインストールディレクトリーの
install.sh
スクリプト。インストールスクリプトは S2I プロセス中に実行され、問題なく動作します。install.sh
スクリプトの例#!/bin/bash injected_dir=$1 source /usr/local/s2i/install-common.sh install_deployments ${injected_dir}/injected-deployments.war install_modules ${injected_dir}/modules configure_drivers ${injected_dir}/drivers.env
install.sh
スクリプトの役割は、install-common.sh
によって提供される API を使用してベースイメージをカスタマイズすることです。install-common.sh
には、モジュール、ドライバー、および汎用デプロイメントをインストールおよび設定するためにinstall.sh
スクリプトによって使用される関数が含まれます。install-common.sh
内に含まれる関数は次のとおりです。-
install_modules
-
configure_drivers
install_deployments
モジュール
モジュールは、クラスローディングおよび依存関係管理に使用されるクラスの論理グループです。モジュールは、アプリケーションサーバーの
EAP_HOME/modules/
ディレクトリーに定義されます。各モジュールは、EAP_HOME/modules/org/apache/
のようにサブディレクトリーとして存在します。各モジュールのディレクトリーには、デフォルトが main であるスロットサブディレクトリーが含まれ、module.xml
設定ファイルと必要な JAR ファイルすべてが含まれます。MySQL および PostgreSQL JDBC ドライバーの
module.xml
ファイルの設定に関する詳細は、JBoss EAP『設定ガイド』の「データソース設定の例」を参照してください。module.xml
ファイルの例<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="org.apache.derby"> <resources> <resource-root path="derby-10.12.1.1.jar"/> <resource-root path="derbyclient-10.12.1.1.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
PostgreSQL データソースの
module.xml
ファイルの例<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="org.postgresql"> <resources> <resource-root path="postgresql-jdbc.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
MySQL Connect/J 8 データソースの
module.xml
ファイルの例<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-8.0.Z.jar" /> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
注記mysql-connector-java-8.0.Z.jar
の「.Z」はダウンロードしたJAR
ファイルのバージョンを示します。ファイル名は変更できますが、名前はmodule.xml
ファイルの名前に一致する必要があります。install.sh
のinstall_modules
関数は、module.xml
とともに該当の JAR ファイルを JBoss EAP の modules ディレクトリーにコピーします。ドライバー
ドライバーはモジュールとしてインストールされます。ドライバーは
configure_drivers
関数によってinstall.sh
に設定されます。 この設定プロパティーは ランタイムアーティファクト 環境ファイルに定義されます。drivers.env
ファイルの例#DRIVER DRIVERS=DERBY DERBY_DRIVER_NAME=derby DERBY_DRIVER_MODULE=org.apache.derby DERBY_DRIVER_CLASS=org.apache.derby.jdbc.EmbeddedDriver DERBY_XA_DATASOURCE_CLASS=org.apache.derby.jdbc.EmbeddedXADataSource
内部データソースドライバーの追加
MySQL および PostgreSQL データソースは、事前に設定された内部データソースとして提供されなくなりました。ただし、これらのドライバーは、「モジュール、ドライバー、および汎用デプロイメント」で説明されているように、モジュールとしてインストールすることができます。
メカニズムは
Derby
ドライバーの例にならい、S2I アーティファクトを使用します。インストールする各データソースのdrivers.env
ファイルを作成します。MySQL データソースの
drivers.env
ファイルの例#DRIVER DRIVERS=MYSQL MYSQL_DRIVER_NAME=mysql MYSQL_DRIVER_MODULE=org.mysql MYSQL_DRIVER_CLASS=com.mysql.cj.jdbc.Driver MYSQL_XA_DATASOURCE_CLASS=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
PostgreSQL データソースの
drivers.env
ファイルの例#DRIVER DRIVERS=POSTGRES POSTGRES_DRIVER_NAME=postgres POSTGRES_DRIVER_MODULE=org.postgresql POSTGRES_DRIVER_CLASS=org.postgresql.Driver POSTGRES_XA_DATASOURCE_CLASS=org.postgresql.xa.PGXADataSource
MySQL や PostgreSQL など、さまざまなドライバーのダウンロード場所に関する情報は、『設定ガイド』の「 JDBC ドライバーのダウンロード場所 」を参照してください。
-
汎用デプロイメント
JAR、WAR、RAR、EAR などのデプロイ可能なアーカイブファイルは、install-common.sh
の API によって提供される install_deployments
を使用して、インジェクトされたイメージからデプロイすることができます。
CUSTOM_INSTALL_DIRECTORIES
環境変数が宣言されていても、カスタムインストールディレクトリーにinstall.sh
スクリプトがない場合、以下のアーティファクトディレクトリーがビルドイメージの該当する場所にコピーされます。-
modules/*
は$JBOSS_HOME/modules/system/layers/openshift
にコピーされます。 -
configuration/*
は$JBOSS_HOME/standalone/configuration
にコピーされます。 -
deployments/*
は$JBOSS_HOME/standalone/deployments
にコピーされます。
これは
install.sh
の代替方法と比べ基本的な設定方法となります。 アーティファクトが適切に構築される必要があります。-
3.3.2. ランタイムアーティファクト
3.3.2.1. データソース
データソースの種類は 3 つあります。
- デフォルトの内部データソース。これらは PostgreSQL、MySQL、および MongoDB になります。これらのデータソースは、Red Hat レジストリー介して OpenShift ではデフォルトで利用でき、JDK 8 イメージストリームに追加の環境ファイルを設定する必要がありません。DB_SERVICE_PREFIX_MAPPING 環境変数を、検出してデータソースとして使用する OpenShift サービスの名前に設定します。
- その他の内部データソース。これらは、Red Hat レジストリーを介してデフォルトでは利用できない、OpenShift 上で実行されるデータソースです。これらのデータソースの設定は、OpenShift のシークレットに追加された環境ファイルによって提供されます。
- OpenShift 上では実行されない外部データソース。外部データソースの設定は、OpenShift のシークレットに追加された環境ファイルによって提供されます。
例: データソース環境ファイル
# derby datasource ACCOUNTS_DERBY_DATABASE=accounts ACCOUNTS_DERBY_JNDI=java:/accounts-ds ACCOUNTS_DERBY_DRIVER=derby ACCOUNTS_DERBY_USERNAME=derby ACCOUNTS_DERBY_PASSWORD=derby ACCOUNTS_DERBY_TX_ISOLATION=TRANSACTION_READ_UNCOMMITTED ACCOUNTS_DERBY_JTA=true # Connection info for xa datasource ACCOUNTS_DERBY_XA_CONNECTION_PROPERTY_DatabaseName=/home/jboss/source/data/databases/derby/accounts # _HOST and _PORT are required, but not used ACCOUNTS_DERBY_SERVICE_HOST=dummy ACCOUNTS_DERBY_SERVICE_PORT=1527
DATASOURCES
プロパティーは、データソースプロパティー接頭辞のコンマ区切りリストです。これらの接頭辞は、データソースのすべてのプロパティーに追加されます。複数のデータソースを 1 つの環境ファイルに含むことができます。また、各データソースを個別の環境ファイルに提供することもできます。
データソースには、接続プール固有のプロパティーとデータベースドライバー固有のプロパティーの 2 種類のプロパティーが含まれます。データベースドライバー固有のプロパティーは、ドライバー自体がドライバー S2I アーティファクトとして設定されるため、汎用の XA_CONNECTION_PROPERTY
を使用します。ドライバープロパティーの接尾辞は、データソースの特定のドライバーに固有します。
上記の例では、ACCOUNTS
はデータソース接頭辞、XA_CONNECTION_PROPERTY
は汎用ドライバープロパティー、DatabaseName
はドライバー固有のプロパティーになります。
データソース環境ファイルは、プロジェクトの OpenShift シークレットに追加されます。これらの環境ファイルは、ENV_FILES
環境プロパティーを使用して、テンプレート内で呼び出されます。 この環境プロパティーの値は、以下のような完全修飾環境ファイルのコンマ区切りリストです。
{ “Name”: “ENV_FILES”, “Value”: “/etc/extensions/datasources1.env,/etc/extensions/datasources2.env” }
3.3.2.2. リソースアダプター
リソースアダプターの設定は、OpenShift のシークレットに追加された環境ファイルによって提供されます。
表3.1 リソースアダプタープロパティー
属性 | 説明 |
---|---|
PREFIX_ID | サーバー設定ファイルに指定されたリソースアダプターの識別子。 |
PREFIX_ARCHIVE | リソースアダプターアーカイブ。 |
PREFIX_MODULE_SLOT |
|
PREFIX_MODULE_ID | オブジェクトファクトリー Java クラスをロードできる JBoss モジュール ID。 |
PREFIX_CONNECTION_CLASS | 管理された接続ファクトリーまたは管理オブジェクトの完全修飾クラス名。 |
PREFIX_CONNECTION_JNDI | 接続ファクトリーの JNDI 名。 |
PREFIX_PROPERTY_ParentDirectory | データファイルが格納されるディレクトリー。 |
PREFIX_PROPERTY_AllowParentPaths |
|
PREFIX_POOL_MAX_SIZE | プールの最大接続数。各サブプールではこの値を超える接続は作成されません。 |
PREFIX_POOL_MIN_SIZE | プールの最小接続数。 |
PREFIX_POOL_PREFILL | プールをプレフィルすべきかどうかを指定します。値の変更後にサーバーを再起動する必要があります。 |
PREFIX_POOL_FLUSH_STRATEGY |
エラーの場合にプールがどのようにフラッシュされるか。有効な値は |
RESOURCE_ADAPTERS
プロパティーは、リソースアダプタープロパティー接頭辞のコンマ区切りリストです。接頭辞はそのリソースアダプターのすべてのプロパティーに追加されます。複数のリソースアダプターを 1 つの環境ファイルに含めることができます。以下の例では、MYRA
がリソースアダプターの接尾辞として使用されます。各リソースアダプターを個別の環境ファイルに提供することもできます。
例: リソースアダプター環境ファイル
#RESOURCE_ADAPTER RESOURCE_ADAPTERS=MYRA MYRA_ID=myra MYRA_ARCHIVE=myra.rar MYRA_CONNECTION_CLASS=org.javaee7.jca.connector.simple.connector.outbound.MyManagedConnectionFactory MYRA_CONNECTION_JNDI=java:/eis/MySimpleMFC
リソースアダプター環境ファイルは、プロジェクト namespace の OpenShift シークレットに追加されます。これらの環境ファイルは、ENV_FILES
環境プロパティーを使用して、テンプレート内で呼び出されます。 この環境プロパティーの値は、以下のような完全修飾環境ファイルのコンマ区切りリストです。
{ "Name": "ENV_FILES", "Value": "/etc/extensions/resourceadapter1.env,/etc/extensions/resourceadapter2.env" }
3.4. JBoss EAP for OpenShift イメージのデプロイメントに関する考慮事項
3.4.1. スケールアップおよび永続ストレージのパーティショニング
永続ストレージを用いて JBoss EAP をデプロイする方法は、単一ノードのパーティショニングと複数ノードのパーティショニングの 2 つがあります。
単一ノードのパーティショニングは、トランザクションデータを含む JBoss EAP データストアディレクトリーをストレージボリュームに格納します。
複数ノードのパーティショニングは、追加の独立した split-n
ディレクトリーを作成し、各 JBoss EAP Pod のトランザクションデータを格納します。n
は、増分整数です。JBoss EAP Pod が更新された場合、予期せず停止した場合、または再デプロイされた場合、この通信は変更されません。JBoss EAP Pod が再度操作可能になると、関連する split ディレクトリーに再接続し、以前と同様に続行されます。新しい JBoss EAP Pod が追加されると、対応する split-n
ディレクトリーがその Pod に作成されます。
複数ノードの設定を有効にするには、SPLIT_DATA
パラメーターを true
に設定する必要があります。これにより、データストアとして使用される永続ボリューム内の各インスタンスに対して、サーバーが独立した split-n
ディレクトリーを作成します。
現在、これが eap72-tx-recovery-s2i
テンプレートのデフォルト設定です。
単一ノードと複数ノードのパーティショニングではストレージの方法が異なるため、デプロイメントを単一ノードから複数ノードに変更すると、data ディレクトリーにこれまで保存されたすべてのデータ (メッセージやトランザクションログを含む) がアプリケーションから失われます。ストレージパスが一致しないため、デプロイメントを複数ノードから単一ノードに変更した場合でも同様です。
3.4.2. スケールダウンおよびトランザクションリカバリー
JBoss EAP for OpenShift イメージが 複数ノード 設定を使用してデプロイされると、クラスターがスケールダウンした場合に、終了する Pod の data ディレクトリーに予期せず終了されたトランザクションが残される可能性があります。
クラスターが次回スケールアップするまで、終了する Pod のデータストア内にトランザクションが残らないようにするため、eap72-tx-recovery-s2i
JBoss EAP テンプレートは、トランザクションの移行を管理するマイグレーション Pod が含まれる 2 つ目のデプロイメントを作成します。マイグレーション Pod は、JBoss EAP 永続ボリューム内の独立した各 split-n
ディレクトリーをスキャンし、終了する Pod と関連するデータストアを特定し、終了する Pod のすべてのトランザクションが完了するまで実行を継続します。
永続ボリュームは JBoss EAP アプリケーション Pod と移行 Pod の両方によって読み書きモードでアクセスする必要があるため、ReadWriteMany
アクセスモードで作成する必要があります。このアクセスモードは、GlusterFS
および NFS
プラグインを使用する永続ボリュームでのみサポートされています。詳細は、永続ボリュームのサポート対象アクセスモード表を参照してください。
詳細情報は、クラスターをスケールダウンするときの JBoss EAP for OpenShift イメージの自動化トランザクションリカバリー機能を実行する「ワークフローの例: クラスターをスケールダウンするときの自動化トランザクションリカバリー機能」を参照してください。
第4章 JBoss EAP for OpenShift の JDK 11 イメージへの移行
4.1. JDK 11 イメージを使用したアプリケーションのデプロイメントに向けた OpenShift の準備
JDK 11 イメージを使用してアプリケーションのデプロイメントに向けて OpenShift を準備するには、「アプリケーションのデプロイメントに向けた OpenShift の準備」と同じ手順にしたがいます。
4.2. JDK 11 イメージのインポート
以下のコマンドを使用して、JBoss EAP for OpenShift の JDK 11 イメージストリームおよびテンプレートを OpenShift プロジェクトの namespace にインポートします。
for resource in \ eap72-openjdk11-image-stream.json \ eap72-openjdk11-amq-persistent-s2i.json \ eap72-openjdk11-amq-s2i.json \ eap72-openjdk11-basic-s2i.json \ eap72-openjdk11-https-s2i.json \ eap72-openjdk11-sso-s2i.json \ eap72-openjdk11-starter-s2i.json \ eap72-openjdk11-third-party-db-s2i.json \ eap72-openjdk11-tx-recovery-s2i.json do oc replace --force -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-eap-7-openshift-image/eap72-openjdk11-ubi8/templates/${resource} done
以下の内部データソースおよびドライバーは、JBoss EAP for OpenShift の JDK 11 イメージとは提供されません。
- MySQL
- PostgreSQL
- MongoDB
データベースベンダーから取得した JDBC ドライバーを JBoss EAP アプリケーションに使用することが推奨されます。
ドライバーのインストールに関する詳細は、「モジュール、ドライバー、および汎用デプロイメント」を参照してください。
4.3. JDK 11 イメージを使用した JBoss EAP S2I アプリケーションの OpenShift へのデプロイ
JBoss EAP の S2I アプリケーションを OpenShift にデプロイするには、「JBoss EAP S2I (Source-to-Image) アプリケーションの OpenShift へのデプロイ」と同じ手順にしたがいます。
JDK 11 ストリームは、JDK 8 で使用される eap72-basic-s2i
テンプレートの代わりに eap72-openjdk11-basic-s2i
を S2I ビルドに使用します。
kitchensink
クイックスタートをデプロイするには、以下のコマンドを使用して eap72-openjdk11-basic-s2i
テンプレートを GitHub の kitchensink
ソースコードと使用します。
oc new-app --template=eap72-openjdk11-basic-s2i \ -p IMAGE_STREAM_NAMESPACE=eap-demo \ -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts.git \ -p SOURCE_REPOSITORY_REF=openshift \ -p CONTEXT_DIR=kitchensink \
eap-demo
プロジェクトの eap72-openjdk11-basic-s2i
テンプレートは「アプリケーションのデプロイメントに向けた OpenShift の準備」で作成済みです。
4.4. JDK 11 イメージに環境変数を使用した JBoss EAP for OpenShift の設定
JDK 11 イメージに環境変数を使用して JBoss EAP for OpenShift を設定するには、「環境変数を使用した JBoss EAP for OpenShift の設定」と同じ手順にしたがいます。
JDK 11 イメージストリームは、JDK 8 で使用される eap72-basic-s2i
テンプレートの代わりに eap72-openjdk11-basic-s2i
テンプレートを使用します。
環境変数を使用して JBoss EAP インスタンスの管理ユーザー名およびパスワードを設定するには、OpenShift アプリケーションの作成時に以下のコマンドを使用します。
oc new-app --template=eap72-openjdk11-basic-s2i \ -p IMAGE_STREAM_NAMESPACE=eap-demo \ -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \ -p SOURCE_REPOSITORY_REF=openshift \ -p CONTEXT_DIR=kitchensink \ -e ADMIN_USERNAME=myspecialuser \ -e ADMIN_PASSWORD=myspecialp@ssw0rd
第5章 アプリケーションの OpenShift 4 への移行
5.1. OpenShift 4 の Liveness および Readiness プローブ設定の更新
プローブの YAML
設定は、OpenShift 4 に移行する際に調整される必要があります。
OpenShift 3.11 では、Liveness プローブのデフォルト YAML
設定は以下のコードの例に似ています。
OpenShift 3.11 liveness プローブの YAML
設定サンプル
livenessProbe: exec: command: - /bin/bash - '-c' - /opt/eap/bin/livenessProbe.sh initialDelaySeconds: 60 periodSeconds: 10 successThreshold: 1 failureThreshold: 3
この例では、Liveness プローブは JBoss EAP イメージ内の /opt/eap/bin/livenessProbe.sh
にあります。プローブは、60 秒の最初の遅延後にトリガーされ、JBoss EAP サーバーで Pod が開始された後は 10 秒ごとにトリガーされます。
プローブは、livenessProbe.sh
スクリプトの呼び出し試行が 3 回行われると失敗とみなされます。コンテナーは正常ではないとみなされ、OpenShift はそれぞれの Pod で JBoss EAP コンテナーを再起動します。
OpenShift 3.11 では、成功または失敗が決まるまで、1 回の呼び出しが 5 秒間続きます。OpenShift 4 では、1 回の呼び出しが 1 秒未満になります。
OpenShift 3.11 では、プローブの呼び出しが 5 秒間続き、10 秒間待機します。つまり、JBoss EAP イメージが正常ではない場合、Pod 内のコンテナーが再起動するまで、3 回にわたる呼び出しが約 35 秒間続きます。
OpenShift 4、3 では、呼び出しが 23 秒間続きます。OpenShift 4 のプローブの設定は、以下のように YAML
設定で調整する必要があります。
OpenShift 4 liveness プローブの YAML
設定サンプル
livenessProbe: exec: command: - /bin/bash - '-c' - /opt/eap/bin/livenessProbe.sh initialDelaySeconds: 60 periodSeconds: 16 successThreshold: 1 failureThreshold: 3
この例では、periodSeconds
が 6 秒分増えています。これにより、最初の呼び出しが 1 秒続き、16 秒間にわたり待機します。3 回の呼び出しは、プローブの OpenShift 3.11 の動作とほぼ同等で 約 34 秒続きます。
Readiness プローブの場合、同様の調整を YAML
設定に対して行う必要があります。
OpenShift 4 Readiness プローブの YAML
設定サンプル
readinessProbe: exec: command: - /bin/bash - '-c' - /opt/eap/bin/readinessProbe.sh initialDelaySeconds: 10 periodSeconds: 16 successThreshold: 1 failureThreshold: 3
その他のリソース
第6章 トラブルシューティング
6.1. Pod 再起動のトラブルシューティング
Pod は、さまざまな理由で再起動します。しかし、JBoss EAP Pod の再起動の一般的な原因には OpenShift リソース制約 (特にメモリー不足の問題) が含まれる場合があります。OpenShift Pod エビクションの詳細は、OpenShift ドキュメントを参照してくださeい。
デフォルトでは、JBoss EAP for OpenShift テンプレートは、メモリー不足などの問題が発生すると影響を受けるコンテナーを自動的に再起動するよう設定されています。以下の手順は、メモリー不足やその他の Pod 再起動の問題を診断し、トラブルシューティングを行うのに役立ちます。
問題のある Pod の名前を取得します。
以下のコマンドを使用すると、Pod の名前と、各 Pod が再起動した回数を確認することができます。
$ oc get pods
Pod が再起動した理由を診断するには、前の Pod の JBoss EAP ログまたは OpenShift イベントを調べます。
前の Pod の JBoss EAP ログを表示するには、以下のコマンドを使用します。
oc logs --previous POD_NAME
OpenShift イベントを表示するには、以下のコマンドを使用します。
$ oc get events
- リソースの問題により Pod が再起動される場合は、OpenShift Pod 設定を変更して、その リソース要求および制限を引き上げることができます。Pod コンピュートリソースの設定についての詳細は、OpenShift ドキュメントを参照してください。
6.2. JBoss EAP 管理 CLI を使用したトラブルシューティング
JBoss EAP 管理コンソールである EAP_HOME/bin/jboss-cli.sh
は、トラブルシューティングの目的でコンテナー内からアクセスすることができます。
JBoss EAP 管理 CLI を使用して、実行中の Pod の設定を変更することは推奨されません。管理 CLI を使用して実行中のコンテナーで変更した設定内容は、コンテナーの再起動時に失われます。
JBoss EAP for OpenShift の設定を変更する場合は「Java アプリケーションに対して JBoss EAP for OpenShift イメージを設定」を参照してください。
最初に、実行中の Pod にリモートシェルセッションを開きます。
$ oc rsh POD_NAME
リモートシェルセッションから以下のコマンドを実行し、JBoss EAP 管理 CLI を起動します。
$ /opt/eap/bin/jboss-cli.sh
第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 がトランザクションリカバリーを実行し、トランザクションが正常に完了したことを示しています。
第8章 参考情報
本セクションの内容は、このイメージの技術文書を参考にしました。開発の目的で便利なリファレンスとして提供され、製品ドキュメントの範囲外となるテスト用に提供されます。
8.1. 永続テンプレート
JBoss EAP およびデータベース Pod をデプロイする JBoss EAP データベーステンプレートは、一時的なものと永続的なものの両方があります。
永続テンプレートには、永続ボリュームクレームのプロビジョニングを行う環境変数が含まれます。これは、JBoss EAP for OpenShift デプロイメントのストレージボリュームとして使用される利用可能な永続ボリュームとバインドします。タイマースキーマ、ログ処理、またはデータ更新などの情報は、一時的なコンテナーメモリーではなく、ストレージボリュームに保存されます。この情報は、プロジェクトのアップグレード、デプロイメントのロールバック、予期せぬエラーなどの何らかの理由で Pod がダウンした場合に永続します。
デプロイメントの永続ストレージボリュームがないと、この情報はコンテナーメモリーのみに格納され、何らかの理由で Pod がダウンした場合は失われます。
たとえば、永続ストレージが基盤となる EE タイマーは Pod が再起動しても実行を継続します。再起動のプロセス中にタイマーによってトリガーされたイベントは、アプリケーションが再度稼働したとき実行されます。
逆に、EE タイマーがコンテナーメモリーで稼働している場合、Pod が再起動するとタイマーの状態は失われ、Pod が再度稼働したときに最初から開始します。
8.2. 情報環境変数
以下の環境変数は、イメージに情報を提供するための環境変数であり、ユーザーが変更すべきではありません。
表8.1 情報環境変数
変数名 | 説明および値 |
---|---|
JBOSS_IMAGE_NAME | イメージ名
値: |
JBOSS_IMAGE_RELEASE | イメージリリースラベル。
値: |
JBOSS_IMAGE_VERSION | イメージバージョン。 値: イメージバージョン番号になります。最新の値は Red Hat Container Catalog を参照してください。 |
JBOSS_MODULES_SYSTEM_PKGS | アプリケーションが利用できる JBoss EAP システムモジュールパッケージのコンマ区切りリスト。
値: |
STI_BUILDER |
値: |
8.3. 設定環境変数
以下の環境変数を設定すると再ビルドせずにイメージを調整することができます。
表8.2 設定環境変数
変数名 | 説明 |
---|---|
AB_JOLOKIA_AUTH_OPENSHIFT |
OpenShift TLS 通信のクライアント認証を切り替えます。このパラメーターの値は
|
AB_JOLOKIA_CONFIG | 設定した場合、Jolokia リファレンスドキュメント に説明があるように、この完全修飾ファイルパスを Jolokia JVM エージェントプロパティーに使用します。独自の Jolokia プロパティー設定ファイルを設定した場合、このドキュメントの残りの Jolokia 設定は無視されます。
設定しない場合、Jolokia リファレンスドキュメントに定義された設定を使用して、
値の例: |
AB_JOLOKIA_DISCOVERY_ENABLED | Jolokia の検索を有効にします。
デフォルトは |
AB_JOLOKIA_HOST | バインド先のホストアドレス。
デフォルトは
値の例: |
AB_JOLOKIA_HTTPS | HTTPS を使用したセキュアな通信を有効にします。
デフォルトでは、
値の例: |
AB_JOLOKIA_ID | 使用するエージェント ID。
デフォルト値はコンテナー ID の
値の例: |
AB_JOLOKIA_OFF |
Jolokia はデフォルトで有効になります。 |
AB_JOLOKIA_OPTS |
エージェント設定に追加されるその他のオプション。
値の例: |
AB_JOLOKIA_PASSWORD | Basic 認証のパスワード。 デフォルトでは認証は無効になっています。
値の例: |
AB_JOLOKIA_PASSWORD_RANDOM |
パスワードを無作為に生成する場合は |
AB_JOLOKIA_PORT | リッスンするポート。
デフォルトは
値の例: |
AB_JOLOKIA_USER | Basic 認証に使用するユーザーの名前。
デフォルトは
値の例: |
CLI_GRACEFUL_SHUTDOWN |
ゼロでない長さの値が設定された場合、イメージは
値の例: |
CONTAINER_HEAP_PERCENT | 最大 Java ヒープサイズを利用可能なコンテナーメモリーの割合 (パーセント) として設定します。
値の例: |
CUSTOM_INSTALL_DIRECTORIES | S2I プロセス中にイメージのアーティファクトのインストールおよび設定に使用されるディレクトリーのコンマ区切りリスト。
値の例: |
DEFAULT_JMS_CONNECTION_FACTORY |
この値は、JMS 接続ファクトリーのデフォルトの JNDI バインディングを指定するために使用されます (例:
値の例: |
ENABLE_ACCESS_LOG | 標準出力チャネルへのアクセスメッセージのロギングを有効にします。 アクセスメッセージのロギングは以下の方法を使用して実装されます。
デフォルトは |
INITIAL_HEAP_PERCENT | 初期 Java ヒープサイズを最大ヒープサイズの割合 (パーセント) として設定します。
値の例: |
JAVA_OPTS_APPEND | サーバー起動オプション。
値の例: |
JBOSS_MODULES_SYSTEM_PKGS_APPEND |
値の例: |
JGROUPS_CLUSTER_PASSWORD |
JGroups クラスターへの参加を許可するため、ノードの認証に使用されるパスワード。
値の例: |
JGROUPS_ENCRYPT_KEYSTORE |
値の例: |
JGROUPS_ENCRYPT_KEYSTORE_DIR |
値の例: |
JGROUPS_ENCRYPT_NAME |
値の例: |
JGROUPS_ENCRYPT_PASSWORD |
値の例: |
JGROUPS_ENCRYPT_PROTOCOL |
クラスタートラフィックの暗号化に使用する JGroups プロトコル。
デフォルトは
値の例: |
JGROUPS_ENCRYPT_SECRET |
値の例: |
JGROUPS_PING_PROTOCOL |
ノードの検索に使用する JGroups プロトコル。 |
MQ_SIMPLE_DEFAULT_PHYSICAL_DESTINATION |
後方互換性を維持するには、 |
OPENSHIFT_DNS_PING_SERVICE_NAME | DNS 検索メカニズムに対してサーバーで ping ポートを公開するサービスの名前。
値の例: |
OPENSHIFT_DNS_PING_SERVICE_PORT |
DNS 検索メカニズムの ping ポートのポート番号。指定のない場合は、サービスの SRV レコードからポート番号を検出を試み、検出できない場合はデフォルトの
デフォルトは |
OPENSHIFT_KUBE_PING_LABELS | Kubernetes 検索メカニズムのクラスタリングラベルセレクター。
値の例: |
OPENSHIFT_KUBE_PING_NAMESPACE | Kubernetes 検索メカニズムのクラスタリングプロジェクト namespace。
値の例: |
SCRIPT_DEBUG |
|
上記に記載されていない、製品に影響するその他の環境変数については、JBoss EAP のドキュメントを参照してください。
8.4. アプリケーションテンプレート
表8.3 アプリケーションテンプレート
変数名 | 説明 |
---|---|
AUTO_DEPLOY_EXPLODED | 展開形式のデプロイメントコンテンツが自動的にデプロイされるかどうかを制御します。
値の例: |
8.5. 公開されたポート
表8.4 公開されたポート
ポート番号 | 説明 |
---|---|
8443 | HTTPS |
8778 | Jolokia の監視 |
8.6. データソース
データソースは、環境変数の一部の値を元にして自動的に作成されます。
最も重要な環境変数は、データソースの JNDI マッピングを定義する DB_SERVICE_PREFIX_MAPPING
です。この変数で使用できる値は、POOLNAME-DATABASETYPE=PREFIX
トリプレットのコンマ区切りリストです。 説明を以下に示します。
-
POOLNAME
はデータソースのpool-name
として使用されます。 -
DATABASETYPE
は使用するデータベースドライバーです。 -
PREFIX
は、データソースを設定するために使用される環境変数の名前に使用される接頭辞です。
8.6.1. データソースの JNDI マッピング
起動スクリプトは、イメージの起動時に実行される個別のデータソースを DB_SERVICE_PREFIX_MAPPING
環境変数に定義された各 POOLNAME-DATABASETYPE=PREFIX
トリプレットに対して作成します。
DB_SERVICE_PREFIX_MAPPING
の最初の部分 (等号の前) は小文字である必要があります。
DATABASETYPE
はデータソースのドライバーを決定します。
ドライバーの設定に関する詳細は、「モジュール、ドライバー、および汎用デプロイメント」を参照してください。JDK 8 イメージにはデフォルトで設定された postgresql
および mysql
のドライバーがあります。
POOLNAME
パラメーターには特殊文字を使用しないでください。
8.6.1.1. データベースドライバー
Red Hat が提供する内部データソースドライバーを JBoss EAP for OpenShift イメージと使用する場合のサポートは、JDK 8 イメージストリームでは非推奨になりました。データベースベンダーから取得した JDBC ドライバーを JBoss EAP アプリケーションに使用することが推奨されます。
以下の内部データソースは、JBoss EAP for OpenShift の JDK 11 イメージでは提供されないようになりました。
- MySQL
- PostgreSQL
ドライバーのインストールに関する詳細は、「モジュール、ドライバー、および汎用デプロイメント」を参照してください。
JBoss EAP で JDBC ドライバーを設定するための詳細は、『設定ガイド』の「JDBC ドライバー」を参照してください。
各 JDK 8 イメージには、デプロイされた MySQL、PostgreSQL、および MongoDB データベースの Java ドライバーが含まれています。データソースは MySQL および PostgreSQL データベースのみに生成されます。
JDK 11 イメージストリームには、MySQL、PostgreSQL、および MongoDB データベースのドライバーは含まれず、データソースは生成されません。
ドライバーのインストールに関する詳細は、「モジュール、ドライバー、および汎用デプロイメント」を参照してください。
MongoDB は SQL データベースでないため、MongoDB データベースには JNDI マッピングは作成されません。
8.6.1.2. データソース設定環境変数
その他のデータソースプロパティーを設定するには、以下の環境変数を使用します。
必ず POOLNAME
、DATABASETYPE
、および PREFIX
の値を、以下の変数名と適切な値に置き換えてください。置き換え可能な値の説明は、本セクションと「データソース」に記載されています。
変数名 | 説明 |
---|---|
POOLNAME_DATABASETYPE_SERVICE_HOST |
データソースの
値の例: |
POOLNAME_DATABASETYPE_SERVICE_PORT | データソースのデータベースサーバーのポートを定義します。
値の例: |
PREFIX_BACKGROUND_VALIDATION |
|
PREFIX_BACKGROUND_VALIDATION_MILLIS |
|
PREFIX_CONNECTION_CHECKER | 使用中の特定のデータベースの接続を検証するために使用される接続チェッカークラスを指定します。
値の例: |
PREFIX_DATABASE | データソースのデータベース名を定義します。
値の例: |
PREFIX_DRIVER | データソースの Java データベースドライバーを定義します。
例の値: |
PREFIX_EXCEPTION_SORTER | 致命的なデータベース接続例外の発生後に適切に検出およびクリーンアップを行うために使用される例外ソータークラスを指定します。
例の値: |
PREFIX_JNDI |
データソースの JNDI 名を定義します。デフォルトは
値の例: |
PREFIX_JTA | 非 XA データソースの Java Transaction API (JTA) オプションを定義します。XA データソースはすでにデフォルトで JTA 可能になっています。
デフォルト値は |
PREFIX_MAX_POOL_SIZE | データソースの最大プールサイズオプションを定義します。
値の例: |
PREFIX_MIN_POOL_SIZE | データソースの最小プールサイズオプションを定義します。
値の例: |
PREFIX_NONXA |
データソースを非 XA データソースとして定義します。デフォルトは |
PREFIX_PASSWORD | データソースのパスワードを定義します。
値の例: |
PREFIX_TX_ISOLATION | データソースの java.sql.Connection トランザクション分離レベルを定義します。
値の例: |
PREFIX_URL | データソースの接続 URL を定義します。
値の例: |
PREFIX_USERNAME | データソースのユーザー名を定義します。
値の例: |
OpenShift でこのイメージを実行している場合、POOLNAME_DATABASETYPE_SERVICE_HOST
および POOLNAME_DATABASETYPE_SERVICE_PORT
環境変数は OpenShift アプリケーションテンプレートのデータベースサービス定義から自動的に設定されます。 その他の環境変数は、各 Pod テンプレートのコンテナー定義の env
エントリーとして直接テンプレートで設定されます。
8.6.1.3. 例
これらの例は、DB_SERVICE_PREFIX_MAPPING
環境変数の値がどのようにデータソースの作成に影響するかを表しています。
8.6.1.3.1. 単一のマッピング
値 test-postgresql=TEST
について考えてみます。
これは、java:jboss/datasources/test_postgresql
名でデータソースを作成します。さらに、パスワードやユーザー名などの必要な設定すべてが、TEST_USERNAME
や TEST_PASSWORD
のように、TEST_
接頭辞を持つ環境変数として提供されることが想定されます。
8.6.1.3.2. 複数のマッピング
複数のデータソースマッピングを指定できます。
複数のデータソースマッピングは常にコンマで区切ります。
DB_SERVICE_PREFIX_MAPPING
環境変数の値として cloud-postgresql=CLOUD,test-mysql=TEST_MYSQL
を考慮します。
これは以下の 2 つのデータソースを作成します。
-
java:jboss/datasources/test_mysql
-
java:jboss/datasources/cloud_postgresql
TEST_MYSQL
接頭辞は、TEST_MYSQL_USERNAME
のように MySQL データソースのユーザー名やパスワードなどの設定に使用できます。PostgreSQL データソースの場合は、CLOUD_USERNAME
のように CLOUD_
接頭辞を使用します。
8.7. クラスタリング
8.7.1. JGroups 検索メカニズムの設定
OpenShift で JBoss EAP クラスタリングを有効にするには、JBoss EAP 設定の JGroups プロトコルスタックを設定し、kubernetes.KUBE_PING
または openshift.DNS_PING
検索メカニズムのいずれかを使用するようにします。
カスタムの standalone-openshift.xml
設定ファイルを使用することもできますが、環境変数を使用 してイメージビルドで JGroups を設定することが推奨されます。
以下の手順は、環境変数を使用して JBoss EAP for OpenShift イメージの検出メカニズムを設定します。
利用可能なアプリケーションテンプレートの 1 つを使用して、JBoss EAP for OpenShift イメージの上にアプリケーションをデプロイする場合、デフォルトの検索メカニズムは openshift.DNS_PING
になります。
openshift.DNS_PING
および kubernetes.KUBE_PING
検索メカニズムは互換性がありません。検索に openshift.DNS_PING
メカニズムを使用する 1 つの独立した子クラスターと、kubernetes.KUBE_PING
メカニズムを使用するもう 1 つの独立した子クラスターを使用して、スーパークラスターを構成することは不可能です。同様に、ローリングアップグレードを実行する場合は、ソースクラスターとターゲットクラスターの両方で同じ検索メカニズムを使用する必要があります。
8.7.1.1. KUBE_PING の設定
KUBE_PING
JGroups 検索メカニズムを使用するには、以下を行います。
KUBE_PING
を検索メカニズムとして使用するよう JGroups プロトコルスタックを設定する必要があります。これには、
JGROUPS_PING_PROTOCOL
環境変数をkubernetes.KUBE_PING
に設定します。JGROUPS_PING_PROTOCOL=kubernetes.KUBE_PING
KUBERNETES_NAMESPACE
環境変数を OpenShift プロジェクト名に設定する必要があります。設定がないと、サーバーは単一ノードのクラスター (「1 つのクラスター」) として動作します。例を以下に示します。KUBERNETES_NAMESPACE=PROJECT_NAME
KUBERNETES_LABELS
環境変数を設定する必要があります。これは サービスレベルで設定したラベルと一致する必要があります。設定がないと、アプリケーション外部の Pod (namespace にあっても) は参加を試みます。例を以下に示します。KUBERNETES_LABELS=application=APP_NAME
Pod が実行しているサービスアカウントを承認し、Kubernetes の REST API アカウントへのアクセスを許可する必要があります。これは OpenShift CLI を使用して行われます。以下は、現在のプロジェクトの namespace で
default
サービスアカウントを使用した例になります。oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)
プロジェクトの namespace で
eap-service-account
を使用した例は次のとおりです。oc policy add-role-to-user view system:serviceaccount:$(oc project -q):eap-service-account -n $(oc project -q)
注記サービスアカウントへのポリシーの追加に関する詳細は、「アプリケーションのデプロイメントに向けた OpenShift の準備」を参照してください。
8.7.1.2. DNS_PING の設定
DNS_PING
JGroups 検索メカニズムを使用するには、以下を行います。
DNS_PING
を検索メカニズムとして使用するよう JGroups プロトコルスタックを設定する必要があります。これには、
JGROUPS_PING_PROTOCOL
環境変数をopenshift.DNS_PING
に設定します。JGROUPS_PING_PROTOCOL=openshift.DNS_PING
OPENSHIFT_DNS_PING_SERVICE_NAME
環境変数を、クラスターの ping サービスの名前に設定する必要があります。設定のない場合、サーバーは単一ノードのクラスター (「1 つのクラスター」) のように動作します。OPENSHIFT_DNS_PING_SERVICE_NAME=PING_SERVICE_NAME
OPENSHIFT_DNS_PING_SERVICE_PORT
環境変数を、ping サービスが公開されるポート番号に設定する必要があります。DNS_PING
プロトコルは SRV レコードからポートを識別しようとします。 識別できない場合はデフォルトの8888
になります。OPENSHIFT_DNS_PING_SERVICE_PORT=PING_PORT
ping ポートを公開する ping サービスを定義する必要があります。このサービスはヘッドレスである必要があり (ClusterIP=None)、以下が必要になります。
- ポートに名前を付ける必要があります。
"true"
に設定されたservice.alpha.kubernetes.io/tolerate-unready-endpoints
アノテーションをサービスに付ける必要があります。注記このアノテーションを省略すると、起動時に各ノードが独自の「1 つのクラスター」を構成することになり、他のノードは起動後まで検出されないため、起動後に他のノードのクラスターとマージすることになります。
kind: Service apiVersion: v1 spec: clusterIP: None ports: - name: ping port: 8888 selector: deploymentConfig: eap-app metadata: name: eap-app-ping annotations: service.alpha.kubernetes.io/tolerate-unready-endpoints: "true" description: "The JGroups ping port for clustering."
DNS_PING
はサービスアカウントへの変更が必要なく、デフォルトのパーミッションを使用して動作します。
8.7.2. クラスタートラフィックを暗号化するため JGroups を設定
OpenShift でJBoss EAP のクラスタートラフィックを暗号化するには、SYM_ENCRYPT
または ASYM_ENCRYPT
プロトコルのいずれかを使用するよう、JBoss EAP 設定の JGroups プロトコルスタックを設定する必要があります。
カスタムの standalone-openshift.xml
設定ファイルを使用することもできますが、環境変数を使用 してイメージビルドで JGroups を設定することが推奨されます。
以下の手順は、環境変数を使用して、JBoss EAP for OpenShift イメージのクラスタートラフィックの暗号化にプロトコルを設定します。
SYM_ENCRYPT
および ASYM_ENCRYPT
プロトコルは互換性がありません。クラスタートラフィックの暗号化に SYM_ENCRYPT
を使用する 1 つの独立した子クラスターと、ASYM_ENCRYPT
プロトコルを使用する別の独立した子クラスターの 2 つを使用してスーパークラスターを構成するのは不可能です。同様に、ローリングアップグレードを実行する場合は、ソースおよびターゲットクラスターの両方で同じプロトコルを使用する必要があります。
8.7.2.1. SYM_ENCRYPT の設定
SYM_ENCRYPT
プロトコルを使用して JGroups クラスタートラフィックを暗号化するには、以下を行います。
SYM_ENCRYPT
を暗号化プロトコルをして使用するよう、JGroups プロトコルスタックを設定する必要があります。これには、
JGROUPS_ENCRYPT_PROTOCOL
環境変数をSYM_ENCRYPT
に設定します。JGROUPS_ENCRYPT_PROTOCOL=SYM_ENCRYPT
JGROUPS_ENCRYPT_SECRET
環境変数を、JGroups の通信をセキュアにするために使用される JGroups キーストアファイルが含まれるシークレットの名前に設定する必要があります。設定しないと、クラスター通信は暗号化されず、警告が発生します。例を以下に示します。JGROUPS_ENCRYPT_SECRET=eap7-app-secret
JGROUPS_ENCRYPT_KEYSTORE_DIR
環境変数を、JGROUPS_ENCRYPT_SECRET
変数を介して指定されるシークレット内にあるキーストアファイルのディレクトリーパスに設定する必要があります。設定しないと、クラスター通信は暗号化されず、警告が発生します。例を以下に示します。JGROUPS_ENCRYPT_KEYSTORE_DIR=/etc/jgroups-encrypt-secret-volume
JGROUPS_ENCRYPT_KEYSTORE
環境変数を、JGROUPS_ENCRYPT_SECRET
変数を介して指定されるシークレット内にあるキーストアファイルの名前に設定する必要があります。設定しないと、クラスター通信は暗号化されず、警告が発生します。例を以下に示します。JGROUPS_ENCRYPT_KEYSTORE=jgroups.jceks
JGROUPS_ENCRYPT_NAME
環境変数を、サーバーの証明書に関連する名前に設定する必要があります。設定しないと、クラスター通信は暗号化されず、警告が発生します。例を以下に示します。JGROUPS_ENCRYPT_NAME=jgroups
JGROUPS_ENCRYPT_PASSWORD
環境変数を、キーストアおよび証明書にアクセスするために使用されるパスワードに設定する必要があります。設定しないと、クラスター通信は暗号化されず、警告が発生します。例を以下に示します。JGROUPS_ENCRYPT_PASSWORD=mypassword
8.7.2.2. ASYM_ENCRYPT の設定
ASYM_ENCRYPT
プロトコルを使用して JGroups クラスタートラフィックを暗号化するには、以下を行います。
ASYM_ENCRYPT
を暗号化プロトコルをして使用するよう、JGroups プロトコルスタックを設定する必要があります。これには、
JGROUPS_ENCRYPT_PROTOCOL
環境変数をASYM_ENCRYPT
に設定します。JGROUPS_ENCRYPT_PROTOCOL=ASYM_ENCRYPT
JGROUPS_CLUSTER_PASSWORD
環境変数を、ノードの認証に使用されるパスワードに設定し、JGroups クラスターに参加できるようにする必要があります。設定がないと、認証は無効になり、クラスターの通信は暗号化されず、警告が発生します。例を以下に示します。JGROUPS_CLUSTER_PASSWORD=mypassword
ASYM_ENCRYPT
を設定し、SYM_ENCRYPT
に必要な環境変数も定義した場合、SYM_ENCRYPT
環境変数は無視され、警告が発生します。このような場合でも、クラスターの通信は ASYM_ENCRYPT
を使用して暗号化されます。
8.8. ヘルスチェック
JBoss EAP for OpenShift イメージは、デフォルトで OpenShift に含まれる liveness および readiness プローブ を使用します。また、このイメージには 『設定ガイド』で説明されているように Eclipse MicroProfile Healthが含まれます。
以下の表には、これらのヘルスチェックに合格するために必要な値が記載されています。以下の値以外の場合は、ヘルスチェックに合格せず、イメージの再起動ポリシーにしたがってイメージが再起動されます。
表8.5 Liveness および Readiness チェック
実行されたテスト | Liveness | Readiness |
---|---|---|
Server Status | すべての状態 | Running |
Boot Errors | None | None |
デプロイメントの状態 [a] |
N/A または |
N/A または |
Eclipse MicroProfile Health [b] |
N/A または |
N/A または |
[a]
Deployment Status デプロイメントが存在しない場合、有効な状態は N/A のみ。
[b]
microprofile-health-smallrye サブシステムが無効な場合、有効な状態は N/A のみ。
|
8.9. Messaging
8.9.1. 外部 Red Hat AMQ ブローカーの設定
環境変数で JBoss EAP for OpenShift イメージを設定し、外部 Red Hat AMQ ブローカーに接続できます。
OpenShift アプリケーション定義の例
以下の例はテンプレートを使用して、外部 Red Hat AMQ 7 ブローカーに接続する JBoss EAP アプリケーションを作成します。
例: eap72-amq-s2i
アプリケーションテンプレート
oc new-app eap72-amq-s2i \ -p APPLICATION_NAME=eap72-mq \ -p MQ_USERNAME=MY_USERNAME \ -p MQ_PASSWORD=MY_PASSWORD
以上の例では、JDK 11 イメージストリームは JDK 8 イメージストリームで使用される eap72-amq-s2i
の代わりに、eap72-openjdk11-amq-s2i
アプリケーションテンプレートを使用します。
例で使用されるテンプレートは、必要なパラメーターに有効なデフォルト値を提供します。テンプレートを使用せず、独自のパラメーターを提供する場合は、MQ_SERVICE_PREFIX_MAPPING
の名前が「-amq7=MQ」が追加された APPLICATION_NAME
の名前と一致する必要があることに注意してください。
8.10. セキュリティードメイン
新しいセキュリティードメインを設定するには、ユーザーは SECDOMAIN_NAME
環境変数を定義する必要があります。
これにより、環境変数の名前が付けられたセキュリティードメインが作成されます。ドメインをカスタマイズするには、以下の環境変数も定義します。
表8.6 セキュリティードメイン
変数名 | 説明 |
---|---|
SECDOMAIN_NAME | 追加のセキュリティードメインを定義します。
値の例: |
SECDOMAIN_PASSWORD_STACKING |
定義した場合、
値の例: |
SECDOMAIN_LOGIN_MODULE | 使用されるログインモジュール。
デフォルトは |
SECDOMAIN_USERS_PROPERTIES | ユーザー定義が含まれるプロパティーファイルの名前。
デフォルトは |
SECDOMAIN_ROLES_PROPERTIES | ロール定義が含まれるプロパティーファイルの名前。
デフォルトは |
8.11. HTTPS 環境変数
変数名 | 説明 |
---|---|
HTTPS_NAME |
値の例: |
HTTPS_PASSWORD |
値の例: |
HTTPS_KEYSTORE |
値の例: |
8.12. 管理環境変数
表8.7 管理環境変数
変数名 | 説明 |
---|---|
ADMIN_USERNAME |
この変数と
値の例: |
ADMIN_PASSWORD |
指定された
値の例: |
8.13. S2I
イメージには S2I スクリプトと Maven が含まれます。
現在 Maven は、OpenShift 上の JBoss EAP ベースのコンテナー (または関連/子孫イメージ) にデプロイされるはずのアプリケーションのビルドツールとしてのみサポートされます。
現在、WAR デプロイメントのみがサポートされます。
8.13.1. カスタム設定
イメージのカスタム設定ファイルを追加することが可能です。configuration/
ディレクトリーに置かれたすべてのファイルは EAP_HOME/standalone/configuration/
にコピーされます。たとえば、イメージで使用されるデフォルトの設定をオーバーライドするには、カスタムの standalone-openshift.xml
を configuration/
ディレクトリーに追加します。このようなデプロイメントの例を参照してください。
8.13.1.1. カスタムモジュール
カスタムモジュールを追加することが可能です。modules/
ディレクトリーからのすべてのファイルは EAP_HOME/modules/
にコピーされます。このようなデプロイメントの 例を参照 してください。
8.13.2. デプロイメントアーティファクト
デフォルトでは、ソースの target
ディレクトリーからのアーティファクトがデプロイされます。異なるディレクトリーからデプロイするには、BuildConfig 定義の ARTIFACT_DIR
環境変数を設定します。ARTIFACT_DIR
はカンマ区切りのリストです。例: ARTIFACT_DIR=app1/target,app2/target,app3/target
8.13.3. アーティファクトリポジトリーミラー
Maven のリポジトリーは、すべてのプロジェクト JAR、ライブラリー JAR、プラグイン、またはその他のプロジェクト固有のアーティファクトなど、さまざまな種類のビルドアーティファクトおよび依存関係を保持します。また、S2I ビルドの実行中にアーティファクトのダウンロード元となる場所も指定します。組織では、中央リポジトリーを使用する他に、ローカルカスタムミラーリポジトリーをデプロイすることが一般的です。
ミラーを使用する利点は次のとおりです。
- 地理的に近く、高速な同期ミラーを使用できる。
- リポジトリーの内容をより良く制御できる。
- パブリックサーバーおよびリポジトリーに依存する必要なく、異なるチーム (開発者、CI) 全体でアーティファクトを共有できる。
- ビルド時間が改善される。
多くの場合で、リポジトリーマネージャーはミラーへのローカルキャッシュとして機能できます。リポジトリーマネージャーがすでにデプロイされ、http://10.0.0.1:8080/repository/internal/
で外部アクセス可能な場合、以下のように MAVEN_MIRROR_URL
環境変数をアプリケーションのビルド設定に提供すると S2I ビルドはこのマネージャーを使用することができます。
MAVEN_MIRROR_URL
変数を適用するビルド設定の名前を特定します。oc get bc -o name buildconfig/eap
eap
のビルド設定をMAVEN_MIRROR_URL
環境変数で更新します。oc env bc/eap MAVEN_MIRROR_URL="http://10.0.0.1:8080/repository/internal/" buildconfig "eap" updated
設定を確認します。
oc env bc/eap --list # buildconfigs eap MAVEN_MIRROR_URL=http://10.0.0.1:8080/repository/internal/
- アプリケーションの新しいビルドをスケジュールします。
アプリケーションのビルド中、Maven 依存関係はデフォルトのパブリックリポジトリーではなく、リポジトリーマネージャーからプルされることを確認できます。またビルドの完了後、ビルド中に取得および使用されたすべての依存関係がミラーに追加されたことが確認できます。
8.13.4. スクリプト
run
-
このスクリプトは、
standalone-openshift.xml
設定で JBoss EAP を設定および開始するopenshift-launch.sh
スクリプトを使用します。 assemble
-
このスクリプトは Maven を使用してソースをビルドして、パッケージ (WAR) を作成し、それを
EAP_HOME/standalone/deployments
ディレクトリーに移動します。
8.13.5. 環境変数
s2i build
コマンドに指定する環境変数によって、ビルドの実行方法が異なります。指定できる環境変数は次のとおりです。
表8.8 S2I 環境変数
変数名 | 説明 |
---|---|
ARTIFACT_DIR |
このディレクトリーからの
値の例: |
HTTP_PROXY_HOST | Maven が使用する HTTP プロキシーのホスト名または IPアドレス。
値の例: |
HTTP_PROXY_PORT | Maven が使用する HTTP プロキシーの TCP ポート。
値の例: |
HTTP_PROXY_USERNAME |
値の例: |
HTTP_PROXY_PASSWORD |
値の例: |
HTTP_PROXY_NONPROXYHOSTS | 指定された場合、設定された HTTP プロキシーはこれらのホストを無視します。
値の例: |
MAVEN_ARGS | ビルド中に Maven に指定された引数をオーバーライドします。
値の例: |
MAVEN_ARGS_APPEND | ビルド中に Maven に指定されたユーザー引数を追加します。
値の例: |
MAVEN_MIRROR_URL | 設定する Maven ミラー/リポジトリーマネージャーの URL。
値の例: |
MAVEN_CLEAR_REPO | 任意で、ビルド後にローカル Maven リポジトリーを消去します。
値の例: |
APP_DATADIR | 定義された場合、データファイルのコピー元であるソースのディレクトリー。
値の例: |
DATA_DIR |
値の例: |
詳細は、JBoss EAP for OpenShift イメージに含まれる Maven および S2I スクリプトを使用する、「JBoss EAP for OpenShift イメージでの Java アプリケーションのビルドおよび実行」を参照してください。
8.14. SSO
このイメージには Red hat JBoss SSO 対応アプリケーションのサポートが含まれます。
JBoss EAP for OpenShift イメージで OpenShift イメージの Red Hat JBoss SSO をデプロイする方法に関する詳細は、『Red Hat Single Sign-On for OpenShift』を参照してください。
表8.9 SSO 環境変数
変数名 | 説明 |
---|---|
SSO_URL | SSO サーバーの URL。 |
SSO_REALM | デプロイされたアプリケーションの SSO レルム。 |
SSO_PUBLIC_KEY | SSO レルムの公開鍵。これは任意のフィールドですが、省略するとアプリケーションが中間者攻撃に脆弱になります。 |
SSO_USERNAME | SSO REST API のアクセスに必要な SSO ユーザー。
値の例: |
SSO_PASSWORD |
値の例: |
SSO_SAML_KEYSTORE |
SAML のキーストアの場所。デフォルトは |
SSO_SAML_KEYSTORE_PASSWORD |
SAML のキーストアパスワード。デフォルトは |
SSO_SAML_CERTIFICATE_NAME |
SAML に使用するキー/証明書のエイリアス。デフォルトは |
SSO_BEARER_ONLY | SSO クライアントアクセスタイプ。(オプション)
値の例: |
SSO_CLIENT |
アプリケーションへ戻る SSO リダイレクトのパス。デフォルトは |
SSO_ENABLE_CORS |
|
SSO_SECRET | 機密アクセスのための SSO クライアントシークレット。
値の例: |
SSO_DISABLE_SSL_CERTIFICATE_VALIDATION |
値の例: |
8.15. トランザクションリカバリー
クラスターがスケールダウンしたとき、トランザクションブランチがインダウトの状態になる可能性があります。このようなブランチを完了するたための テクノロジープレビューの自動化リカバリー Pod がありますが、リカバリーに失敗する可能性のあるネットワークスプリットなど、まれな状況が発生する場合があります。そのような場合、手動によるトランザクションリカバリーが必要になることがあります。
8.15.1. サポートされないトランザクションリカバリーのシナリオ
JTS トランザクション
親のネットワークエンドポイントはリカバリーコーディネーター IOR でエンコードされるため、子または親ノードのいずれかが新しい IP アドレスでリカバリーしたり、仮想化された IP アドレスを使用してアクセスされる目的である場合は、リカバリーが確実に動作しません。
XTS トランザクション
XTS はリカバリー目的ではクラスター化された状況で動作しません。詳細は「JBTM-2742」を参照してください。
- JBoss Remoting 上で伝搬されるトランザクション
XATerminator 上で伝搬されるトランザクション
EIS は、Java EE アプリケーションサーバーの単一インスタンスに接続することを目的とするため、これらのプロセスに対応する明確に定義された方法はありません。
8.15.2. 手動のトランザクションリカバリープロセス
次の手順の目的は、自動化リカバリーに失敗した場合にインダウト状態のブランチを見つけ、手作業で解決することです。
8.15.2.1. 注意事項
この手順は、単一の JVM 内で完全に自己完結したトランザクションを手動でリカバリーする方法のみを説明しています。この手順の説明は、別の JVM に伝搬された JTA トランザクションをリカバリーする方法ではありません。
同じ IP アドレスと同じノード名を持つ同じ Pod の複数のインスタンスを OpenShift が起動する可能性があり、パーティションにより古い Pod が稼働するさまざまなネットワークパーティションのシナリオがあります。そのため、手動リカバリーの間に、オブジェクトストアの古いビューを持つ Pod に接続される可能性があります。これに該当すると思われる場合は、すべての JBoss EAP Pod をシャットダウンし、使用中のリソースマネージャーやオブジェクトストアが存在しないようにします。
XA トランザクションでリソースを登録する場合、各リソースタイプがリカバリーでサポートされることを確認するのはユーザーの責任となります。たとえば、PostgreSQL とMySQL はリカバリーで適切に動作することが知られています。 しかし、A-MQ や JDV リソースマネージャーはの場合は、特定の OpenShift リリースのドキュメントをチェックする必要があります。
デプロイメントは JDBC オブジェクトストア を使用する必要があります。
トラザクションマネージャーは、ノード識別子が一意であることに依存します。XID の最大バイト長は XA 仕様によって設定され、変更できません。JBoss EAP for OpenShift イメージが XID に含めなければならないデータにより、ノード識別子には 23 バイトの空き領域があります。
OpenShift では以下をこの 23 バイトの制限に合わせるよう強制されます。
-
すべてのノード名。 23 バイト未満の名前でも
-
(ダッシュ) は削除されます。 - 名前が 23 バイトを超える場合、名前の最初から 23 バイトの長さまでに省略されます。
しかし、これにより識別子の一意性に影響を与える可能性があります。たとえば、aaa123456789012345678m0jwh
と bbb123456789012345678m0jwh
は両方 123456789012345678m0jwh
に省略され、名前の一意性が保たれなくなります。this-pod-is-m0jwh
と thispod-is-m0jwh
の場合でも、両方が thispodism0jwh
に省略され、一意性が保たれなくなります。
上記の省略処理を念頭に置いて、設定するノード名が一意になるようにする必要があります。
8.15.2.2. 前提条件
OpenShift インスタンスは JDBC ストアと設定され、ストアテーブルは Pod 名に対応するテーブル接頭辞を使用してパーティションされることを前提とします。これは、JBoss EAP デプロイメントを使用する場合は常に自動である必要があります。これは、共有ボリューム上で split ディレクトリーを持つファイルストアを使用する 自動化リカバリーの例 とは異なります。稼働中の Pod で transaction サブシステムの設定を確認すると、JBoss EAP インスタンスが JDBC オブジェクトストアを使用していることが確認できます。
/opt/eap/standalone/configuration/openshift-standalone.xml
設定ファイルに transaction サブシステムの要素が含まれることを確認します。<subsystem xmlns="urn:jboss:domain:transactions:3.0">
JDBC オブジェクトストアが使用されている場合、以下と似たエントリーが存在します。
<jdbc-store datasource-jndi-name="java:jboss/datasources/jdbcstore_postgresql"/>
注記JNDI 名は、トランザクションログの格納に使用されるデータソースを識別します。
8.15.2.3. 手順
以下の手順は、データソースのみに対する手動トランザクションリカバリーのプロセスについて説明します。
- データベースベンダーのツールを使用して、インダウト状態のブランチの XID (トランザクションブランチ識別子) をリストします。失敗またはスケールダウンした Pod で実行中であったすべてのデプロイメントが使用していたすべてのデータソースの XID をリストする必要があります。使用しているデータベース製品のドキュメントを参照してください。
このような各 XID に対して、トランザクションを作成した Pod を特定し、その Pod が今も実行中であるかを確認します。
- 実行中である場合、ブランチはそのままにしておきます。
Pod が実行していない場合、クラスターから削除されたと仮定し、ここで説明する手動の解決手順を適用する必要があります。失敗した Pod によって使用されたトランザクションログストレージに、対応するトランザクションログがあるかどうかを確認します。
- ログがある場合、ベンダーのツールを使用して XID を手動でコミットします。
- ログがない場合、orphan ブランチであることを仮定し、ベンダーのツールを使用して XID をロールバックします。
これ以降の手順では、各ステップの実行方法を詳細に説明します。
8.15.2.3.1. インダウト状態のブランチの解決
最初に、デプロイメントが使用しているリソースをすべて探します。
この作業は、JBoss EAP 管理 CLI を使用して行うことが推奨されます。リソースは JBoss EAP の standalone-openshift.xml
設定ファイルに定義する必要がありますが、アプリケーションサーバー内で transaction サブシステムが利用できるようにする方法が他にあります。たとえば、デプロイメントのファイルを使用したり、ランタイムで管理 CLI を動的に使用したりして行うことができます。
- 失敗した Pod のクラスターで JBoss EAP インスタンスを実行する Pod にてターミナルを開きます。対象の Pod がない場合は、その Pod に対してスケールアップします。
-
/opt/eap/bin/add-user.sh
スクリプトを使用して管理ユーザーを作成します。 -
/opt/eap/bin/jboss-cli.sh
スクリプトを使用して、管理 CLI にログインします。 サーバーに設定されたデータソースをリストします。これらにインダウト状態のトランザクションブランチが含まれる可能性があります。
/subsystem=datasources:read-resource { "outcome" => "success", "result" => { "data-source" => { "ExampleDS" => undefined, ... }, ... }
リストを表示したら、各データソースの接続 URL を見つけます。例を以下に示します。
/subsystem=datasources/data-source=ExampleDS:read-attribute(name=connection-url) { "outcome" => "success", "result" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE", "response-headers" => {"process-state" => "restart-required"} }
各データソースに接続し、インダウト状態のトランザクションブランチをすべて表示します。
注記インダウト状態のブランチを格納するテーブル名は各データソースベンダーごとに異なります。
JBoss EAP には、各データベースをチェックするのに使用できるデフォルトの SQL クエリーツール (H2) があります。例を以下に示します。
java -cp /opt/eap/modules/system/layers/base/com/h2database/h2/main/h2-1.3.173.jar \ -url "jdbc:postgresql://localhost:5432/postgres" \ -user sa \ -password sa \ -sql "select gid from pg_prepared_xacts;"
この代わりに、リソースのネイティブツールを使用することもできます。たとえば、
sampledb
と呼ばれる PostGreSQL データソースでは、OpenShift クライアントツールを使用して Pod にリモートでログインし、インダウト状態のトランザクションテーブルにクエリーを実行することができます。$ oc rsh postgresql-2-vwf9n # rsh to the named pod sh-4.2$ psql sampledb psql (9.5.7) Type "help" for help. sampledb=# select gid from pg_prepared_xacts; 131077_AAAAAAAAAAAAAP//rBEAB440GK1aJ72oAAAAGHAtanRhLWNyYXNoLXJlYy0zLXAyY2N3_AAAAAAAAAAAAAP//rBEAB440GK1aJ72oAAAAGgAAAAEAAAAA
8.15.2.3.2. グローバルトランザクション ID およびノード識別子を各 XID から取得
インダウト状態のブランチの XID がすべて特定できたら、XID をトランザクションマネージャーのトランザクションテーブルに保存されたログと比較できる形式に変換します。
たとえば、この変換に以下の Bash スクリプトを使用することができます。$PG_XID
が上記の select ステートメントからの XID を保持する場合、以下のように JBoss EAP トランザクション ID を取得することができます。
PG_XID="$1" IFS='_' read -ra lines <<< "$PG_XID" [[ "${lines[0]}" = 131077 ]] || exit 0; # this script only works for our own FORMAT ID PG_TID=${lines[1]} a=($(echo "$PG_TID"| base64 -d | xxd -ps |tr -d '\n' | while read -N16 i ; do echo 0x$i ; done)) b=($(echo "$PG_TID"| base64 -d | xxd -ps |tr -d '\n' | while read -N8 i ; do echo 0x$i ; done)) c=("${b[@]:4}") # put the last 3 32-bit hexadecimal numbers into array c # the negative elements of c need special handling since printf below only works with positive # hexadecimal numbers for i in "${!c[@]}"; do arg=${c[$i]} # inspect the MSB to see if arg is negative - if so convert it from a 2’s complement number [[ $(($arg>>31)) = 1 ]] && x=$(echo "obase=16; $(($arg - 0x100000000 ))" | bc) || x=$arg if [[ ${x:0:1} = \- ]] ; then # see if the first character is a minus sign neg[$i]="-"; c[$i]=0x${x:1} # strip the minus sign and make it hex for use with printf below else neg[$i]="" c[$i]=$x fi done EAP_TID=$(printf %x:%x:${neg[0]}%x:${neg[1]}%x:${neg[2]}%x ${a[0]} ${a[1]} ${c[0]} ${c[1]} ${c[2]})
完了後、$EAP_TID
変数はこの XID を作成したトランザクションのグローバルトランザクション ID を保持します。トランザクションを開始した Pod のノード識別子は、以下の bash コマンドの出力によって提供されます。
echo "$PG_TID"| base64 -d | tail -c +29
ノード識別子は、PostgreSQL グローバルトラザクション ID フィールドの 29 番目の文字から始まります。
- Pod が 実行している 場合は、トランザクションが実行中であるため、インダウト状態のブランチをそのままにしておきます。
この Pod が実行していない場合は、トランザクションログの関連するトランザクションログストレージを検索する必要があります。ログストレージは、以下に従って命名される JDBC テーブルにあります。
OS<node-identifier>jbosststxtable
パターン。- このようなテーブルがない場合は、他のトランザクションマネージャーによって所有されているため、ブランチをそのままにしておきます。このテーブルが含まれるデータソースの URL は、以下の transaction サブシステムで定義されます。
このようなテーブルがある場合、グローバルトランザクション ID と一致するエントリーを探します。
- グローバルトランザクション ID と一致するエントリーがテーブルにある場合、以下の説明どおりにデータソースベンダーのツールを使用してインダウト状態のブランチをコミットする必要があります。
- そのようなエントリーがない場合、ブランチは orphan であり、安全にロールバックすることができます。
以下は、インダウト状態の PostgreSQL ブランチをコミットする方法の例になります。
$ oc rsh postgresql-2-vwf9n sh-4.2$ psql sampledb psql (9.5.7) Type "help" for help. psql sampledb commit prepared '131077_AAAAAAAAAAAAAP//rBEAB440GK1aJ72oAAAAGHAtanRh ---- LWNyYXNoLXJlYy0zLXAyY2N3_AAAAAAAAAAAAAP//rBEAB440GK1aJ72oAAAAGgAAAAEAAAAA';
この手順をすべてのデータソースおよびインダウト状態のブランチに繰り返します。
8.15.2.3.3. リソースマネージャーに接触できるクラスターで稼働中すべての JBoss EAP インスタンスのノード識別子リストを取得
ノード識別子は、Pod 名と同じ名前になるように設定されます。oc
コマンドを使用すると、使用中の Pod 名を取得できます。以下のコマンドを使用して、実行中の Pod をリストします。
$ oc get pods | grep Running eap-manual-tx-recovery-app-4-26p4r 1/1 Running 0 23m postgresql-2-vwf9n 1/1 Running 0 41m
実行中の各 Pod に対し、Pod のログの出力を確認し、ノード名を取得します。たとえば、上記の出力にある最初の Pod の場合、以下のコマンドを使用します。
$ oc logs eap-manual-tx-recovery-app-4-26p4r | grep "jboss.node.name" | head -1 jboss.node.name = tx-recovery-app-4-26p4r
前述の JBoss ノード名識別子 は、常に最大文字数である 23 文字になるよう省略されます。これは、先頭から文字を削除して最大長の 23 文字になるまで末尾の文字を確保します。
8.15.2.3.4. トランザクションログの検索
-
トランザクションログは JDBC が基盤のオブジェクトストアにあります。このストアの JNDI 名は、JBoss EAP 設定ファイルの
transaction
サブシステム定義に定義されています。 - 設定ファイルを確認し、上記の JNDI 名に対応するデータソース定義を見つけます。
- JNDI 名を使用して、接続 URL を取得します。
URL を使用してデータベースに接続し、関係するインダウト状態のトランザクションテーブルで
select
クエリーを実行します。データベースが実行している Pod が分かり、データベースの名前が分かる場合は、Pod に OpenShift リモートシェルを開き、直接データベースツールを使用した方が簡単であることがあります。
たとえば、JDBC ストアが Pod
postgresql-2-vwf9n
で実行されているsampledb
という PostgreSQL データベースによってホストされる場合、以下のコマンドを使用してトランザクションログを見つけることができます。注記以下のコマンドの ostxrecoveryapp426p4rjbosststxtable テーブル名は、ログストレージエントリーを保持する JDBC テーブル名のパターン にしたがっているため選択されました。ご使用の環境では、テーブル名は以下と似た形式になります。
-
os
接頭辞で始まります。 - 中間部分は、上記の JBoss ノード名から適用されます。 「-」(ダッシュ) が存在する場合は削除される可能性があります。
-
最後に
jbosststxtable
接頭辞が追加され、テーブルの最終名が作成されます。
$ oc rsh postgresql-2-vwf9n sh-4.2$ psql sampledb psql (9.5.7) Type "help" for help. sampledb=# select uidstring from ostxrecoveryapp426p4rjbosststxtable where TYPENAME='StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction' ; uidstring ------------------------------------- 0:ffff0a81009d:33789827:5a68b2bf:40 (1 row)
-
8.15.2.3.5. 調整したインダウト状態のブランチのトランザクションログをクリーンアップ
インダウト状態のブランチが残っていないことを確信できるまで、ログを削除しないでください。
指定のトラザクションのブランチがすべて完了し、A-MQ および JDV を含む潜在的なリソースマネージャーがすべてチェックされた後、トランザクションログを安全に削除できます。
以下のコマンドを実行します。 適切な uidstring
を使用して削除するトラザクションログを指定します。
DELETE FROM ostxrecoveryapp426p4rjbosststxtable where uidstring = UIDSTRING
ログを削除しない場合、準備後に失敗し、現在は解決された完了済みのトランザクションはトランザクションログストレージから削除されません。この結果、不必要なストレージが使用され、今後の手作業の調整がより困難になります。
8.16. 含まれる JBoss モジュール
以下の表は、JBoss EAP for OpenShift イメージに含まれる JBoss モジュールを表しています。
表8.10 含まれる JBoss モジュール
JBoss モジュール |
---|
org.jboss.as.clustering.common |
org.jboss.as.clustering.jgroups |
org.jboss.as.ee |
org.jboss.logmanager.ext |
org.jgroups |
org.mongodb |
org.openshift.ping |
org.postgresql |
com.mysql |
net.oauth.core |
以下のモジュールは、JDK 11 イメージには含まれていません。
-
org.mongodb
-
org.postgresql
-
com.mysql
Revised on 2019-11-28 14:43:51 CET