Red Hat JBoss Web Server for OpenShift
Red Hat JBoss Web Server for OpenShift のインストールおよび使用
概要
Red Hat ドキュメントへのフィードバック (英語のみ)
弊社の技術的な内容についてのフィードバックに感謝します。ご意見をお聞かせください。コメントの追加、Insights の提供、誤字の修正、および質問を行う必要がある場合は、ドキュメントで直接行うこともできます。
Red Hat アカウントがあり、カスタマーポータルにログインしている必要があります。
カスタマーポータルからドキュメントのフィードバックを送信するには、以下の手順を実施します。
- Multi-page HTML 形式を選択します。
- ドキュメントの右上にある Feedback ボタンをクリックします。
- フィードバックを提供するテキストのセクションを強調表示します。
- ハイライトされたテキストの横にある Add Feedback ダイアログをクリックします。
- ページの右側のテキストボックスにフィードバックを入力し、送信 をクリックします。
フィードバックを送信すると、自動的に問題の追跡が作成されます。Submit をクリックすると表示されるリンクを開き、問題の監視を開始するか、さらにコメントを追加します。
貴重なフィードバックにご協力いただきありがとうございます。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Red Hat JBoss Web Server for OpenShift
Red Hat JBoss Web Server (JWS) 5.6 の Apache Tomcat 9 コンポーネントは、Red Hat OpenShift 用に設計されたコンテナー化されたイメージとして利用できます。このイメージを使用して、ハイブリッドクラウド環境にまたがるデプロイメントのために Java Web アプリケーションをビルド、スケーリング、テストできます。
1.1. Red Hat JBoss Web Server と JWS for OpenShift の相違点
JWS for OpenShift イメージは、Red Hat JBoss Web Server の通常のリリースとは異なります。
JWS for OpenShift イメージと標準の JBoss Web Server デプロイメントとの次の違いを考慮してください。
-
JWS for OpenShift イメージでは、
/opt/jws-5.6/
ディレクトリーがJWS_HOME
の場所です。 -
JWS for OpenShift デプロイメントでは、JBoss Core Services の
mod_cluster
コネクターまたはmod_jk
コネクターではなく、OpenShift ルーターによってすべてのロードバランシングが処理されます。
1.2. OpenShift イメージバージョンの互換性とサポート
OpenShift イメージは、Red Hat OpenShift Container Platform のお客様が使用している最も一般的なテクノロジーの組み合わせを表すさまざまなオペレーティングシステムのバージョン、設定、およびインターフェイスポイントでテストされています。
新しいアプリケーションをデプロイする場合は、OpenShift イメージとアプリケーションテンプレートに JWS の 5.6 バージョンを使用する必要があります。
JWS for OpenShift イメージおよびアプリケーションテンプレートの 5.5 バージョンは非推奨となり、更新を受信しなくなりました。
1.3. JBoss Web Server でサポートされるアーキテクチャー
JBoss Web Server は以下のアーキテクチャーをサポートします。
- x86_64 (AMD64)
- OpenShift 環境の IBM Z (s390x)
- OpenShift 環境の IBM Power (ppc64le)
サポートされるすべてのアーキテクチャーで OpenJDK 11 に JBoss Web Server イメージを使用できます。イメージについての詳細は、Red Hat Container Catalog を参照してください。
1.4. Red Hat コンテナーイメージのヘルスチェック
すべての OpenShift Container Platform イメージには、正常性評価が関連付けられています。Red Hat JBoss Web Server の可用性評価は、Certfied コンテナーイメージ ページに移動し、JBoss Web Server
を検索して 5.6 バージョンを選択することで確認できます。
また、OpenShift コンテナーでヘルスチェックを実行して、コンテナーの稼働状況と準備状況をテストすることもできます。
1.5. 関連情報 (または次の手順)
第2章 Red Hat JBoss Web Server for OpenShift の使用を開始する
Red Hat コンテナーレジストリーから、最新の Red Hat JBoss Web Server for OpenShift イメージストリームおよびテンプレートをインポートできます。その後、JWS for OpenShift Source-to-Image (S2I) プロセスを使用して、既存の Maven バイナリーを使用するか、ソースコードから OpenShift アプリケーション用の JBoss Web Server を作成できます。
このドキュメントの手順に従う前に、前提条件として OpenShift クラスターが既にインストールされ、設定されていることを確認する必要があります。OpenShift クラスターのインストールと設定の詳細については、OpenShift Container Platform の インストール ガイドを参照してください。
JWS for OpenShift アプリケーションテンプレートは、Tomcat 9 に対して配布されます。
2.1. Red Hat Container Registry の認証トークンの設定
Red Hat JBoss Web Server for OpenShift イメージをインポートして使用する前に、Red Hat Container Registry にアクセスするための認証トークンが設定されていることを確認する必要があります。
レジストリーサービスアカウントを使用して、認証トークンを作成できます。こうすると、お持ちの Red Hat アカウントのユーザー名やパスワードを OpenShift 設定に使用または保存する必要がありません。
手順
- Red Hat カスタマーポータルの手順にしたがって、レジストリーサービスアカウントを使用して認証トークンを作成します。
- トークンの Token Information ページで、OpenShift Secret タブをクリックし、トークンの OpenShift シークレットを含む YAML ファイルをダウンロードします。
ダウンロードした 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
注記前の例で、
1234567-myserviceaccount
を前の手順で作成したシークレットの名前に置き換えます。
2.2. JBoss Web Server イメージストリームとテンプレートのインポート
Red Hat Container Registry から、Red Hat JBoss Web Server for OpenShift イメージストリームおよびテンプレートをインポートできます。JDK の最新の JBoss Web Server イメージストリームとテンプレートを OpenShift プロジェクトの namespace にインポートする必要があります。
手順
- カスタマーポータルの認証情報を使用して、Red Hat Container Registry にログインします。詳細は、Red Hat コンテナーレジストリーの認証 を参照してください。
使用している JDK バージョンに応じて、次のいずれかの手順を実行します。
OpenJDK 8 を使用している場合は、次のコマンドを入力します。
for resource in \ jws56-openjdk8-tomcat9-ubi8-basic-s2i.json \ jws56-openjdk8-tomcat9-ubi8-https-s2i.json \ jws56-openjdk8-tomcat9-ubi8-image-stream.json do oc replace -n openshift --force -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-webserver-5-openshift-image/jws56el8-v5.6.0/templates/${resource} done
上記のコマンドは、UBI8 JDK 8 イメージストリーム、
jboss-webserver56-openjdk8-tomcat9-openshift-ubi8
、およびコマンドで指定されたすべてのテンプレートをインポートします。OpenJDK 11 を使用している場合は、次のコマンドを入力します。
for resource in \ jws56-openjdk11-tomcat9-ubi8-basic-s2i.json \ jws56-openjdk11-tomcat9-ubi8-https-s2i.json \ jws56-openjdk11-tomcat9-ubi8-image-stream.json do oc replace -n openshift --force -f \ https://raw.githubusercontent.com/jboss-container-images/jboss-webserver-5-openshift-image/jws56el8-v5.6.0/templates/${resource} done
上記のコマンドは、UBI8 JDK 11 イメージストリーム、
jboss-webserver56-openjdk11-tomcat9-openshift-ubi8
、およびコマンドで指定されたすべてのテンプレートをインポートします。
2.3. 最新の JWS for OpenShift イメージのインポート
import-image
コマンドを使用して、利用可能な最新の JWS for OpenShift イメージをインポートできます。Red Hat は、OpenJDK 8 および OpenJDK 11 用の個別の JWS for OpenShift イメージを提供します。
手順
使用している JDK バージョンに応じて、次のいずれかの手順を実行します。
コア JBoss Web Server 5.6 tomcat 9 を OpenJDK 8 OpenShift イメージで更新するには、次のコマンドを入力します。
$ oc -n openshift import-image \ jboss-webserver56-openjdk8-tomcat9-openshift-ubi8:5.6.2
コア JBoss Web Server 5.6 tomcat 9 を OpenJDK 11 OpenShift イメージで更新するには、次のコマンドを入力します。
$ oc -n openshift import-image \ jboss-webserver56-openjdk11-tomcat9-openshift-ubi8:5.6.2
インポートする各イメージの最後にある 5.6.2
タグは、イメージストリームに設定されるストリームバージョンを参照します。
2.4. OpenShift S2I プロセスの JWS
OpenShift の source-to-image (S2I) プロセスを使用して、アプリケーションテンプレートのパラメーターと環境変数を使用することにより、OpenShift イメージ用の JWS を実行および設定できます。
JWS for OpenShift イメージの S2I プロセスは以下のようになります。
-
configuration
ソースディレクトリーに Maven のsettings.xml
ファイルが含まれている場合、settings.xml
ファイルは新しいイメージの$HOME/.m2/
ディレクトリーに移動されます。 ソースリポジトリーに
pom.xml
ファイルが含まれれている場合、$MAVEN_ARGS
環境変数の内容を使用して Maven ビルドがトリガーされます。デフォルトでは、
package
ゴールは、テストをスキップするための-DskipTests
引数と、Red Hat GA リポジトリーを有効にするための-Dcom.redhat.xpaas.repo.redhatga
引数を含むopenshift
プロファイルで使用されます。成功した Maven ビルドの結果は、
/opt/jws-5.6/tomcat/webapps
ディレクトリーにコピーされます。これには、$ARTIFACT_DIR
環境変数によって指定されたソースディレクトリーからの WAR ファイルがすべて含まれます。$ARTIFACT_DIR
のデフォルト値はtarget/
ディレクトリーです。$MAVEN_ARGS_APPEND
環境変数を使用して Maven 引数を変更します。-
deployments
ソースディレクトリーのすべての WAR ファイルは、/opt/jws-5.6/tomcat/webapps
ディレクトリーにコピーされます。 -
Maven settings.xml ファイルを除く、
configuration
ソースディレクトリー内のすべてのファイルが/opt/jws-5.6/tomcat/conf/
ディレクトリーにコピーされます。 lib
ソースディレクトリー内のすべてのファイルが/opt/jws-5.6/tomcat/lib/
ディレクトリーにコピーされます。注記カスタム Tomcat 設定ファイルを使用する場合は、通常の Tomcat インストールで使用されるのと同じファイル名 (
context.xml
やserver.xml
など) を使用します。
カスタム Maven アーティファクトリーポジトリミラーを使用するように S2I プロセスを設定する方法の詳細は、アーティファクトリーポジトリーミラー を参照してください。
2.5. 既存の Maven バイナリーを使用した OpenShift アプリケーションの JWS の作成
既存の Maven バイナリーを使用して、OpenShift アプリケーション用の JWS を作成できます。oc start-build
コマンドを使用して、既存のアプリケーションを OpenShift にデプロイできます。
この手順では、tomcat-websocket-chat クイックスタートの例に基づいたサンプルアプリケーションを作成する方法を示します。
前提条件
JWS for OpenShift にデプロイするアプリケーション用の既存の
.war
、.ear
、または.jar
ファイルがあるか、アプリケーションをローカルでビルドしている。たとえば、
tomcat-websocket-chat
アプリケーションをローカルでビルドするには、次の手順を実行します。ソースコードを複製するには、次のコマンドを入力します。
$ git clone https://github.com/jboss-openshift/openshift-quickstarts.git
Red Hat JBoss Middleware Maven リポジトリーの設定 で説明するように、Red HatJBoss Middleware Maven リポジトリーを設定します。
Maven リポジトリーの詳細については、Red Hat JBoss Enerprise Maven リポジトリー の Web ページを参照してください。
アプリケーションをビルドするには、以下のコマンドを入力します。
$ cd openshift-quickstarts/tomcat-websocket-chat/ $ mvn clean package
上記のコマンドにより、次の出力が生成されます。
[INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Tomcat websocket example 1.2.0.Final [INFO] ------------------------------------------------------------------------ ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 01:28 min [INFO] Finished at: 2018-01-16T15:59:16+10:00 [INFO] Final Memory: 19M/271M [INFO] ------------------------------------------------------------------------
手順
ローカルファイルシステムで、バイナリービルド用のソースディレクトリーと
deployments
サブディレクトリーを作成します。たとえば、
tomcat-websocket-chat
アプリケーション用に/ocp
ソースディレクトリーと/deployments
サブディレクトリーを作成するには、次のコマンドを入力します。$ cd openshift-quickstarts/tomcat-websocket-chat/ $ mkdir -p ocp/deployments
注記ソースディレクトリーには、Maven バイナリーに含まれていないアプリケーションで必要なコンテンツを含めることができます。詳細は、OpenShift S2I プロセスの JWS を参照してください。
.war
、.ear
、または.jar
バイナリーファイルをdeployments
サブディレクトリーにコピーします。たとえば、サンプル tomcat-websocket-chat アプリケーションの
.war
ファイルをコピーするには、次のコマンドを入力します。$ cp target/websocket-chat.war ocp/deployments/
注記上記の例では、
target/websocket-chat.war
が、コピーするバイナリーファイルへのパスです。ソースディレクトリーの
deployments
サブディレクトリーにあるアプリケーションアーカイブは、OpenShift 上にビルドされているイメージの$JWS_HOME/tomcat/webapps/
ディレクトリーにコピーされます。アプリケーションを正常にデプロイできるようにするには、Web アプリケーションデータを含むディレクトリー階層が正しく構造化されていることを確認する必要があります。詳細は、OpenShift S2I プロセスの JWS を参照してください。OpenShift インスタンスにログインします。
$ oc login <url>
必要に応じて新規プロジェクトを作成します。
以下に例を示します。
$ oc new-project jws-bin-demo
注記前の例では、
jws-bin-demo
が作成するプロジェクトの名前です。アプリケーションに使用する OpenShift イメージストリームの JWS を特定します。
$ oc get is -n openshift | grep ^jboss-webserver | cut -f1 -d ' '
上記のコマンドは、次のタイプの出力を生成します。
jboss-webserver56-openjdk8-tomcat9-openshift-ubi8
注記-n openshift
オプションは、使用するプロジェクトを指定します。oc get is -n openshift
コマンドは、openshift
プロジェクトからイメージストリームリソースを取得します。新しいビルド設定を作成し、イメージストリームとアプリケーション名を指定していることを確認します。
たとえば、サンプル tomcat-websocket-chat アプリケーションの新しいビルド設定を作成するには、次のようにします。
$ oc new-build --binary=true \ --image-stream=jboss-webserver56-openjdk8-tomcat9-openshift-ubi8:latest\* --name=jws-wsch-app
注記上記の例では、
jws-wsch-app
が JWS for OpenShift アプリケーションの名前です。上記のコマンドは、次のタイプの出力を生成します。
--> Found image 8c3b85b (4 weeks old) in image stream "openshift/jboss-webserver56-tomcat9-openshift" under tag "latest" for "jboss-webserver56" JBoss Web Server 5.6 -------------------- Platform for building and running web applications on JBoss Web Server 5.6 - Tomcat v9 Tags: builder, java, tomcat9 * A source build using binary input will be created * The resulting image will be pushed to image stream "jws-wsch-app:latest" * A binary build was created, use 'start-build --from-dir' to trigger a new build --> Creating resources with label build=jws-wsch-app ... imagestream "jws-wsch-app" created buildconfig "jws-wsch-app" created --> Success
バイナリービルドを開始します。
以下に例を示します。
$ oc start-build jws-wsch-app --from-dir=./ocp --follow
注記上記の例では、
jws-wsch-app
は JWS for OpenShift アプリケーションの名前であり、ocp
はソースディレクトリーの名前です。上記のコマンドは、OpenShift イメージビルドのバイナリー入力用に作成したソースディレクトリーを使用するよう OpenShift に指示します。
上記のコマンドは、次のタイプの出力を生成します。
Uploading directory "ocp" as binary input for the build ... build "jws-wsch-app-1" started Receiving source from STDIN as archive ... Copying all deployments war artifacts from /home/jboss/source/deployments directory into `/opt/jws-5.6/tomcat/webapps` for later deployment... '/home/jboss/source/deployments/websocket-chat.war' -> '/opt/jws-5.6/tomcat/webapps/websocket-chat.war' Pushing image 172.30.202.111:5000/jws-bin-demo/jws-wsch-app:latest ... Pushed 0/7 layers, 7% complete Pushed 1/7 layers, 14% complete Pushed 2/7 layers, 29% complete Pushed 3/7 layers, 49% complete Pushed 4/7 layers, 62% complete Pushed 5/7 layers, 92% complete Pushed 6/7 layers, 100% complete Pushed 7/7 layers, 100% complete Push successful
イメージに基づいて新しい OpenShift アプリケーションを作成します。
以下に例を示します。
$ oc new-app jws-wsch-app
注記上記の例では、
jws-wsch-app
が JWS for OpenShift アプリケーションの名前です。上記のコマンドは、次のタイプの出力を生成します。
--> Found image e5f3a6b (About a minute old) in image stream "jws-bin-demo/jws-wsch-app" under tag "latest" for "jws-wsch-app" JBoss Web Server 5.6 -------------------- Platform for building and running web applications on JBoss Web Server 5.6 - Tomcat v9 Tags: builder, java, tomcat9 * This image will be deployed in deployment config "jws-wsch-app" * Ports 8080/tcp, 8443/tcp, 8778/tcp will be load balanced by service "jws-wsch-app" * Other containers can access this service through the hostname "jws-wsch-app" --> Creating resources ... deploymentconfig "jws-wsch-app" created service "jws-wsch-app" created --> Success Application is not exposed. You can expose services to the outside world by executing one or more of the commands below: 'oc expose svc/jws-wsch-app' Run 'oc status' to view your app.
サービスを公開して、アプリケーションがユーザーにアクセスできるようにします。
たとえば、サンプル
jws-wsch-app
アプリケーションにアクセスできるようにするには、次の手順を実行します。公開するサービスの名前を確認します。
$ oc get svc -o name
上記のコマンドは、次のタイプの出力を生成します。
service/jws-wsch-app
サービスを公開するには、以下を実行します。
$ oc expose svc/jws-wsch-app
上記のコマンドは、次のタイプの出力を生成します。
route "jws-wsch-app" exposed
公開されたルートのアドレスを取得します。
oc get routes --no-headers -o custom-columns='host:spec.host' jws-wsch-app
Web ブラウザーを開き、URL を入力してアプリケーションにアクセスします。
たとえば、サンプル
jws-wsch-app
アプリケーションにアクセスするには、次の URL を入力します。\http://<address_of_exposed_route>/websocket-chat
注記前の例で、
<address_of_exposed_route>
をデプロイメントに適した値に置き換えます。
関連情報
-
oc start-build
コマンド
2.6. ソースコードから JWS for OpenShift アプリケーションを作成します。
ソースコードから JWS for OpenShift アプリケーションを作成できます。
ソースコードから新規 OpenShift アプリケーションを作成する方法は、OpenShift.com - ソースコードからのアプリケーションの作成 を参照してください。
前提条件
- アプリケーションデータが正しく構造化されている。詳細は、OpenShift S2I プロセスの JWS を参照してください。
手順
OpenShift インスタンスにログインします。
$ oc login <url>
必要に応じて新規プロジェクトを作成します。
$ oc new-project <project-name>
注記前の例で、
<project-name>
を作成するプロジェクトの名前に置き換えます。アプリケーションに使用する OpenShift イメージストリームの JWS を特定します。
$ oc get is -n openshift | grep ^jboss-webserver | cut -f1 -d ' '
上記のコマンドは、次のタイプの出力を生成します。
jboss-webserver56-openjdk8-tomcat9-openshift-ubi8
注記-n openshift
オプションは、使用するプロジェクトを指定します。oc get is -n openshift
コマンドは、openshift
プロジェクトからイメージストリームリソースを取得します。Red Hat JBoss Web Server for OpenShift イメージを使用して、ソースコードから新しい OpenShift アプリケーションを作成します。
$ oc new-app \ _<source_code_location>_\ --image-stream=jboss-webserver56-openjdk8-tomcat9-openshift-ubi8\ --name=_<openshift_application_name>_
以下に例を示します。
$ oc new-app \ \https://github.com/jboss-openshift/openshift-quickstarts.git#main \ --image-stream=jboss-webserver56-openjdk8-tomcat9-openshift-ubi8\ --context-dir='tomcat-websocket-chat' \ --name=jws-wsch-app
上記のコマンドは、ソースコードをイメージに追加し、ソースコードをコンパイルします。上記のコマンドは、ビルド設定とサービスも作成します。
アプリケーションを公開するには、次の手順を実行します。
公開するサービスの名前を確認するには:
$ oc get svc -o name
上記のコマンドは、次のタイプの出力を生成します。
service/<openshift_application_name>
サービスを公開するには、以下を実行します。
$ oc expose svc/<openshift_application_name>
上記のコマンドは、次のタイプの出力を生成します。
route "<openshift_application_name>" exposed
公開されたルートのアドレスを取得するには、以下を実行します。
oc get routes --no-headers -o custom-columns='host:spec.host' <openshift_application_name>
Web ブラウザーを開き、次の URL を入力してアプリケーションにアクセスします。
\http://<address_of_exposed_route>/<java_application_name>
注記前の例で、
<address_of_exposed_route>
と<java_application_name>
をデプロイに適した値に置き換えます。
2.7. tomcat/lib/
ディレクトリーに追加の jar ファイルの追加
Docker を使用して、追加の Java アーカイブ (JAR) ファイルを tomcat/lib
ディレクトリーに追加できます。
手順
Docker でイメージを開始します。
docker run --network host -i -t -p 8080:8080 ImageURL
CONTAINER ID
を検索します。docker ps | grep <ImageName>
ライブラリーを
tomcat/lib/
ディレクトリーにコピーします。docker cp <yourLibrary> <CONTAINER ID>:/opt/jws-5.6/tomcat/lib/
新規イメージへの変更のコミット
docker commit <CONTAINER ID> <NEW IMAGE NAME>
新規イメージタグの作成
docker tag <NEW IMAGE NAME>:latest <NEW IMAGE REGISTRY URL>:_<TAG>_
イメージをレジストリーにプッシュします。
docker push <NEW IMAGE REGISTRY URL>
第3章 OpenShift の JWS Operator
Operator Framework は Operator という Kubernetes ネイティブアプリケーションを効果的かつ自動化された拡張性のある方法で管理するためのツールキットです。Operator を使用すると、Kubernetes 上で実行されている複雑なステートフルアプリケーションを簡単に管理できます。すべての Operator は、Operator SDK、Operator Lifecycle Manager、および OperatorHub.io の 3 つの主要コンポーネントに基づいています。これらのツールを使用すると、独自のオペレーターを開発し、Kubernetes クラスターで使用する Operator を管理し、コミュニティーが作成する Operator を検出したり、共有したりできます。
3.1. JBoss Web Server Operator
Red Hat JBoss Web Server (JWS) は、OpenShift イメージの JWS を管理するために使用できる Operator を提供します。JWS Operator for OpenShift をビルド、テスト、およびパッケージ化できます。
JWS Operator は、OpenShift セットアップ用の標準 JWS とは異なる環境変数を使用します。JWS Operator が使用する環境変数の詳細は、Parameters to use in CRD を参照してください。
このリリースでは、Use Session Clustering
機能はテクノロジープレビュー機能としてのみ使用できます。セッションクラスターリングは、デフォルトで Off
に設定されています。現在の Operator バージョンは、DNS の制限により制限されている DNS Membership Provider
を使用します。InetAddress.getAllByName()
の結果はキャッシュされます。つまり、スケールアップ中にセッションのレプリケーションが機能しない可能性があります。
このドキュメントの手順に従って、JWS Operator をインストールし、既存の JWS イメージをデプロイし、クラスターから Operator を削除できます。準備されたイメージを展開するか、既存のイメージストリームからイメージを構築するための、より高速で詳細度の低いガイドについては、QuickStart ガイドを参照してください。
Red Hat は、JWS 5.4 以降のバージョンのイメージをサポートしています。JWS 5.4 より前のイメージはサポートされていません。
3.2. Operator グループ
Operator グループは、OLM がインストールされた Operator にマルチテナント設定を提供する Operator Lifecycle Manger (OLM) リソースです。Operator グループは、OperatorGroup
オブジェクトと同じ namespace にデプロイされたすべての Operator に対してロールベースのアクセス制御 (RBAC) を生成するターゲット namespace を選択します。
Operator を namespace にサブスクライブする場合、namespace に Operator と同じ InstallModeType
設定を使用する OperatorGroup
オブジェクトがあることを確認する必要があります。InstallModeType
設定は AllNamespaces
および SingleNamespace
です。
次のガイドラインを考慮してください。
-
インストールする Operator が
AllNamespaces
モードを使用する場合、openshift-operators
namespace は既に適切な Operator グループを提供します。 -
インストールする Operator が
SingleNamespace
モードを使用する場合、その namespace に Operator グループを 1 つだけ作成する必要があります。
関連情報
3.3. JWS Operator 2.0 リリースの新機能
JWS Operator 2.0 リリースは、シームレスな統合などのレベル-2 Operator 機能を提供します。JWS Operator 2.0 は、Red Hat JBoss Web Server メータリングラベルもサポートし、いくつかの強化されたカスタムリソース定義 (CRD) パラメーターを含みます。
レベル 2 Operator の能力
JWS Operator 2.0 は、次のレベル 2 Operator 機能を提供します。
- シームレスなアップグレードを実現
- パッチおよびマイナー バージョンアップグレードをサポート
- JWS Operator 1.1.x によってデプロイされた Web サーバーを管理します。
新しいイメージに対するレベル 2 のシームレスな統合の有効化
DeploymentConfig
オブジェクト定義には、新しいイメージがイメージストリームにプッシュされたときに、OpenShift が新しい Pod をデプロイするために使用するトリガーが含まれています。イメージストリームは新しいイメージのリポジトリーを監視できます。また、新しいイメージが使用可能であることをイメージストリームに指示することもできます。
手順
プロジェクト名前空間で、
oc import-image
コマンドを使用してイメージストリームを作成し、イメージのタグやその他の情報をインポートします。以下に例を示します。
oc import-image <my-image>-imagestream:latest \ --from=quay.io/$user/<my-image>:latest \ --confirm
前の例では、出現する
<my-image>
をインポートするイメージの名前に置き換えます。上記のコマンドは、
quay.io/$user/<my-image>
イメージの情報をインポートして<my-image>-imagestream
という名前のイメージストリームを作成します。イメージストリームの形式と管理の詳細については、イメージストリームの管理 を参照してください。イメージストリームが更新されるたびに JWS Operator がデプロイする Web アプリケーション用の
WebServer
種類のカスタムリソースを作成します。YAML ファイル形式でカスタムリソースを定義できます。以下に例を示します。
apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name:
<my-image>
spec: # Add fields here applicationName: my-app useSessionClustering: true replicas: 2 webImageStream: imageStreamNamespace:<project-name>
imageStreamName:<my-image>
-imagestreamoc tag
コマンドを使用して、イメージストリームへの更新をトリガーします。以下に例を示します。
oc tag quay.io/$user/<my-image> <my-image>-imagestream:latest --scheduled
上記のコマンドにより、OpenShift Container Platform は指定されたイメージストリームタグを定期的に更新します。この期間は、デフォルトで 15 分に設定されているクラスター全体の設定です。
既存のイメージを再構築するためのレベル 2 のシームレスな統合
BuildConfig
オブジェクト定義には、イメージストリームの更新のトリガーと、Webhook が Git または GitHub によってトリガーされたときにイメージの再構築を可能にする GitHub または Generic Webhook のいずれかである Webhook が含まれています。
Webhook のシークレットの作成、およびカスタムリソース WebServer ファイルでの汎用 Webhook または GitHub Webhook の設定の詳細については、CRD で使用するパラメーター を参照してください。
Red Hat JBoss Web Server 計測ラベルのサポート
JWS Operator 2.0 は、JWS Operator が作成する Red Hat JBoss Web Server Pod に計量ラベルを追加する機能をサポートします。
Red Hat JBoss Web Server では、以下のメータリングラベルを使用できます。
-
com.company:Red_Hat
-
rht.prod_name:Red_Hat_Runtimes
-
rht.prod_ver:2022-Q2
-
rht.comp:JBoss_Web_Server
-
rht.comp_ver:5.6.2
-
rht.subcomp:Tomcat 9
-
rht.subcomp_t: application
デプロイする Web アプリケーションのカスタムリソース WebServer
ファイルの metadata
セクションの下にラベルを追加できます。以下に例を示します。
---
apiVersion: web.servers.org/v1alpha1
kind: WebServer
metadata:
name: <my-image>
labels:
com.company: Red_Hat
rht.prod_name: Red_Hat_Runtimes
rht.prod_ver: 2022-Q2
rht.comp: JBoss_Web_Server
rht.comp_ver: 5.6.2
rht.subcomp: Tomcat 9
rht.subcomp_t: application
spec:
----
デプロイされた Web サーバーのラベルキーまたはラベル値を変更すると、JWS Operator は Web サーバー アプリケーションを再デプロイします。デプロイされた Web サーバーがソースコードから構築された場合、JWS Operator は Web サーバー アプリケーションも再構築します。
webImage
パラメーターの強化
JWS Operator 2.0 リリースでは、CRD の webImage
パラメーターに次の追加フィールドが含まれています。
imagePullSecret
JWS Operator がリポジトリーからイメージをプルするために使用するシークレット
注記シークレットにはキー
.dockerconfigjson
が含まれている必要があります。JWS Operator はシークレット (例:--authfile /mount_point/.dockerconfigjson
) をマウントして使用し、リポジトリーからイメージをプルします。Secret
オブジェクト定義ファイルには、サーバーのユーザー名とパスワードの値またはトークンが含まれている場合があり、イメージストリーム内のイメージ、ビルダー イメージ、および JWS Operator によってビルドされたイメージにアクセスできます。webApp
JWS Operator が Web サーバーアプリケーションをビルドする方法を記述するパラメーターのセット
webApp
パラメーターの強化
JWS Operator 2.0 リリースでは、CRD の webApp
パラメーターに次の追加フィールドが含まれています。
name
Web サーバーアプリケーションの名前
sourceRepositoryURL
アプリケーションのソースファイルがある URL
sourceRepositoryRef
Operator が使用するソースリポジトリーのブランチ
sourceRepositoryContextDir
pom.xml
ファイルが配置され、mvn install
コマンドを実行する必要があるサブディレクトリーwebAppWarImage
JWS Operator がビルドされたイメージをプッシュするイメージの URL
webAppWarImagePushSecret
JWS Operator がイメージをリポジトリーにプッシュするために使用するシークレット
builder
Web アプリケーションを構築し、イメージを作成してイメージリポジトリーにプッシュするために必要なすべての情報を含む一連のパラメーター
注記ビルダーが正常に動作し、異なるユーザー ID でコマンドを実行できるようにするには、ビルダーが
anyuid
セキュリティーコンテキスト制約 (SCC) にアクセスできる必要があります。ビルダーに
anyuid
SCC へのアクセス権を付与するには、次のコマンドを入力します。oc adm policy add-scc-to-user anyuid -z builder
builder
パラメーターには以下のフィールドが含まれます。image
Web アプリケーションがビルドされるコンテナーのイメージ (例:
quay.io/$user/tomcat10-buildah
)imagePullSecret
JWS Operator がリポジトリーからビルダー イメージをプルするために使用するシークレット (指定されている場合)
applicationBuildScript
ビルダー イメージがアプリケーションの
.war
ファイルをビルドし、それを/mnt
ディレクトリーに移動するために使用するスクリプト注記このパラメーターの値を指定しない場合、ビルダー イメージは Maven と Buildah を使用するデフォルトのスクリプトを使用します。
関連情報
3.4. JWS Operator のインストール
以下のいずれかの方法を使用して、OpenShift 用の JBoss Web Server (JWS) Operator をインストールできます。
3.4.1. Web コンソールを使用した JWS Operator のインストール
OpenShift Web コンソールを使用して JWS Operator をインストールできます。
前提条件
-
cluster-admin
および Operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
Web コンソールを開き、Operator タブに移動します。
OpenShift OperatorHub が開きます。
JWS を検索し、JWS Operator を選択します。
新しいメニューが表示されます。
- 使用する容量レベルを選択します。
- Operator をインストールするには、コンソールの開始時に Install をクリックします。
Operator のインストールをセットアップするには、次の手順を実行します。
Operator をインストールするクラスターの namespace を指定して、インストールモードを指定します。
注記namespace を指定しない場合、Operator はデフォルトでクラスター上のすべての namespace にインストールされます。
JWS Operator が使用可能な更新チャネルを指定します。
注記JWS Operator は現在 1 つのチャネルからのみ利用できます。
Automatic 更新または Manual 更新を選択して、承認戦略を指定します。
注記Automatic 更新を選択した場合、Operator の新しいバージョンが利用可能になると、Operator Lifecycle Manager (OLM) は Operator の実行中のインスタンスを自動的にアップグレードします。
Manual (手動) 更新を選択した場合、Operator の新しいバージョンが使用できるようになると、OLM によって更新リクエストが作成されます。クラスター管理者は、更新リクエストを手動で承認して、Operator が新しいバージョンに更新されるようにする必要があります。
Install をクリックします。
注記Manual 承認戦略を選択した場合は、インストールが完了する前にインストール計画を承認する必要があります。JWS Operator が Operators タブの Installed Operators セクションに表示されるようになりました。
3.4.2. コマンドラインからの JWS Operator のインストール
oc
コマンドラインツールを使用して JWS Operator をインストールできます。コマンドラインから JWS Operator をインストールする手順には、Operator でサポートされている installModes と使用可能なチャネルの確認、Operator グループの作成、および Subscription オブジェクトの作成が含まれます。
Web コンソールを使用して JWS Operator をインストールし、Operator が SingleNamespace
モードを使用している場合、OperatorGroup
および Subscription
オブジェクトが自動的にインストールされます。
前提条件
- Operator インストールパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにデプロイできること。
-
ローカルシステムに
oc
ツールがインストールされている。
手順
JWS Operator を調べるには、次の手順を実行します。
JWS Operator でサポートされているインストールモードを確認するには、次のコマンドを入力します。
$ oc get packagemanifests -n openshift-marketplace | grep jws
上記のコマンドは、次のタイプの出力を生成します。
jws-operator Red Hat Operators 16h
JWS Operator で使用可能なチャネルを確認するには、次のコマンドを入力します。
$ oc describe packagemanifests jws-operator -n openshift-marketplace | grep "Catalog Source"
上記のコマンドは、次のタイプの出力を生成します。
Catalog Source: redhat-operators
Operator グループを作成するには、次の手順を実行します。
Operator グループの実際のリストを確認するには、次のコマンドを入力します。
$ oc get operatorgroups -n <project_name>
注記前の例で、<project_name> を OpenShift プロジェクト名に置き換えます。
上記のコマンドは、次のタイプの出力を生成します。
NAME AGE mygroup 17h
OperatorGroup
オブジェクトの YAML ファイルを作成します。以下に例を示します。
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <operatorgroup_name> namespace: <project_name> spec: targetNamespaces: - <project_name>
注記前の例で、
<project_name>
を、Operator をインストールするプロジェクトの namespace (oc project -q
) に置き換えます。`<operatorgroup_name>
をOperatorGroup
オブジェクトの名前に置き換えます。YAML ファイルから
OperatorGroup
オブジェクトを作成します。$ oc apply -f <filename>.yaml
注記前の例の
<filename>.yaml
を、OperatorGroup
オブジェクト用に作成した YAML ファイルの名前に置き換えます。
サブスクリプションオブジェクトを作成するには、次の手順を実行します。
Subscription
オブジェクトの YAML ファイルを作成します。以下に例を示します。
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: jws-operator namespace: <project_name> spec: channel: alpha name: jws-operator source: redhat-operators sourceNamespace: openshift-marketplace
注記前の例で、
<project_name>
を、Operator をインストールするプロジェクトの namespace (oc project -q
) に置き換えます。Operator がAllNamespaces
モードを使用している場合、<project_name>
をopenshift-operators
に置き換えます。Operator で使用可能なチャネル (
redhat-operators
など) を確認したときのコマンドライン出力に基づいて、source
設定がCatalog source
値と一致していることを確認します。YAML ファイルから
Subscription
オブジェクトを作成します。$ oc apply -f <filename>.yaml
注記前の例の
<filename>.yaml
を、Subscription
オブジェクト用に作成した YAML ファイルの名前に置き換えます。
検証
JWS Operator が正常にインストールされたことを確認するには、次のコマンドを入力します。
$ oc get csv -n <project_name>
注記前の例で、
<project_name>
を Operator をインストールしたプロジェクトの namespace に置き換えます。上記のコマンドは、次のタイプの出力を生成します。
名前 DISPLAY バージョン REPLACE PHASE jws-operator.V<version>
JBoss Web Server Operator
<version>
Succeeded
注記上記の例では、
<version>
は Operator バージョンを参照します (例:1.1.0
)。
3.5. 既存の JWS イメージのデプロイ
OpenShift Web コンソールを使用して、既存の JWS イメージをデプロイできます。
前提条件
Web コンソールまたはコマンドラインを使用して JWS Operator をインストールしました。
JWS Operator がインストールされていることを確認するには、次のコマンドを入力します。
$ oc get deployment.apps/jws-operator
上記のコマンドは、次のタイプの出力を生成します。
NAME READY UP-TO-DATE AVAILABLE AGE jws-operator 1/1 1 1 15h
注記より詳細な出力を表示する場合は、次のコマンドを使用できます。
oc describe deployment.apps/jws-operator
手順
-
イメージを準備し、イメージを表示する場所 (例:
quay.io/<USERNAME>/tomcat-demo:latest
) にプッシュします。 Custom Resource
Web サーバー用の YAML ファイルを作成するには、次の手順を実行します。-
たとえば、
webservers_cr.yaml
という名前のファイルを作成します。 詳細を次の形式で入力します。
apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: example-image-webserver spec: # Add fields here applicationName: jws-app replicas: 2 webImage: applicationImage: quay.io/<USERNAME>/tomcat-demo:latest
-
たとえば、
Web アプリケーションをデプロイするには、次の手順を実行します。
- Web アプリケーションを作成したディレクトリーに移動します。
以下のコマンドを入力します。
$ oc apply -f webservers_cr.yaml
上記のコマンドにより、次の出力が生成されます。
webserver/example-image-webserver created
注記Operator はルートを自動的に作成します。
Operator が作成するルートを確認します。
$ oc get routes
オプション:前の手順で作成した
webserver
を削除します。$ oc delete webserver example-image-webserver
注記または、YAML ファイルを削除して
webserver
を削除することもできます。以下に例を示します。oc delete -f webservers_cr.yaml
関連情報
3.6. JWS Operator の削除
次のいずれかの方法を使用して、クラスターから JWS Operator を削除できます。
3.6.1. Web コンソールを使用した JWS Operator の削除
OpenShift Web コンソールを使用して、クラスターから JWS Operator を削除できます。
前提条件
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにデプロイできる。注記cluster admin
のアクセス許可がない場合は、この要件を回避できます。詳しくは、非クラスター管理者による Operator のインストールの許可 を参照してください。
手順
- Web コンソールを開き、Operators Operator Installed Operators をクリックします。
Actions メニューを選択し、Uninstall Operator をクリックします。
注記Uninstall Operator オプションは、Operator、Operator デプロイメント、および Pod を自動的に削除します。
Operator を削除しても、CRD または CR を含む Operator のカスタムリソース定義またはカスタムリソースは削除されません。Operator がクラスターにアプリケーションをデプロイした場合、または Operator がクラスター外のリソースを設定した場合、これらのアプリケーションとリソースを手動でクリーンアップする必要があります。
3.6.2. コマンドラインからの JWS Operator の削除
oc
コマンドラインツールを使用して、クラスターから JWS Operator を削除できます。
前提条件
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにデプロイできる。注記cluster admin
のアクセス許可がない場合は、この要件を回避できます。詳しくは、非クラスター管理者による Operator のインストールの許可 を参照してください。-
ローカルシステムに
oc
ツールがインストールされている。
手順
サブスクライブした Operator の現在のバージョンを確認します。
$ oc get subscription jws-operator -n <project_name> -o yaml | grep currentCSV
注記上記のコマンドで、
<project_name>
を Operator をインストールしたプロジェクトの namespace に置き換えます。Operator がすべての namespace にインストールされている場合は、<project_name>
をopenshift-operators
に置き換えます。上記のコマンドは、次の出力を生成します。ここで、
v<version>
は Operator のバージョン (たとえば、v1.1.0
) を指します。f:currentCSV: {} currentCSV: jws-operator.v<version>
Operator のサブスクリプションを削除します。
$ oc delete subscription jws-operator -n <project_name>
注記上記のコマンドで、
<project_name>
を Operator をインストールしたプロジェクトの namespace に置き換えます。Operator がすべての namespace にインストールされている場合は、<project_name>
をopenshift-operators
に置き換えます。前の手順で取得した currentCSV 値を使用して、ターゲット namespace の Operator の CSV を削除します。
$ oc delete clusterserviceversion <currentCSV> -n <project_name>
注記上記のコマンドで、
<project_name>
を Operator をインストールしたプロジェクトの namespace に置き換え、<currentCSV>
を前の手順で取得したcurrentCSV value
(たとえば、jws-operator.v<version>) に置き換えます。.上記のコマンドは、次のタイプの出力を生成します。
clusterserviceversion.operators.coreos.com "jws-operator.v<version>" deleted
注記上記のコマンドでは、
<project_name>
はオペレーターをインストールしたプロジェクトの namespace を参照し、v<version>
はオペレーターバージョン (v1.1.0
など) を参照します。Operator がすべての namespace にインストールされていた場合は、<project_name>
の代わりにopenshift-operators
を使用します。
第4章 Red Hat OpenShift 向け Red Hat JBoss Web Server メータリングラベル
メータリングラベルを Red Hat JBoss Web Server Pod に追加し、OpenShift Metering Operator を使用して Red Hat サブスクリプションの詳細を確認できます。
- メータリングラベルは、Operator またはテンプレートがデプロイおよび管理する Pod に追加しないでください。
- OpenShift Container Platform バージョン 4.8 以前では、Metering Operator を使用してラベルを Pod に適用できます。バージョン 4.9 以降は、Metering Operator は直接置き換えなしには利用できなくなりました。
Red Hat JBoss Web Server では、以下のメータリングラベルを使用できます。
-
com.company:Red_Hat
-
rht.prod_name:Red_Hat_Runtimes
-
rht.prod_ver:2022-Q2
-
rht.comp:JBoss_Web_Server
-
rht.comp_ver:5.6.2
-
rht.subcomp:Tomcat 9
-
rht.subcomp_t: application
付録A S2I スクリプトと Maven
Red Hat JBoss Web Server for OpenShift イメージには、S2I スクリプト と Maven が含まれています。
A.1. OpenShift の Maven アーティファクトリーポジトリミラーと JWS
Maven リポジトリーには、プロジェクト Java アーカイブ (JAR) ファイル、ライブラリー JAR ファイル、プラグイン、またはその他のプロジェクト固有のアーティファクトなど、ビルドアーティファクトと依存関係が保持されます。Maven リポジトリーは、source-to-image (S2I) ビルドの実行中にアーティファクトをダウンロードできる場所も定義します。Maven Central Repository の使用に加えて、ローカルのカスタムリポジトリー (mirror) もデプロイします。
ローカルミラーには、次の利点があります。
- 地理的に近く、高速な同期ミラーを使用できる。
- リポジトリーコンテンツの制御が強化されます。
- パブリックサーバーやリポジトリーに依存することなく、さまざまなチーム (開発者および継続的インテグレーション (CI)) 間でアーティファクトを共有できる可能性があります。
- ビルド時間が改善される。
Maven リポジトリーマネージャー はミラーへのローカルキャッシュとして機能できます。リポジトリーマネージャーが既にデプロイされていて、指定された URL の場所で外部からアクセスできる場合、S2I ビルドはこのリポジトリーを使用できます。MAVEN_MIRROR_URL
環境変数をアプリケーションのビルド設定に追加することで、内部 Maven リポジトリーを使用できます。
A.1.1. 新しいビルド設定に内部 Maven リポジトリーを使用する
oc new-app
コマンドまたは oc new-build
コマンドで --build-env
オプションを指定することにより、MAVEN_MIRROR_URL
環境変数をアプリケーションの新しいビルド設定に追加できます。
手順
以下のコマンドを入力します。
$ oc new-app \ https://github.com/jboss-openshift/openshift-quickstarts.git#main \ --image-stream=jboss-webserver56-openjdk8-tomcat9-openshift-ubi8:latest\* --context-dir='tomcat-websocket-chat' \ --build-env MAVEN_MIRROR_URL=\http://10.0.0.1:8080/repository/internal/ \ --name=jws-wsch-app
注記上記のコマンドは、リポジトリーマネージャーが既にデプロイされており、
http://10.0.0.1:8080/repository/internal/
でアクセスできることを前提としています。
A.1.2. 既存のビルド設定に内部 Maven リポジトリーを使用する
oc env
コマンドでビルド設定の名前を指定することにより、アプリケーションの既存のビルド設定に MAVEN_MIRROR_URL
環境変数を追加できます。
手順
MAVEN_MIRROR_URL
変数を必要とするビルド設定を特定します。$ oc get bc -o name
上記のコマンドは、次のタイプの出力を生成します。
buildconfig/jws
注記前の例では、jws はビルド設定の名前です。
MAVEN_MIRROR_URL
環境変数をbuildconfig/jws
に追加します。$ oc env bc/jws MAVEN_MIRROR_URL="http://10.0.0.1:8080/repository/internal/" buildconfig "jws" updated
ビルド設定が更新されたことを確認します。
$ oc env bc/jws --list # buildconfigs jws MAVEN_MIRROR_URL=http://10.0.0.1:8080/repository/internal/
-
oc start-build
を使用したアプリケーションの新規ビルドのスケジュール
アプリケーションのビルドプロセス中に、Maven の依存関係は、デフォルトのパブリックリポジトリーからではなく、リポジトリーマネージャーからダウンロードされます。ビルドプロセスが完了すると、ビルドプロセス中に取得および使用されるすべての依存関係がミラーに含まれます。
A.2. Red Hat JBoss Web Server for OpenShift イメージに含まれるスクリプト
Red Hat JBoss Web Server for OpenShift イメージには、Catalina を実行し、Maven を使用して .war
パッケージを作成およびデプロイするためのスクリプトが含まれています。
run
- Catalina (Tomcat) の実行
assemble
-
Maven を使用して Web アプリケーションソースをビルドし、
.war
ファイルを作成して、.war
ファイルを$JWS_HOME/tomcat/webapps
ディレクトリーに移動します。
A.3. OpenShift データソースの JWS
JWS for OpenShift は、次の 3 種類のデータソースを提供します。
- デフォルトの内部データソース
-
PostgreSQL、MySQL、および MongoDB のデータソースは、Red Hat レジストリーを介してデフォルトで OpenShift で利用できます。これらのデータソースでは、イメージストリーム用に追加の環境ファイルを設定する必要はありません。データベースを検出してデータソースとして使用できるようにするには、
DB_SERVICE_PREFIX_MAPPING
環境変数を OpenShift サービスの名前に設定します。 - その他の内部データソース
- これらのデータソースは OpenShift で実行されますが、デフォルトでは Red Hat レジストリーからは利用できません。OpenShift シークレットに追加される環境ファイルは、他の内部データソースの設定を提供します。
- 外部データソース
- これらのデータソースは OpenShift では実行されません。OpenShift シークレットに追加される環境ファイルは、外部データソースの設定を提供します。
ENV_FILES
プロパティー
プロジェクトの OpenShift シークレットにデータソースの環境変数を追加できます。ENV_FILES
プロパティーを使用して、テンプレート内でこれらの環境ファイルを呼び出すことができます。
DB_SERVICE_PREFIX_MAPPING
環境変数
データソースは、特定の環境変数の値に基づいて自動的に作成されます。DB_SERVICE_PREFIX_MAPPING
環境変数は、データソースの JNDI マッピングを定義します。
DB_SERVICE_PREFIX_MAPPING
変数に許可される値は、POOLNAME-DATABASETYPE=PREFIX
トリプレットのコンマ区切りリストです。各トリプレットは、次の値で設定されます。
-
POOLNAME
はデータソースのpool-name
として使用されます。 -
DATABASETYPE
は使用するデータベースドライバーです。 -
PREFIX
は、データソースを設定するために使用される環境変数の名前に使用される接頭辞です。
起動スクリプトは、イメージの起動時に実行される個別のデータソースを DB_SERVICE_PREFIX_MAPPING
環境変数に定義された各 POOLNAME-DATABASETYPE=PREFIX
トリプレットに対して作成します。
関連情報
A.4. OpenShift と互換性のある環境変数の JWS
source-to-image (S2I) build
コマンドを使用して環境変数を含めることにより、ビルド設定を変更できます。詳細は、Maven アーティファクトリーポジトリミラーおよび JWS for OpenShift を参照してください。
以下の表に、Red Hat JBoss Web Server for OpenShift イメージの有効な環境変数を示します。
変数名 | 表示名 | 説明 | 値の例 |
---|---|---|---|
ARTIFACT_DIR | 該当なし |
このディレクトリーからの | target |
APPLICATION_NAME | アプリケーション名 | アプリケーションの名前 | jws-app |
CONTEXT_DIR | コンテキストディレクトリー | ビルドする Git プロジェクト内のパス。root プロジェクトディレクトリーの場合は空です。 | tomcat-websocket-chat |
GITHUB_WEBHOOK_SECRET | Github Webhook Secret | GitHub トリガーシークレット | [a-zA-Z0-9]{8} からの式 |
GENERIC_WEBHOOK_SECRET | Generic Webhook Secret | 汎用ビルドトリガーシークレット | [a-zA-Z0-9]{8} からの式 |
HOSTNAME_HTTP | カスタム HTTP ルートのホスト名 | http サービスルートのカスタムホスト名。デフォルトホスト名の場合は空白のままにします。 | <application-name>-<project>.<default-domain-suffix> |
HOSTNAME_HTTPS | カスタム HTTPS ルートのホスト名 | https サービスルートのカスタムホスト名。デフォルトホスト名の場合は空白のままにします。 | <application-name>-<project>.<default-domain-suffix> |
IMAGE_STREAM_NAMESPACE | イメージストリーム名前空間 | Red Hat ミドルウェアイメージの ImageStreams がインストールされている名前空間 | openshift |
JWS_HTTPS_SECRET | シークレット名 | 証明書ファイルが含まれるシークレットの名前 | jws-app-secret |
JWS_HTTPS_CERTIFICATE | 証明書名 | シークレット内の証明書ファイルの名前 | server.crt |
JWS_HTTPS_CERTIFICATE_KEY | 証明書キー名 | シークレット内の証明書キーファイルの名前 | server.key |
JWS_HTTPS_CERTIFICATE_PASSWORD | 証明書のパスワード | 証明書のパスワード | P5ssw0rd |
SOURCE_REPOSITORY_URL | Git リポジトリー URL | アプリケーションの Git ソース URI | https://github.com/jboss-openshift/openshift-quickstarts.git |
SOURCE_REPOSITORY_REFERENCE | Git リファレンス | Git ブランチ/タグ参照 | 1.2 |
IMAGE_STREAM_NAMESPACE | イメージストリーム名前空間 | Red Hat ミドルウェアイメージの ImageStreams がインストールされている名前空間 | openshift |
MAVEN_MIRROR_URL | Maven ミラー URL | 設定する Maven ミラー/リポジトリーマネージャーの URL。 | http://10.0.0.1:8080/repository/internal/ |
付録B OpenShift 用の JWS 上のバルブ
以下の環境変数を定義して、バルブコンポーネントを関連付けられた Catalina コンテナーのリクエスト処理パイプラインに挿入することができます。
変数名 | 説明 | 値の例 | デフォルト値 |
---|---|---|---|
ENABLE_ACCESS_LOG | Access Log Valve を有効にして、標準出力チャンネルへのアクセスメッセージをログに記録します。 | true | false |
付録C OpenShift ログの確認
oc logs
コマンドを使用して、OpenShift ログ、または実行中のコンテナーのコンソールによって提供されるログを表示できます。
手順
以下のコマンドを入力します。
$ oc logs -f <pod_name> <container_name>
注記上記のコマンドで、
<pod_name>
と<container_name>
をデプロイに適した値に置き換えます。アクセスログは
/opt/jws-5.6/tomcat/logs/
ディレクトリーに保存されます。