Red Hat JBoss Web Server for OpenShift


Red Hat JBoss Web Server 5.6

Red Hat JBoss Web Server for OpenShift のインストールおよび使用

Red Hat Customer Content Services

概要

Red Hat JBoss Web Server for OpenShift の使用ガイド

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社の技術的な内容についてのフィードバックに感謝します。ご意見をお聞かせください。コメントの追加、Insights の提供、誤字の修正、および質問を行う必要がある場合は、ドキュメントで直接行うこともできます。

注記

Red Hat アカウントがあり、カスタマーポータルにログインしている必要があります。

カスタマーポータルからドキュメントのフィードバックを送信するには、以下の手順を実施します。

  1. Multi-page HTML 形式を選択します。
  2. ドキュメントの右上にある Feedback ボタンをクリックします。
  3. フィードバックを提供するテキストのセクションを強調表示します。
  4. ハイライトされたテキストの横にある Add Feedback ダイアログをクリックします。
  5. ページの右側のテキストボックスにフィードバックを入力し、送信 をクリックします。

フィードバックを送信すると、自動的に問題の追跡が作成されます。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 設定に使用または保存する必要がありません。

手順

  1. Red Hat カスタマーポータルの手順にしたがって、レジストリーサービスアカウントを使用して認証トークンを作成します
  2. トークンの Token Information ページで、OpenShift Secret タブをクリックし、トークンの OpenShift シークレットを含む YAML ファイルをダウンロードします。
  3. ダウンロードした YAML ファイルを使用して、OpenShift プロジェクトの認証トークンシークレットを作成します。

    以下に例を示します。

    oc create -f 1234567_myserviceaccount-secret.yaml
  4. 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 にインポートする必要があります。

手順

  1. カスタマーポータルの認証情報を使用して、Red Hat Container Registry にログインします。詳細は、Red Hat コンテナーレジストリーの認証 を参照してください。
  2. 使用している 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.xmlserver.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 アプリケーションをローカルでビルドするには、次の手順を実行します。

    1. ソースコードを複製するには、次のコマンドを入力します。

      $ git clone https://github.com/jboss-openshift/openshift-quickstarts.git
    2. Red Hat JBoss Middleware Maven リポジトリーの設定 で説明するように、Red HatJBoss Middleware Maven リポジトリーを設定します。

      Maven リポジトリーの詳細については、Red Hat JBoss Enerprise Maven リポジトリー の Web ページを参照してください。

    3. アプリケーションをビルドするには、以下のコマンドを入力します。

      $ 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] ------------------------------------------------------------------------

手順

  1. ローカルファイルシステムで、バイナリービルド用のソースディレクトリーと deployments サブディレクトリーを作成します。

    たとえば、tomcat-websocket-chat アプリケーション用に /ocp ソースディレクトリーと /deployments サブディレクトリーを作成するには、次のコマンドを入力します。

    $ cd openshift-quickstarts/tomcat-websocket-chat/
    $ mkdir -p ocp/deployments
    注記

    ソースディレクトリーには、Maven バイナリーに含まれていないアプリケーションで必要なコンテンツを含めることができます。詳細は、OpenShift S2I プロセスの JWS を参照してください。

  2. .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 を参照してください。

  3. OpenShift インスタンスにログインします。

    $ oc login <url>
  4. 必要に応じて新規プロジェクトを作成します。

    以下に例を示します。

    $ oc new-project jws-bin-demo
    注記

    前の例では、jws-bin-demo が作成するプロジェクトの名前です。

  5. アプリケーションに使用する 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 プロジェクトからイメージストリームリソースを取得します。

  6. 新しいビルド設定を作成し、イメージストリームとアプリケーション名を指定していることを確認します。

    たとえば、サンプル 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
  7. バイナリービルドを開始します。

    以下に例を示します。

    $ 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
  8. イメージに基づいて新しい 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.
  9. サービスを公開して、アプリケーションがユーザーにアクセスできるようにします。

    たとえば、サンプル jws-wsch-app アプリケーションにアクセスできるようにするには、次の手順を実行します。

    1. 公開するサービスの名前を確認します。

      $ oc get svc -o name

      上記のコマンドは、次のタイプの出力を生成します。

      service/jws-wsch-app
    2. サービスを公開するには、以下を実行します。

      $ oc expose svc/jws-wsch-app

      上記のコマンドは、次のタイプの出力を生成します。

      route "jws-wsch-app" exposed
  10. 公開されたルートのアドレスを取得します。

    oc get routes --no-headers -o custom-columns='host:spec.host' jws-wsch-app
  11. Web ブラウザーを開き、URL を入力してアプリケーションにアクセスします。

    たとえば、サンプル jws-wsch-app アプリケーションにアクセスするには、次の URL を入力します。

    \http://<address_of_exposed_route>/websocket-chat

    注記

    前の例で、<address_of_exposed_route> をデプロイメントに適した値に置き換えます。

関連情報

2.6. ソースコードから JWS for OpenShift アプリケーションを作成します。

ソースコードから JWS for OpenShift アプリケーションを作成できます。

ソースコードから新規 OpenShift アプリケーションを作成する方法は、OpenShift.com - ソースコードからのアプリケーションの作成 を参照してください。

前提条件

手順

  1. OpenShift インスタンスにログインします。

    $ oc login <url>
  2. 必要に応じて新規プロジェクトを作成します。

    $ oc new-project <project-name>
    注記

    前の例で、<project-name> を作成するプロジェクトの名前に置き換えます。

  3. アプリケーションに使用する 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 プロジェクトからイメージストリームリソースを取得します。

  4. 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

    上記のコマンドは、ソースコードをイメージに追加し、ソースコードをコンパイルします。上記のコマンドは、ビルド設定とサービスも作成します。

  5. アプリケーションを公開するには、次の手順を実行します。

    1. 公開するサービスの名前を確認するには:

      $ oc get svc -o name

      上記のコマンドは、次のタイプの出力を生成します。

      service/<openshift_application_name>
    2. サービスを公開するには、以下を実行します。

      $ oc expose svc/<openshift_application_name>

      上記のコマンドは、次のタイプの出力を生成します。

      route "<openshift_application_name>" exposed
  6. 公開されたルートのアドレスを取得するには、以下を実行します。

    oc get routes --no-headers -o custom-columns='host:spec.host' <openshift_application_name>
  7. 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 ディレクトリーに追加できます。

手順

  1. Docker でイメージを開始します。

    docker run --network host -i -t -p 8080:8080 ImageURL
  2. CONTAINER ID を検索します。

     docker ps | grep <ImageName>
  3. ライブラリーを tomcat/lib/ ディレクトリーにコピーします。

    docker cp <yourLibrary> <CONTAINER ID>:/opt/jws-5.6/tomcat/lib/
  4. 新規イメージへの変更のコミット

    docker commit <CONTAINER ID> <NEW IMAGE NAME>
  5. 新規イメージタグの作成

    docker tag <NEW IMAGE NAME>:latest <NEW IMAGE REGISTRY URL>:_<TAG>_
  6. イメージをレジストリーにプッシュします。

    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 をデプロイするために使用するトリガーが含まれています。イメージストリームは新しいイメージのリポジトリーを監視できます。また、新しいイメージが使用可能であることをイメージストリームに指示することもできます。

手順

  1. プロジェクト名前空間で、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 という名前のイメージストリームを作成します。イメージストリームの形式と管理の詳細については、イメージストリームの管理 を参照してください。

  2. イメージストリームが更新されるたびに 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>-imagestream
  3. oc 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 クラスターにアクセスできる。

手順

  1. Web コンソールを開き、Operator タブに移動します。

    OpenShift OperatorHub が開きます。

  2. JWS を検索し、JWS Operator を選択します。

    新しいメニューが表示されます。

  3. 使用する容量レベルを選択します。
  4. Operator をインストールするには、コンソールの開始時に Install をクリックします。
  5. Operator のインストールをセットアップするには、次の手順を実行します。

    1. Operator をインストールするクラスターの namespace を指定して、インストールモードを指定します。

      注記

      namespace を指定しない場合、Operator はデフォルトでクラスター上のすべての namespace にインストールされます。

    2. JWS Operator が使用可能な更新チャネルを指定します。

      注記

      JWS Operator は現在 1 つのチャネルからのみ利用できます。

    3. Automatic 更新または Manual 更新を選択して、承認戦略を指定します。

      注記

      Automatic 更新を選択した場合、Operator の新しいバージョンが利用可能になると、Operator Lifecycle Manager (OLM) は Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual (手動) 更新を選択した場合、Operator の新しいバージョンが使用できるようになると、OLM によって更新リクエストが作成されます。クラスター管理者は、更新リクエストを手動で承認して、Operator が新しいバージョンに更新されるようにする必要があります。

  6. 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 ツールがインストールされている。

手順

  1. JWS Operator を調べるには、次の手順を実行します。

    1. JWS Operator でサポートされているインストールモードを確認するには、次のコマンドを入力します。

      $ oc get packagemanifests -n openshift-marketplace | grep jws

      上記のコマンドは、次のタイプの出力を生成します。

      jws-operator    Red Hat Operators   16h
    2. JWS Operator で使用可能なチャネルを確認するには、次のコマンドを入力します。

      $ oc describe packagemanifests jws-operator -n openshift-marketplace | grep "Catalog Source"

      上記のコマンドは、次のタイプの出力を生成します。

      Catalog Source:     redhat-operators
  2. Operator グループを作成するには、次の手順を実行します。

    1. Operator グループの実際のリストを確認するには、次のコマンドを入力します。

      $ oc get operatorgroups -n <project_name>
      注記

      前の例で、<project_name> を OpenShift プロジェクト名に置き換えます。

      上記のコマンドは、次のタイプの出力を生成します。

      NAME       AGE
      mygroup    17h
    2. 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 オブジェクトの名前に置き換えます。

    3. YAML ファイルから OperatorGroup オブジェクトを作成します。

      $ oc apply -f <filename>.yaml
      注記

      前の例の <filename>.yaml を、OperatorGroup オブジェクト用に作成した YAML ファイルの名前に置き換えます。

  3. サブスクリプションオブジェクトを作成するには、次の手順を実行します。

    1. 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 値と一致していることを確認します。

    2. 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

手順

  1. イメージを準備し、イメージを表示する場所 (例: quay.io/<USERNAME>/tomcat-demo:latest) にプッシュします。
  2. Custom Resource Web サーバー用の YAML ファイルを作成するには、次の手順を実行します。

    1. たとえば、webservers_cr.yaml という名前のファイルを作成します。
    2. 詳細を次の形式で入力します。

      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
  3. Web アプリケーションをデプロイするには、次の手順を実行します。

    1. Web アプリケーションを作成したディレクトリーに移動します。
    2. 以下のコマンドを入力します。

      $ oc apply -f webservers_cr.yaml

      上記のコマンドにより、次の出力が生成されます。

      webserver/example-image-webserver created
      注記

      Operator はルートを自動的に作成します。

  4. Operator が作成するルートを確認します。

    $ oc get routes
  5. オプション:前の手順で作成した 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 を削除できます。

前提条件

手順

  1. Web コンソールを開き、Operators Operator Installed Operators をクリックします。
  2. 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 ツールがインストールされている。

手順

  1. サブスクライブした 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>
  2. Operator のサブスクリプションを削除します。

    $ oc delete subscription jws-operator -n <project_name>
    注記

    上記のコマンドで、<project_name> を Operator をインストールしたプロジェクトの namespace に置き換えます。Operator がすべての namespace にインストールされている場合は、<project_name>openshift-operators に置き換えます。

  3. 前の手順で取得した 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> はオペレーターバージョン (v 1.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 環境変数をアプリケーションの新しいビルド設定に追加できます。

手順

  1. 以下のコマンドを入力します。

    $ 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 環境変数を追加できます。

手順

  1. MAVEN_MIRROR_URL 変数を必要とするビルド設定を特定します。

    $ oc get bc -o name

    上記のコマンドは、次のタイプの出力を生成します。

    buildconfig/jws
    注記

    前の例では、jws はビルド設定の名前です。

  2. MAVEN_MIRROR_URL 環境変数を buildconfig/jws に追加します。

    $ oc env bc/jws MAVEN_MIRROR_URL="http://10.0.0.1:8080/repository/internal/"
    
    buildconfig "jws" updated
  3. ビルド設定が更新されたことを確認します。

    $ oc env bc/jws --list
    
    # buildconfigs jws
    MAVEN_MIRROR_URL=http://10.0.0.1:8080/repository/internal/
  4. 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

該当なし

このディレクトリーからの .war.ear、および .jar ファイルが deployments ディレクトリーにコピーされます。

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/ ディレクトリーに保存されます。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.