Red Hat JBoss Web Server Operator


Red Hat JBoss Web Server 5.7

Red Hat JBoss Web Server Operator 2.0 for OpenShift のインストールと使用

Red Hat Customer Content Services

概要

Red Hat JBoss Web Server Operator 2.0 をインストールおよび使用して、Red Hat OpenShift で Web アプリケーションを管理する方法

Red Hat JBoss Web Server ドキュメントへのフィードバックの提供

エラーを報告したり、ドキュメントを改善したりするには、Red Hat Jira アカウントにログインし、課題を送信してください。Red Hat Jira アカウントをお持ちでない場合は、アカウントを作成するように求められます。

手順

  1. 次のリンクをクリックして チケットを作成します
  2. Summary に課題の簡単な説明を入力します。
  3. Description に課題や機能拡張の詳細な説明を入力します。問題があるドキュメントのセクションへの URL を含めてください。
  4. Submit をクリックすると、課題が作成され、適切なドキュメントチームに転送されます。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

第1章 Red Hat JBoss Web Server Operator

Operator は、Kubernetes および OpenShift 環境で複雑なステートフルアプリケーションの管理を容易にする Kubernetes ネイティブアプリケーションです。Red Hat JBoss Web Server (JWS) は、OpenShift イメージの JWS を管理する Operator を提供します。JWS Operator を使用して、OpenShift で Web サーバーアプリケーションのインスタンスを作成、設定、管理、およびシームレスにアップグレードできます。

Operator には、次のような重要な概念があります。

  • Operator Framework は、効果的で自動化されたスケーラブルな方法で Operator を管理するためのツールキットです。Operator Framework には、次の 3 つの主要コンポーネントが含まれます。

    • OperatorHub を使用して、インストールする Operator を検出できます。
    • Operator Lifecycle Manager (OLM) を使用して、OpenShift クラスターに Operator をインストールおよび管理できます。
    • Operator SDK を使用して、独自のカスタム Operator を開発できます。
  • Operator グループ は、マルチテナント設定を OLM でインストールされた Operator に提供する OLM リソースです。Operator グループは、OperatorGroup オブジェクトと同じ namespace にデプロイされたすべての Operator に対してロールベースのアクセス制御 (RBAC) を生成するターゲット namespace を選択します。
  • カスタムリソース定義 (CRD) は、Operator が使用する Kubernetes 拡張メカニズムです。CRD により、Operator が管理するカスタムオブジェクトがネイティブの Kubernetes オブジェクトのように動作できるようになります。JWS Operator は、デプロイする Web サーバーアプリケーションのカスタムリソースファイルで指定できる一連の CRD パラメーターを提供します。

このドキュメントでは、JWS Operator をインストールする方法、既存の JWS イメージをデプロイする方法、クラスターから Operator を削除する方法について説明します。このドキュメントでは、JWS Operator が提供する CRD パラメーターの詳細についても説明します。

注記

このガイドの手順に従う前に、前提条件として OpenShift クラスターがすでにインストールされ、設定されていることを確認する必要があります。OpenShift クラスターのインストールと設定の詳細については、OpenShift Container Platform の インストール ガイドを参照してください。

準備されたイメージを展開するか、既存のイメージストリームからイメージを構築するための、より高速で詳細度の低いガイドについては、JWS Operator QuickStart ガイドを参照してください。

重要

Red Hat は、JWS 5.4 以降のバージョンのイメージのみをサポートしています。

第2章 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
    Copy to Clipboard Toggle word wrap

    前の例では、出現する <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
    Copy to Clipboard Toggle word wrap
  3. oc tag コマンドを使用して、イメージストリームへの更新をトリガーします。

    以下に例を示します。

    oc tag quay.io/$user/<my-image> <my-image>-imagestream:latest --scheduled
    Copy to Clipboard Toggle word wrap

    上記のコマンドにより、OpenShift Container Platform は指定されたイメージストリームタグを定期的に更新します。この期間は、デフォルトで 15 分に設定されているクラスター全体の設定です。

既存のイメージを再構築するためのレベル 2 のシームレスな統合

BuildConfig オブジェクト定義には、イメージストリームの更新のトリガーと、Webhook が Git または GitHub によってトリガーされたときにイメージの再構築を可能にする GitHub または汎用 Webhook のいずれかである Webhook が含まれています。

Webhook のシークレット作成について、詳しくは 汎用 Webhook または GitHub Webhook のシークレットの作成 を参照してください。

カスタムリソース WebServer ファイルでの汎用 Webhook または GitHub Webhook の設定について、詳しくは JWS Operator の 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-Q4
  • rht.comp: JBoss_Web_Server
  • rht.comp_ver: 5.7.0
  • 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-Q4
    rht.comp: JBoss_Web_Server
    rht.comp_ver: 5.7.0
    rht.subcomp: Tomcat 9
    rht.subcomp_t: application
spec:
----
Copy to Clipboard Toggle word wrap
注記

デプロイされた 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章 OperatorHub からの JWS Operator のインストール

JWS Operator を OperatorHub からインストールして、OpenShift クラスターでの JBoss Web Server アプリケーションのデプロイメントと管理を容易にできます。OperatorHub は、インストールする Operator を検出するために使用できる Operator Framework のコンポーネントです。OperatorHub は、Operator をクラスターにインストールして管理する Operator Lifecycle Manger (OLM) と連携して動作します。

以下のいずれかの方法で、OperatorHub から JWS Operator をインストールできます。

3.1. Web コンソールを使用した JWS Operator のインストール

グラフィカルユーザーインターフェイスを使用して JWS Operator をインストールする場合は、OpenShift Web コンソールを使用して JWS Operator をインストールできます。

注記

Web コンソールを使用して JWS Operator をインストールし、Operator が SingleNamespace インストールモードを使用している場合、OperatorGroup および Subscription オブジェクトが自動的にインストールされます。

前提条件

  • クラスター管理者および Operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

  1. Web コンソールを開き、Operators > OperatorHub を選択します。
  2. Filter by keyword 検索フィールドに JWS と入力します。
  3. JWS Operator を選択します。
  4. JBoss Web Server Operator メニューで、使用する Capability level を選択し、Install をクリックします。
  5. Install Operator ページで、以下の手順を実行します。

    1. JWS Operator が使用できる Update channel を選択します。

      注記

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

    2. Operator の Installation mode を選択します。

      Operator は、クラスターのすべての名前空間または特定の名前空間にインストールできます。特定の名前空間オプションを選択した場合は、Installed Namespace フィールドを使用して、Operator をインストールする名前空間を指定します。

      注記

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

    3. Operator の Approval strategy を選択します。

      次のガイドラインを考慮してください。

      • Automatic 更新を選択した場合、Operator の新しいバージョンが利用可能になると、OLM は Operator の実行中のインスタンスを自動的にアップグレードします。
      • Manual (手動) 更新を選択した場合、Operator の新しいバージョンが使用できるようになると、OLM によって更新リクエストが作成されます。クラスター管理者は、更新リクエストを手動で承認して、Operator が新しいバージョンに更新されるようにする必要があります。
  6. Install をクリックします。

    注記

    Manual 承認戦略を選択した場合は、インストールが完了する前にインストール計画を承認する必要があります。

    JWS Operator が Operators タブの Installed Operators セクションに表示されます。

3.2. コマンドラインを使用した JWS Operator のインストール

コマンドラインインターフェイスを使用して JWS Operator をインストールする場合は、oc コマンドラインツールを使用して JWS Operator をインストールできます。

コマンドラインから JWS Operator をインストールする手順には、Operator でサポートされているインストールモードと使用可能なチャネルの確認、およびサブスクリプションオブジェクトの作成が含まれます。Operator が使用するインストールモードによっては、サブスクリプションオブジェクトを作成する前に、プロジェクトの名前空間に Operator グループを作成する必要があります。

前提条件

  • Operator インストールパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにデプロイできる。
  • ローカルシステムに oc ツールがインストールされている。

手順

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

    1. OperatorHub からクラスターで使用できる JWS Operator のリストを表示します。

      $ oc get packagemanifests -n openshift-marketplace | grep jws
      Copy to Clipboard Toggle word wrap

      上記のコマンドは、使用可能な各 Operator の名前、カタログ、および経過時間を表示します。

      以下に例を示します。

      NAME            CATALOG             AGE
      jws-operator    Red Hat Operators   16h
      Copy to Clipboard Toggle word wrap
    2. JWS Operator を調べて、Operator でサポートされているインストールモードと使用可能なチャネルを確認します。

      $ oc describe packagemanifests jws-operator -n openshift-marketplace
      Copy to Clipboard Toggle word wrap
  2. Operator グループの実際のリストを確認します。

    $ oc get operatorgroups -n <project_name>
    Copy to Clipboard Toggle word wrap

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

    上記のコマンドは、使用可能な各 Operator グループの名前と経過時間を表示します。

    以下に例を示します。

    NAME       AGE
    mygroup    17h
    Copy to Clipboard Toggle word wrap
  3. Operator グループを作成する必要がある場合は、次の手順を実行します。

    注記

    インストールする Operator が SingleNamespace インストールモードを使用し、適切な Operator グループがまだ配置されていない場合は、この手順を完了して Operator グループを作成する必要があります。指定された名前空間に Operator グループを 1 つだけ作成します。

    インストールする Operator が AllNamespaces インストールモードを使用する場合、または適切な Operator グループがすでに配置されている場合は、この手順を無視できます。

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

      以下に例を示します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <project_name>
      spec:
        targetNamespaces:
        - <project_name>
      Copy to Clipboard Toggle word wrap

      前の例で、<operatorgroup_name> を作成する Operator グループの名前に置き換え、<project_name> を Operator をインストールするプロジェクトの名前に置き換えます。プロジェクト名を表示するには、oc project -q コマンドを実行します。

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

      $ oc apply -f <filename>.yaml
      Copy to Clipboard Toggle word wrap

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

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

    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
      Copy to Clipboard Toggle word wrap

      前の例で、<project_name> を Operator をインストールするプロジェクトの名前に置き換えます。プロジェクト名を表示するには、oc project -q コマンドを実行します。

      指定する名前空間には、Operator と同じインストールモード設定を持つ OperatorGroup オブジェクトが必要です。Operator が AllNamespaces インストールモードを使用する場合、<project_name> をすでに適切な Operator グループを提要している openshift-operators に置き換えます。Operator が SingleNamespace インストールモードを使用する場合は、この名前空間にあるのが 1 つの OperatorGroup オブジェクトのみであることを確認してください。

      source 設定が、Operator で使用可能なチャネルを確認したときに表示された Catalog Source 値 (たとえば、redhat-operators) と一致していることを確認します。

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

      $ oc apply -f <filename>.yaml
      Copy to Clipboard Toggle word wrap

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

検証

  • JWS Operator が正常にインストールされたことを確認するには、次のコマンドを入力します。

    $ oc get csv -n <project_name>
    Copy to Clipboard Toggle word wrap

    上の例で、<project_name> を、Operator をインストールしたプロジェクトの名前空間に置き換えます。

    このコマンドは、インストールされている Operator の詳細を表示します。

    以下に例を示します。

    Expand
    NAMEDISPLAYバージョンREPLACE PHASE

    jws-operator.V2.0.x

    JBoss Web Server Operator

    2.0.x

    Succeeded

    上記の出力で、2.0.x は実際の Operator バージョンを表します (例: 2.0.0)。

第4章 既存の JWS イメージのデプロイ

JWS Operator を使用して、OpenShift クラスターにデプロイする Web サーバーアプリケーションの既存のイメージのデプロイを容易にすることができます。この状況では、デプロイする Web サーバーアプリケーションのカスタムリソース WebServer ファイルを作成する必要があります。JWS Operator は、カスタムリソース WebServer ファイルを使用して、アプリケーションのデプロイを処理します。

前提条件

  • OperatorHub から JWS Operator をインストールしている

    JWS Operator がインストールされていることを確認するには、次のコマンドを入力します。

    $ oc get deployment.apps/jws-operator
    Copy to Clipboard Toggle word wrap

    上記のコマンドは、Operator の名前とステータスの詳細を表示します。

    以下に例を示します。

    NAME            READY 	UP-TO-DATE   AVAILABLE   AGE
    jws-operator    1/1   	1            1           15h
    Copy to Clipboard Toggle word wrap
    注記

    より詳細な出力を表示する場合は、次のコマンドを使用できます。

    oc describe deployment.apps/jws-operator

手順

  1. イメージを準備し、イメージを表示する場所 (例: quay.io/<USERNAME>/tomcat-demo:latest) にプッシュします。
  2. Web サーバーアプリケーションのカスタムリソースファイルを作成するには、次の手順を実行します。

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

      apiVersion: web.servers.org/v1alpha1
      kind: WebServer
      metadata:
          name: <image name>
      spec:
          # Add fields here
          applicationName: <application name>
          replicas: 2
      webImage:
         applicationImage: <URL of the image>
      Copy to Clipboard Toggle word wrap

      以下に例を示します。

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

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

      $ oc apply -f webservers_cr.yaml
      Copy to Clipboard Toggle word wrap

      上記のコマンドは、Web アプリケーションがデプロイされたことを確認するメッセージを表示します。

      以下に例を示します。

      webserver/example-image-webserver created
      Copy to Clipboard Toggle word wrap

      上記のコマンドを実行すると、Operator はルートも自動的に作成します。

  4. Operator が自動的に作成したルートを確認します。

    $ oc get routes
    Copy to Clipboard Toggle word wrap
  5. オプション: ステップ 3 で作成した webserver を削除します。

    $ oc delete webserver example-image-webserver
    Copy to Clipboard Toggle word wrap
    注記

    または、YAML ファイルを削除して webserver を削除することもできます。以下に例を示します。

    oc delete -f webservers_cr.yaml

第5章 クラスターからの JWS Operator の削除

JWS Operator を使用する必要がなくなった場合は、後でクラスターから JWS Operator を削除できます。

次のいずれかの方法で、クラスターから JWS Operator を削除できます。

5.1. Web コンソールを使用した JWS Operator の削除

グラフィカルユーザーインターフェイスを使用して 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 がクラスター外のリソースを設定した場合、これらのアプリケーションとリソースを手動でクリーンアップする必要があります。

5.2. コマンドラインを使用した JWS Operator の削除

コマンドラインインターフェイスを使用して 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
    Copy to Clipboard Toggle word wrap

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

    上記のコマンドで以下の出力が表示され、ここで v2.0.x は Operator のバージョン (例: v2.0.0) を示しています。

    f:currentCSV: {}
    currentCSV: jws-operator.v2.0.x
    Copy to Clipboard Toggle word wrap
  2. Operator のサブスクリプションを削除します。

    $ oc delete subscription jws-operator -n <project_name>
    Copy to Clipboard Toggle word wrap

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

  3. ターゲット名前空間で Operator の CSV を削除します。

    $ oc delete clusterserviceversion <currentCSV> -n <project_name>
    Copy to Clipboard Toggle word wrap

    上記の例で、<currentCSV>手順 1 で取得した currentCSV 値 (例: jws-operator.v2.0.x) に置き換えます。<project_name> を、Operator をインストールしたプロジェクトの名前空間に置き換えます。Operator がすべての namespace にインストールされている場合は、<project_name>openshift-operators に置き換えます。

    上記のコマンドは、CSV が削除されたことを確認するメッセージを表示します。

    以下に例を示します。

    clusterserviceversion.operators.coreos.com "jws-operator.v2.0.x" deleted
    Copy to Clipboard Toggle word wrap

第6章 汎用 Webhookまたは GitHub Webhook のシークレットの作成

汎用 Webhook または GitHub Webhook で使用できるシークレットを作成して、Git リポジトリーでアプリケーションのビルドをトリガーできます。アプリケーションコードに使用する Git ホスティングプラットフォームのタイプに応じて、JWS Operator は、Web アプリケーションのカスタムリソースファイルでシークレットを指定するために使用できる genericWebhookSecret パラメーターと githubWebhookSecret パラメーターを提供します。

手順

  1. エンコードされたシークレット文字列を作成します。

    1. たとえば secret.txt という名前のファイルを作成します。
    2. secret.txt ファイルに、シークレット文字列をプレインテキストで入力します。

      以下に例を示します。

      qwerty
      Copy to Clipboard Toggle word wrap
    3. 文字列をエンコードするには、次のコマンドを入力します。

      base64 secret.txt
      Copy to Clipboard Toggle word wrap

      上記のコマンドは、エンコードされた文字列を表示します。

      以下に例を示します。

      cXdlcnR5Cg==
      Copy to Clipboard Toggle word wrap
  2. Secret という種類のオブジェクトを定義する secret.yaml ファイルを作成します。

    以下に例を示します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: jws-secret
    data:
      WebHookSecretKey: cXdlcnR5Cg==
    Copy to Clipboard Toggle word wrap

    上記の例では、jws-secret がシークレットの名前、cXdlcnR5Cg== がエンコードされたシークレット文字列です。

  3. シークレットを作成するには、次のコマンドを入力します。

    oc create -f secret.yaml
    Copy to Clipboard Toggle word wrap

    上記のコマンドは、シークレットが作成されたことを確認するメッセージを表示します。

    以下に例を示します。

    secret/jws-secret created
    Copy to Clipboard Toggle word wrap

検証

  1. Webhook の URL を取得します。

    oc describe BuildConfig | grep webhooks
    Copy to Clipboard Toggle word wrap

    上記のコマンドは、次の形式で Webhook URL を生成します。

    https://<host>:<port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
    Copy to Clipboard Toggle word wrap
  2. たとえば payload.json という名前で、最小限の JSON ファイルを作成します。

    {}
    Copy to Clipboard Toggle word wrap
  3. Webhook にリクエストを送信するには、次の curl コマンドを入力します。

    curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<host>:<port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
    Copy to Clipboard Toggle word wrap

    上記の例で、payload.json は作成した最小限の JSON ファイルの名前です。

    URL 文字列の <host><port><namespace><name> を、お使いの環境に適した値に置き換えます。<secret> を、Webhook 用に作成したシークレットの名前に置き換えます。

    上記のコマンドは、次のタイプの Webhook レスポンスを JSON 形式で生成します。

    {"kind":"Build","apiVersion":"build.openshift.io/v1","metadata":{"name":"test-2","namespace":"jfc","selfLink":"/apis/build.openshift.io/v1/namespaces/jfc/buildconfigs/test-2/instantiate","uid":"a72dd529-edc6-4e1c-898e-7c0dbbea176e","resourceVersion":"846159","creationTimestamp":"2020-10-30T12:29:30Z","labels":{"application":"test","buildconfig":"test","openshift.io/build-config.name":"test","openshift.io/build.start-policy":"Serial"},"annotations":{"openshift.io/build-config.name":"test","openshift.io/build.number":"2"},"ownerReferences":[{"apiVersion":"build.openshift.io/v1","kind":"BuildConfig","name":"test","uid":"1f78fa3f-2f3b-421b-9f49-192184cc2280","controller":true}],"managedFields":[{"manager":"openshift-apiserver","operation":"Update","apiVersion":"build.openshift.io/v1","time":"2020-10-30T12:29:30Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:openshift.io/build-config.name":{},"f:openshift.io/build.number":{}},"f:labels":{".":{},"f:application":{},"f:buildconfig":{},"f:openshift.io/build-config.name":{},"f:openshift.io/build.start-policy":{}},"f:ownerReferences":{".":{},"k:{\"uid\":\"1f78fa3f-2f3b-421b-9f49-192184cc2280\"}":{".":{},"f:apiVersion":{},"f:controller":{},"f:kind":{},"f:name":{},"f:uid":{}}}},"f:spec":{"f:output":{"f:to":{".":{},"f:kind":{},"f:name":{}}},"f:serviceAccount":{},"f:source":{"f:contextDir":{},"f:git":{".":{},"f:ref":{},"f:uri":{}},"f:type":{}},"f:strategy":{"f:sourceStrategy":{".":{},"f:env":{},"f:forcePull":{},"f:from":{".":{},"f:kind":{},"f:name":{}},"f:pullSecret":{".":{},"f:name":{}}},"f:type":{}},"f:triggeredBy":{}},"f:status":{"f:conditions":{".":{},"k:{\"type\":\"New\"}":{".":{},"f:lastTransitionTime":{},"f:lastUpdateTime":{},"f:status":{},"f:type":{}}},"f:config":{".":{},"f:kind":{},"f:name":{},"f:namespace":{}},"f:phase":{}}}}]},"spec":{"serviceAccount":"builder","source":{"type":"Git","git":{"uri":"https://github.com/jfclere/demo-webapp.git","ref":"master"},"contextDir":"/"},"strategy":{"type":"Source","sourceStrategy":{"from":{"kind":"DockerImage","name":"image-registry.openshift-image-registry.svc:5000/jfc/jboss-webserver54-tomcat9-openshift@sha256:75dcdf81011e113b8c8d0a40af32dc705851243baa13b68352706154174319e7"},"pullSecret":{"name":"builder-dockercfg-rvbh8"},"env":[{"name":"MAVEN_MIRROR_URL"},{"name":"ARTIFACT_DIR"}],"forcePull":true}},"output":{"to":{"kind":"ImageStreamTag","name":"test:latest"}},"resources":{},"postCommit":{},"nodeSelector":null,"triggeredBy":[{"message":"Generic WebHook","genericWebHook":{"secret":"\u003csecret\u003e"}}]},"status":{"phase":"New","config":{"kind":"BuildConfig","namespace":"jfc","name":"test"},"output":{},"conditions":[{"type":"New","status":"True","lastUpdateTime":"2020-10-30T12:29:30Z","lastTransitionTime":"2020-10-30T12:29:30Z"}]}}
    {
      "kind": "Status",
      "apiVersion": "v1",
      "metadata": {
    
      },
      "status": "Success",
      "message": "no git information found in payload, ignoring and continuing with build",
      "code": 200
    }
    Copy to Clipboard Toggle word wrap

第7章 JWS Operator CRD パラメーター

JWS Operator は、一連のカスタムリソース定義 (CRD) パラメーターを提供します。Web アプリケーションのカスタムリソース WebServer ファイルを作成する場合、<key>: <value> の形式でパラメーター値を指定できます。JWS Operator は、カスタムリソース WebServer ファイルで指定した情報を使用して、Web アプリケーションをデプロイします。

7.1. CRD パラメーター階層

JWS Operator は、以下の階層形式で CRD パラメーターを提供します。

applicationName: <value>
replicas: <value>
useSessionClustering: <value>
webImage:
   applicationImage: <value>
   imagePullSecret: <value>
   webApp:
      name: <value>
      sourceRepositoryURL: <value>
      sourceRepositoryRef: <value>
      contextDir: <value>
      webAppWarImage: <value>
      webAppWarImagePushSecret: <value>
      builder:
        image: <value>
        imagePullSecret: <value>
        applicationBuildScript: <value>
   webServerHealthCheck:
      serverReadinessScript: <value>
      serverLivenessScript: <value>
webImageStream:
   imageStreamName: <value>
   imageStreamNamespace: <value>
   webSources:
      sourceRepositoryUrl: <value>
      sourceRepositoryRef: <value>
      contextDir: <value>
      webSourcesParams:
         mavenMirrorUrl: <value>
         artifactDir: <value>
         genericWebHookSecret: <value>
         githubWebHookSecret: <value>
   webServerHealthCheck:
      serverReadinessScript: <value>
      serverLivenessScript: <value>
Copy to Clipboard Toggle word wrap
注記

カスタムリソース WebServer ファイルを作成するときは、上記で説明したとおりの階層形式でパラメーターの名前と値を指定します。カスタムリソース WebServer ファイルの作成について、詳しくは 既存 JWS イメージのデプロイ を参照してください。

7.2. CRD パラメーターの詳細

次の表では、JWS Operator が提供する CRD パラメーターについて説明します。この表は、階層内でその上にある上位レベルのパラメーターのコンテキストにおけるパラメーター名を示しています。

Expand
パラメーター名説明

replicas

実行する JBoss Web Server イメージの Pod 数

例:
replicas: 2

applicationName

JWS Operator がデプロイする Web アプリケーションの名前

アプリケーション名は、OpenShift 名前空間またはプロジェクト内で一意の値である必要があります。JWS Operator は、指定されたアプリケーション名を使用して、Web アプリケーションにアクセスするためのルートを作成します。

例:
applicationName: my-app

useSessionClustering

DNSping セッションクラスタリングを有効にします

デフォルトで false に設定されています。このパラメーターを true に設定した場合、セッションクラスタリングは ENV_FILES 環境変数とシェルスクリプトを使用して server.xml ファイルにクラスタリングを追加するため、イメージは JBoss Web Server イメージに基づく必要があります。

注記

このリリースのセッションクラスタリング機能はテクノロジープレビュー機能としてのみ使用できます。現在の Operator バージョンは、DNS の制限により制限されている DNS Membership Provider を使用します。InetAddress.getAllByName() の結果はキャッシュされます。つまり、スケールアップ中にセッションのレプリケーションが機能しない可能性があります。

例:
useSessionClustering: true

webImage

JWS Operator が既存イメージから Pod をデプロイする方法を制御する一連のパラメーター

このパラメーターには、applicationImageimagePullSecretwebApp、および webServerHealthCheck フィールドが含まれます。

webImage:
      applicationImage

デプロイするアプリケーションイメージの名前へのフルパス

例:
applicationImage: quay.io/$user/my-image-name

webImage:
      imagePullSecret

JWS Operator がリポジトリーからイメージをプルするために使用するシークレットの名前

シークレットにはキー .dockerconfigjson が含まれている必要があります。JWS Operator はシークレットをマウントし、--authfile/mount_point/.dockerconfigjson と同様にそれを使用して、リポジトリーからイメージをプルします。

Secret オブジェクト定義ファイルには、複数のユーザー名とパスワードの値またはトークンが含まれている場合があり、イメージストリーム内のイメージ、ビルダー イメージ、および JWS Operator によってビルドされたイメージにアクセスできます。

例:
imagePullSecret: mysecret

webImage:
      webApp

アプリケーションイメージに追加する Web アプリケーションを JWS Operator がビルドする方法を記述する一連のパラメーター

webApp パラメーターを指定しない場合、JWS Operator はアプリケーションをビルドせずに Web アプリケーションをデプロイします。

このパラメーターには、namesourceRepositoryURLsourceRepositoryRefcontextDirwebAppWarImagewebAppWarImagePushSecretbuilder フィールドが含まれます。

webImage:
      webApp:
           name

Web アプリケーションファイルの名前

デフォルトの名前は ROOT.war です。

例:
name: my-app.war

webImage:
      webApp:
           sourceRepositoryURL

アプリケーションのソースファイルがある URL

ソースには、Maven ビルドをサポートする Maven pom.xml ファイルが含まれている必要があります。Maven がアプリケーションの .war ファイルを生成すると、JWS Operator がアプリケーションのデプロイに使用するイメージの webapps ディレクトリーに .war ファイルがコピーされます (例: /opt/jws-5.x/tomcat/webapps)。

例:
sourceRepositoryUrl: 'https://github.com/$user/demo-webapp.git'

webImage:
      webApp:
           sourceRepositoryRef

JWS Operator が使用するソースリポジトリーのブランチ

例:
sourceRepositoryRef: main

webImage:
      webApp:
           contextDir

pom.xml ファイルが配置され、mvn install コマンドが実行されるソースリポジトリー内のサブディレクトリー

例:
contextDir: /

webImage:
      webApp:
           webAppWarImage

JWS Operator がビルドされたイメージをプッシュするイメージの URL

webImage:
      webApp:
           webAppWarImagePushSecret

JWS Operator がイメージをリポジトリーにプッシュするために使用するシークレットの名前

シークレットにはキー .dockerconfigjson が含まれている必要があります。JWS Operator はシークレットをマウントし、--authfile /mount_point/.dockerconfigjson と同様に使用して、イメージをリポジトリーにプッシュします。

JWS Operator がプルシークレットを使用してリポジトリーからイメージをプルする場合、プルシークレットの名前を webAppWarImagePushSecret パラメーターの値として指定する必要があります。詳細は、imagePullSecret を参照してください。

例:
imagePullSecret: mysecret

webImage:
      webApp:
           builder

JWS Operator が Web アプリケーションをビルドし、イメージを作成してイメージリポジトリーにプッシュする方法を記述する一連のパラメーター

注記

ビルダーが正常に動作し、異なるユーザー ID でコマンドを実行できるようにするには、ビルダーが anyuid SCC (セキュリティーコンテキスト制約) にアクセスできる必要があります。ビルダーに anyuid SCC へのアクセス権を付与するには、次のコマンドを入力します。

oc adm policy add-scc-to-user anyuid -z builder

このパラメーターには、imageimagePullSecret、および applicationBuildScript フィールドが含まれます。

webImage:
      webApp:
           builder:
                image

JWS Operator が Web アプリケーションをビルドするコンテナーのイメージ

例:
image: quay.io/$user/tomcat10-buildah

webImage:
      webApp:
           builder:
                imagePullSecret

JWS Operator がリポジトリーからビルダー イメージをプルするために使用するシークレットの名前 (指定されている場合)

シークレットにはキー .dockerconfigjson が含まれている必要があります。JWS Operator はシークレットをマウントし、--authfile/mount_point/.dockerconfigjson と同様にそれを使用して、リポジトリーからイメージをプルします。

Secret オブジェクト定義ファイルには、複数のユーザー名とパスワードの値またはトークンが含まれている場合があり、イメージストリーム内のイメージ、ビルダー イメージ、および JWS Operator によってビルドされたイメージにアクセスできます。

例:
imagePullSecret: mysecret

webImage:
      webApp:
           builder:
                applicationBuildScript

ビルダーイメージがアプリケーションの .war ファイルをビルドし、それを /mnt ディレクトリーに移動するために使用するスクリプト

このパラメーターの値を指定しない場合、ビルダー イメージは Maven と Buildah を使用するデフォルトのスクリプトを使用します。

webImage:
      webServerHealthCheck

JWS Operator が使用するヘルスチェック

デフォルトの動作では、パラメーターを必要としないヘルスバルブが使用されます。

このパラメーターには、serverReadinessScript および serverLivenessScript フィールドが含まれます。

webImage:
      webServerHealthCheck:
           serverReadinessScript

Pod Readiness ヘルスチェックのロジックを指定する文字列

このパラメーターが指定されていない場合、JWS Operator は、OpenShift 内部レジストリーを使用して http://localhost:8080/health をチェックします (デフォルトのヘルスチェック)。

例:
serverReadinessScript: /bin/bash -c " /usr/bin/curl --noproxy '*' -s 'http://localhost:8080/health' | /usr/bin/grep -i 'status.*UP'"

webImage:
      webServerHealthCheck:
           serverLivenessScript

Pod Liveness ヘルスチェックのロジックを指定する文字列

このパラメーターは任意です。

webImageStream

実行またはビルドするイメージを提供するイメージストリームを JWS Operator が使用する方法を制御する一連のパラメーター

JWS Operator は、イメージストリーム内の最新イメージを使用します。

このパラメーターには、applicationImageimagePullSecretwebApp、および webServerHealthCheck フィールドが含まれます。

webImageStream:
      imageStreamName

JWS Operator によるベースイメージの検索を可能にするために作成したイメージストリームの名前

例:
imageStreamName: my-image-name-imagestream:latest

webImageStream:
      imageStreamNamespace

イメージストリームを作成した名前空間またはプロジェクト

例:
imageStreamNamespace: my-namespace

webImageStream:
      webSources

アプリケーションソースファイルの場所とビルド方法を記述する一連のパラメーター

webSources パラメーターを指定しない場合、JWS Operator は最新イメージをイメージストリームにデプロイします。

このパラメーターには、sourceRepositoryUrlsourceRepositoryRefcontextDir、および webSourcesParams フィールドが含まれます。

webImageStream:
      webSources:
           sourceRepositoryUrl

アプリケーションのソースファイルがある URL

ソースには、Maven ビルドをサポートする Maven pom.xml ファイルが含まれている必要があります。Maven がアプリケーションの .war ファイルを生成すると、JWS Operator がアプリケーションのデプロイに使用するイメージの webapps ディレクトリーに .war ファイルがコピーされます (例: /opt/jws-5.x/tomcat/webapps)。

例:
sourceRepositoryUrl: 'https://github.com/$user/demo-webapp.git'

webImageStream:
      webSources:
           sourceRepositoryRef

JWS Operator が使用するソースリポジトリーのブランチ

例:
sourceRepositoryRef: main

webImageStream:
      webSources:
           contextDir

pom.xml ファイルが配置され、mvn install コマンドが実行されるソースリポジトリー内のサブディレクトリー

例:
contextDir: /

webImageStream:
      webSources:
           webSourcesParams

アプリケーションイメージのビルド方法を説明する一連のパラメーター

このパラメーターは任意です。

このパラメーターには、mavenMirrorUrlartifactDirgenericWebHookSecret、および githubWebHookSecret フィールドが含まれます。

webImageStream:
      webSources:
           webSourcesParams:
                mavenMirrorUrl

Maven が Web アプリケーションのビルドに使用する Maven プロキシー URL

クラスターがインターネットにアクセスできない場合、このパラメーターは必須です。

webImageStream:
      webSources:
           webSourcesParams:
                artifactDir

Maven が Web アプリケーション用に生成する .war ファイルを Maven が格納するディレクトリー

このディレクトリーの内容は、JWS Operator がアプリケーションのデプロイに使用するイメージの webapps ディレクトリーにコピーされます (例: /opt/jws-5.x/tomcat/webapps)。

デフォルト値は target です。

webImageStream:
      webSources:
           webSourcesParams:
                genericWebHookSecret

ビルドをトリガーできる汎用 Webhook のシークレットの名前

シークレットの作成について、詳しくは汎用 Webhook または GitHub Webhook のシークレットの作成 を参照してください。

汎用 Webhook の使用について、詳しくは Webhook トリガー を参照してください。

例:
genericWebHookSecret: my-secret

webImageStream:
      webSources:
           webSourcesParams:
                githubWebHookSecret

ビルドをトリガーできる GitHub Webhook のシークレットの名前

シークレットの作成について、詳しくは汎用 Webhook または GitHub Webhook のシークレットの作成 を参照してください。

GitHub Webhook の使用について、詳しくはWebhook トリガー を参照してください。

注記

GitHub Webhook の手動テストは実行できません。GitHub がペイロードを生成し、空ではありません。

webImageStream:
      webServerHealthCheck

JWS Operator が使用するヘルスチェック

デフォルトの動作では、パラメーターを必要としないヘルスバルブが使用されます。

このパラメーターには、serverReadinessScript および serverLivenessScript フィールドが含まれます。

webImageStream:
      webServerHealthCheck:
           serverReadinessScript

Pod Readiness ヘルスチェックのロジックを指定する文字列

このパラメーターが指定されていない場合、JWS Operator は、OpenShift 内部レジストリーを使用して http://localhost:8080/health をチェックします (デフォルトのヘルスチェック)。

例:
serverReadinessScript: /bin/bash -c " /usr/bin/curl --noproxy '*' -s 'http://localhost:8080/health' | /usr/bin/grep -i 'status.*UP'"

webImageStream:
      webServerHealthCheck:
           serverLivenessScript

Pod Liveness ヘルスチェックのロジックを指定する文字列

このパラメーターは任意です。

法律上の通知

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

Theme

© 2025 Red Hat