手順

1. Red Hat OpenShift Container Platform Web クラスターコンソールメニューで、Catalog → Installed operators または Operators → Installed operators を選択します。
2. businessautomation が含まれる Operator の名前をクリックします。この Operator の情報が表示されます。
3. ウィンドウの右側にある Installer リンクをクリックします。
4. プロンプトが出されたら、OpenShift 認証情報でログインします。

手順

1. Application Name フィールドに、OpenShift アプリケーションの名前を入力します。この名前は、すべてのコンポーネントのデフォルト URL で使用されます。

2. Environment 一覧で、環境のタイプを選択します。このタイプは、デフォルトの設定を定めるものです。この設定を必要に応じて変更することができます。以下のタイプは Red Hat Decision Manager で利用できます。

   • rhdm-trial: すばやく設定して、アセットの開発や実行を評価またはデモで確認するのに使用できる試用版の環境。Business Central と KIE Server 1 台が含まれています。この環境では永続ストレージを使用しないため、この環境で実行した作業内容は保存されません。
   • rhdm-authoring: Business Central を使用してサービスを作成し、変更する環境。これは、オーサリング作業用に Business Central を提供する Pod およびサービスのテスト実行用に KIE Server を提供する Pod で設定されます。この環境を使用して、ステージングおよび実稼働の目的でサービスを実行することも可能です。環境に KIE Server を追加して、同じ Business Central で管理できます。

   • rhdm-authoring-ha: Business Central を使用してサービスを作成し、変更する環境。これは、オーサリング作業用に Business Central を提供する Pod およびサービスのテスト実行用に KIE Server を提供する Pod で設定されます。このバージョンのオーサリング環境は、高可用性が確保されるように Business Central Pod のスケーリングをサポートします。

     重要

     Red Hat Decision Manager 7.8 では、Business Central の高可用性機能はテクノロジープレビューとしてのみの提供となっています。Red Hat Technology Preview 機能の詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

   • rhdm-production-immutable: ステージングおよび実稼働目的で既存のサービスを実行するための別の環境。ソースからサービスをビルドしたり、Maven リポジトリーからサービスをプルする KIE Server Pod を 1 つ以上設定できます。その後、必要に応じて各 Pod を複製できます。

     Pod からサービスを削除したり、新しいサービスを Pod に追加したりすることはできません。サービスの別のバージョンを使用するか、他の方法で設定を変更する場合は、新規のサーバーイメージをデプロイして、以前のイメージを置き換えます。コンテナーベースの統合ワークフローを使用して、Pod を管理できます。

     この環境を設定する場合は、KIE Servers タブで KIE Server をカスタマイズし、Set immutable server configuration ボタンをクリックするか、KIE_SERVER_CONTAINER_DEPLOYMENT 環境変数を設定します。KIE Server の設定手順は、「環境のカスタム KIE Server 設定の設定」 を参照してください。

3. 新しいバージョンへの自動アップグレードを有効にするには、Enable Upgrades ボックスを選択します。このボックスを選択すると、Red Hat Decision Manager 7.8 の新しいパッチバージョンが利用可能になると、Operator は自動的にこのバージョンにデプロイメントをアップグレードします。サービスはすべて確保され、アップグレードプロセス全体で通常通り利用できます。

   Red Hat Decision Manager 7.x の新規マイナーバージョンが利用できる場合にも、同じ自動アップグレードプロセスを有効にする場合は、Include minor version upgrade のチェックボックスを選択します。

   注記

   Red Hat Decision Manager のコンポーネントにカスタムイメージを使用する場合は、自動更新を無効にします。

4. オプション: イメージのダウンロードにイメージタグを使用する場合は、Use Image Tags ボックスを選択します。この設定は、カスタムレジストリーを使用する場合や、Red Hat サポートがダイレクトされる場合に役立ちます。
5. Custom registry のカスタムイメージレジストリーを使用する場合は、Image registry フィールドにレジストリーの URL を入力します。このレジストリーに適切に署名され、認識された SSL 証明書がない場合は、Insecure ボックスを選択します。

6. Admin user の下の、Username フィードおよび Password フィールドに、Red Hat Decision Manager の管理者ユーザーのユーザー名とパスワードを入力します。

   重要

   RH-SSO または LDAP 認証を使用する場合は、Red Hat Decision Manager の kie-server,rest-all,admin ロールを使用して、認証システムで同じユーザーを設定する必要があります。

7. イメージのカスタムバージョンタグを使用する必要がある場合は、以下の手順を実行します。

   1. Next をクリックして Security タブにアクセスします。
   2. ウィンドウの下部までスクロールします。
   3. イメージタグを Image tag フィールドに入力します。

手順

1. Installation タブが開いている場合は、Next をクリックして Security タブを表示します。

2. Authentication mode 一覧で、以下のモードのいずれかを選択します。

   • Internal: 環境のデプロイ時に初期ユーザーを設定します。このユーザーは Business Central を使用して他のユーザーを随時セットアップできます。
   • RH-SSO: Red Hat Decision Manager は認証に Red Hat Single Sign-On を使用します。
   • LDAP: Red Hat Decision Manager は認証に LDAP を使用します。

3. 選択した Authentication mode に基づいてセキュリティー設定を完了します。

   RH-SSO を選択してい場合は、RH-SSO 認証を設定します。

   1. RH-SSO URL フィールドに、RH-SSO URL を入力します。
   2. Realm フィールドに、RH-SSO レルム名を入力します。
   3. 環境のコンポーネントに RH-SSO クライアントを作成していない場合は、SSO admin user フィールドおよび SSO admin password フィールドに、RH-SSO システムの管理者ユーザーの認証情報を入力します。
   4. RH-SSO システムに適切な署名済みの SSL 証明書がない場合は、Disable SSL cert validation ボックスを選択します。
   5. Principal attribute フィールドで、ユーザー名に使用される RH-SSO プリンシパル属性を変更する必要がある場合は、新規属性の名前を入力します。

   LDAP を選択した場合は、LDAP 認証を設定します。

   1. LDAP URL フィールドに、LDAP URL を入力します。
   2. Red Hat JBoss EAP の LdapExtended ログインモジュールの設定に対応する LDAP パラメーターを設定します。これらの設定に関する説明は、LdapExtended ログインモジュール を参照してください。

4. RH-SSO または LDAP を選択した場合や、RH-SSO システムまたは LDAP システムがデプロイメントに必要なすべてのロールを定義していない場合は、認証システムのロールを Red Hat Decision Manager のロールにマップできます。

   ロールマッピングを有効にするには、プロジェクト namespace の OpenShift 設定マップまたはシークレットオブジェクトにロールマッピング設定ファイルを指定する必要があります。ファイルには、次の形式のエントリーが含まれている必要があります。

   ldap_role = product_role1, product_role2...

   以下に例を示します。

   admins = kie-server,rest-all,admin

   このファイルの使用を有効にするには、以下の変更を行います。

   1. Roles properties file フィールドの RoleMapper の下に、ルールマッピング設定ファイルの完全修飾パス名を入力します (例: /opt/eap/standalone/configuration/rolemapping/rolemapping.properties)。
   2. 認証システムで定義されているロールをマッピングファイルで定義されているロールに置き換える場合は、Replace roles ボックスを選択します。それ以外の場合は、RH-SSO または LDAP で定義されたロールと設定ファイルで定義されたロールの両方が利用可能です。
   3. RoleMapper Configuration object の下のフィールドで、ファイルを提供するオブジェクトの Kind (ConfigMap または Secret) を選択し、オブジェクトの Name を入力します。このオブジェクトは、ロールマッピング設定ファイルに指定したパスで Business Central および KIE Server Pod に自動的にマウントされます。

5. 他のパスワードを設定します (必要な場合)。

   • AMQ password および AMQ cluster password は、JMS API を使用した ActiveMQ との対話に使用するパスワードです。
   • Keystore password は、HTTPS 通信のシークレットで使用されるキーストアファイルのパスワードです。「KIE Server のシークレットの作成」 または 「Business Central へのシークレットの作成」 の説明にしたがってシークレットを作成した場合は、このパスワードを設定します。
   • Database password は、環境の一部であるデータベースサーバー Pod のパスワードです。

手順

1. Installation または Security タブが開いている場合は、Console タブが表示されるまで Next をクリックします。
2. 「Business Central へのシークレットの作成」 の説明に従って Business Central のシークレットを作成している場合は、Secret フィールドにシークレットの名前を入力します。

3. Git フックを設定します (任意)。

   オーサリング環境では、Git フックを使用して、Business Central の内部 Git リポジトリーと外部 Git リポジトリー間の操作を容易化できます。Git フックを使用する場合は、プロジェクト namespace の OpenShift 設定マップ、シークレット、または Persistent Volume Claim (PVC: 永続ボリューム要求) オブジェクトに Git フックディレクトリーを準備する必要があります。Git の SSH 認証用の SSH キーと既知のホストファイルでシークレットを作成することもできます。Git フックの作成に関する詳細は、「Git フックの準備」 を参照してください。

   Git フックディレクトリーを使用するには、以下の変更を加えます。

   1. Mount path フィールドの GitHooks の下に、ディレクトリーの完全修飾名を入力します (例: /opt/kie/data/git/hooks)。
   2. GitHooks Configuration object の下のフィールドで、ファイルを提供するオブジェクトの Kind (ConfigMap、Secret、または PersistentVolumeClaim) を選択し、オブジェクトの Name を入力します。このオブジェクトは、Git フックディレクトリーの指定したパスで Business Central Pod に自動的にマウントされます。
   3. 必要に応じて、SSH secret フィールドに、SSH キーと既知のホストファイルを含む、シークレットを入力します。
4. 必要に応じて、Business Central または Business Central monitoring のレプリカ数を Replicas フィールドに入力します。rhdm-authoring 環境では、この数を変更しません。
5. 必要に応じて、Resource quotas 下のフィールドに必要な CPU およびメモリーの上限値を入力します。
6. Business Central Pod の Java 仮想マシンの設定をカスタマイズする必要がある場合は、Enable JVM configuration ボックスを選択してから、Enable JVM configuration の下のフィールドに情報を入力します。すべてのフィールドは任意です。設定可能な JVM パラメーターについては、「JVM 設定パラメーター」 を参照してください。

7. RH-SSO 認証を選択している場合は、Business Central の RH-SSO を設定します。

   1. Client name フィールドにクライアント名を入力し、Client secret フィールドにクライアントシークレットを入力します。この名前を持つクライアントが存在しない場合は、デプロイメントでこの名前およびシークレットを持つ新規クライアントの作成を試行します。
   2. デプロイメントで新規クライアントを作成する場合は、KIE Server へのアクセスに使用する HTTP および HTTPS URL を SSO HTTP URL フィールドおよび SSO HTTPS URL フィールドに入力します。この情報は、クライアントに記録されます。

8. 必要に応じて、環境変数を随時設定します。環境変数を設定するには、Add new Environment variable をクリックしてから、変数の名前および値を Name フィールドおよび Value フィールドに入力します。

   • 外部 Maven リポジトリーを使用する必要がある場合は、以下の変数を設定します。

     • MAVEN_REPO_URL: Maven リポジトリーの URL
     • MAVEN_REPO_ID: Maven リポジトリーの ID (例: repo-custom)
     • MAVEN_REPO_USERNAME: Maven リポジトリーのユーザー名

     • MAVEN_REPO_PASSWORD Maven リポジトリーのパスワード

       重要

       オーサリング環境で、Business Central を使用して外部の Maven リポジトリーにプロジェクトをプッシュする場合は、デプロイメント時にこのリポジトリーを設定して、全プロジェクトのリポジトリーへのエクスポートを設定する必要があります。外部の Maven リポジトリーへの Business Central プロジェクトのエクスポートに関する情報は、Red Hat Decision Manager プロジェクトのパッケージ化およびデプロイ を参照してください。

   • OpenShift 環境が公開インターネットに接続されていない場合は、「オフラインで使用する Maven ミラーリポジトリーの用意」 に従って設定した Maven ミラーにアクセスできるように設定します。以下の変数を設定してください。

     • MAVEN_MIRROR_URL: 「オフラインで使用する Maven ミラーリポジトリーの用意」 でセットアップした Maven ミラーリポジトリーの URL。この URL は、OpenShift 環境の Pod からアクセスできるようにする必要があります。

     • MAVEN_MIRROR_OF: ミラーから取得されるアーティファクトを定める値。mirrorOf 値の設定方法は、Apache Maven ドキュメントの Mirror Settings を参照してください。デフォルト値は external:* です。この値の場合、Maven はミラーから必要なアーティファクトをすべて取得し、他のリポジトリーにクエリーを送信しません。

       外部の Maven リポジトリー (MAVEN_REPO_URL) を設定する場合は、ミラーからこのリポジトリー内のアーティファクトを除外するように MAVEN_MIRROR_OF を変更します (例: external:*,!repo-custom)。repo-custom は、MAVEN_REPO_ID で設定した ID に置き換えます。

       オーサリング環境でビルトイン Business Central Maven リポジトリーを使用する場合は、ミラーからこのリポジトリーのアーティファクトを除外するように MAVEN_MIRROR_OF を変更します (例: external:*,!repo-rhdmcentr)。

   • 一部のオーサリング環境では、複数のユーザーが同じ KIE Server に同時にサービスをデプロイできることを確認する必要があります。デフォルトでは、ユーザーは、Business Central を使用して KIE Server にサービスをデプロイして数秒待ってから追加サービスをデプロイする必要があります。OpenShiftStartupStrategy 設定はデフォルトで有効になり、この制限が発生します。制限を削除するには、コントローラーストラテジー を使用するように rhdm-authoring 環境を設定します。これについての特定のニーズがない限り、この変更を行わないでください。コントローラーストラテジーを有効にする場合は、Business Central と同じ環境内のすべての KIE Server でこの変更を行ってください。

     注記

     高可用性の Business Central を使用する環境でコントローラーストラテジーを有効にしないでください。この環境では、コントローラーストラテジーは正しく機能しません。

     Business Central でコントローラーストラテジーを有効にするには、KIE_SERVER_CONTROLLER_OPENSHIFT_ENABLED 環境変数を false に設定します。

手順

1. Installation、Security、または Console タブが開いている場合は、KIE Servers タブが表示されるまで Next をクリックします。
2. Add new KIE Server をクリックして、新規の KIE Server 設定を追加します。
3. Id フィールドに、KIE Server の ID を入力します。KIE Server が Business Central または Business Central Monitoring インスタンスに接続される場合、この ID はサーバーが加わるサーバーグループを決めるものとなります。
4. Name フィールドに、KIE Server の名前を入力します。
5. Deployments フィールドに、デプロイする同様の KIE Server の数を入力します。インストーラーは、同じ設定で複数の KIE Server をデプロイできます。KIE Server の ID および名前は自動的に変更され、一意な状態に保たれます。
6. 「KIE Server のシークレットの作成」 の説明に従って KIE Server のシークレットを作成している場合は、Keystore secret フィールドにシークレットの名前を入力します。
7. 必要に応じて、KIE Server のレプリカ数を Replicas フィールドに入力します。

8. KIE Server のカスタムイメージを使用する必要がある場合は、以下の追加の手順を実行します。

   1. Set KIE Server image をクリックします。
   2. イメージストリームの名前を Name フィールドに入力します。

   3. イメージストリームが openshift 名前空間にない場合は、名前空間を Namespace フィールドに入力します。

      注記

      Kind 値を DockerImage に変更しないでください。このオプションは、Red Hat Decision Manager 7.8.0 では機能しません。

      カスタムイメージの作成手順については、「KIE Server のカスタムイメージの作成」 を参照してください。

9. Source to Image (S2I) ビルドを使用して、イミュータブル KIE Server を設定する必要がある場合は、以下の追加の手順を実行します。

   重要

   Maven リポジトリーからサービスをプルするイミュータブル KIE Server を設定する必要がある場合は、Set Immutable server configuration をクリックせず、この手順も実行しないでください。代わりに、KIE_SERVER_CONTAINER_REPLOYMENT 環境変数を設定します。

   1. Set Immutable server configuration をクリックします。
   2. KIE Server コンテナーデプロイメント フィールドに、デプロイメントが Source to Image (S2I) ビルドの結果から展開する必要があるサービスの識別情報 (KJAR ファイル) を入力します。形式は <containerId>=<groupId>:<artifactId>:<version> になります。また、コンテナーのエイリアス名で指定する場合には、形式は <containerId>(<aliasId>)=<groupId>:<artifactId>:<version> になります。以下の例に示されるように、区切り文字 | を使用して 2 つ以上の KJAR ファイルを指定できます (例: containerId=groupId:artifactId:version|c2(alias2)=g2:a2:v2)。
   3. OpenShift 環境に公開インターネットへの接続がない場合は、「オフラインで使用する Maven ミラーリポジトリーの用意」 に従って、Maven mirror URL フィールドに設定した Maven ミラーの URL を入力します。
   4. Artifact directory フィールドで、Maven が正常にビルドされた後に、必要なバイナリーファイル (KJAR ファイルおよびその他の必要なファイル) が含まれるプロジェクト内のパスを入力します。通常、このディレクトリーはビルドのターゲットディレクトリーです。ただし、Git リポジトリーのこのディレクトリーにビルド済みのバイナリーを提供できます。
   5. S2I ビルドにカスタムベース KIE Server イメージを使用する必要がある場合は、Set Base build image をクリックして、Name フィールドにイメージストリームの名前を入力します。イメージストリームが openshift 名前空間にない場合は、名前空間を Namespace フィールドに入力します。OpenShift イメージストリームタグではなく Docker イメージ名を使用する必要がある場合は、Kind の値を DockerImage に変更します。

   6. Set Git source をクリックし、以下のフィールドに情報を入力します。

      • S2I Git URI: サービスのソースが含まれる Git リポジトリーの URI。
      • Reference: Git リポジトリーのブランチ。
      • コンテキストディレクトリー: (オプション) Git リポジトリーからダウンロードされたプロジェクト内のソースへのパス。デフォルトで、ダウンロードされたプロジェクトのルートディレクトリーはソースディレクトリーです。
   7. Git Webhook を設定して、Git リポジトリーの変更によって KIE Server が自動的に再構築されるようにするには、Add new Webhook をクリックします。Type リストから Webhook のタイプを選択し、Secret フィールドに Webhook のシークレット文字列を入力します。
10. 必要に応じて、Resource quotas 下のフィールドに必要な CPU およびメモリーの上限値を入力します。複数の KIE Server を設定している場合は、制限値はそれぞれのサーバーに別々に適用されます。

11. RH-SSO 認証を選択している場合は、KIE Server の RH-SSO を設定します。

    1. Client name フィールドにクライアント名を入力し、Client secret フィールドにクライアントシークレットを入力します。この名前を持つクライアントが存在しない場合は、デプロイメントでこの名前およびシークレットを持つ新規クライアントの作成を試行します。
    2. デプロイメントで新規クライアントを作成する場合は、KIE Server へのアクセスに使用する HTTP および HTTPS URL を SSO HTTP URL フィールドおよび SSO HTTPS URL フィールドに入力します。この情報は、クライアントに記録されます。

12. 外部 AMQ メッセージブローカーを使用して JMS API から KIE Server と対話する場合は、Enable JMS Integration 設定を有効にします。JMS 統合を設定するための追加のフィールドが表示され、必要に応じて値を入力する必要があります。

    • User name、Password: ブローカーのユーザー認証が環境で必要な場合の、標準ブローカーユーザーのユーザー名およびパスワード。
    • Executor: この設定を選択して JMS executor を無効にします。Executor はデフォルトで有効になります。
    • Executor transacted: この設定を選択して、Executor キューで JMS トランザクションを有効にします。
    • Enable signal: この設定を選択して JMS 経由でシグナルの設定を有効にします。
    • Enable audit: この設定を選択して JMS 経由で監査ロギングを有効にします。
    • Audit transacted: この設定を選択して、監査キューで JMS トランザクションを有効にします。
    • Queue executor、Queue request、Queue response、Queue signal、Queue audit: 使用するキューのカスタム JNDI 名。これらの値のいずれかを設定する場合は、AMQ キュー パラメーターも設定する必要があります。
    • AMQ Queues: AMQ キュー名はコンマで区切られます。これらのキューはブローカーの起動時に自動的に作成され、JBoss EAP サーバーの JNDI リソースとしてアクセスできます。カスタムキュー名を使用する場合は、このフィールドでサーバーが使用するすべてのキューの名前を入力する必要があります。
    • Enable SSL integration: AMQ ブローカーへの SSL 接続を使用する場合は、この設定を選択します。この場合は、「AMQ ブローカー接続のシークレットの作成」 で作成したシークレットの名前や、シークレットに使用したキーストアおよび信頼ストアの名前およびパスワードも指定する必要があります。
13. KIE Server Pod の Java 仮想マシンの設定をカスタマイズする必要がある場合は、Enable JVM configuration ボックスを選択してから、Enable JVM configuration の下のフィールドに情報を入力します。すべてのフィールドは任意です。設定可能な JVM パラメーターについては、「JVM 設定パラメーター」 を参照してください。

14. 必要に応じて、環境変数を随時設定します。環境変数を設定するには、Add new Environment variable をクリックしてから、変数の名前および値を Name フィールドおよび Value フィールドに入力します。

    • 設定した Maven リポジトリーからサービスをプルするイミュータブル KIE Server を設定する必要がある場合は、以下の設定を入力します。

      1. KIE_SERVER_CONTAINER_DEPLOYMENT 環境変数を設定します。変数には、デプロイメントが Maven リポジトリーからプルする必要のあるサービス (KJAR ファイル) の ID 情報が含まれている必要があります。形式は <containerId>=<groupId>:<artifactId>:<version> になります。また、コンテナーのエイリアス名で指定する場合には、形式は <containerId>(<aliasId>)=<groupId>:<artifactId>:<version> になります。以下の例に示されるように、区切り文字 | を使用して 2 つ以上の KJAR ファイルを指定できます (例: containerId=groupId:artifactId:version|c2(alias2)=g2:a2:v2)。
      2. 外部 Maven リポジトリーの設定

    • 外部 Maven リポジトリーを設定する必要がある場合には、以下の変数を設定します。

      • MAVEN_REPO_URL: Maven リポジトリーの URL
      • MAVEN_REPO_ID: Maven リポジトリーの ID (例: repo-custom)
      • MAVEN_REPO_USERNAME: Maven リポジトリーのユーザー名
      • MAVEN_REPO_PASSWORD: Maven リポジトリーのパスワード

    • OpenShift 環境が公開インターネットに接続されていない場合は、「オフラインで使用する Maven ミラーリポジトリーの用意」 に従って設定した Maven ミラーにアクセスできるように設定します。以下の変数を設定してください。

      • MAVEN_MIRROR_URL: 「オフラインで使用する Maven ミラーリポジトリーの用意」 でセットアップした Maven ミラーリポジトリーの URL。この URL は、OpenShift 環境の Pod からアクセスできるようにする必要があります。この KIE Server を S2I として設定している場合は、この URL をすでに入力されています。

      • MAVEN_MIRROR_OF: ミラーから取得されるアーティファクトを定める値。この KIE Server を S2I として設定している場合は、この値を設定しません。mirrorOf 値の設定方法は、Apache Maven ドキュメントの Mirror Settings を参照してください。デフォルト値は external:* です。この値の場合、Maven はミラーから必要なアーティファクトをすべて取得し、他のリポジトリーにクエリーを送信しません。

        外部の Maven リポジトリー (MAVEN_REPO_URL) を設定する場合は、ミラーからこのリポジトリー内のアーティファクトを除外するように MAVEN_MIRROR_OF を変更します (例: external:*,!repo-custom)。repo-custom は、MAVEN_REPO_ID で設定した ID に置き換えます。

        オーサリング環境でビルトイン Business Central Maven リポジトリーを使用する場合は、ミラーからこのリポジトリーのアーティファクトを除外するように MAVEN_MIRROR_OF を変更します (例: external:*,!repo-rhdmcentr)。

    • Prometheus を使用してメトリクスを収集し、保存するように KIE Server デプロイメントを設定する必要がある場合は、PROMETHEUS_SERVER_EXT_DISABLED 環境変数を false に設定します。Prometheus メトリクス収集の設定手順については、{URL_MANAGING_SETTINGS}#prometheus-monitoring-ocp-proc_execution-server[KIE Server の管理と監視] を参照してください。
    • {RH-SSO} 認証を使用していて、アプリケーションと {RH-SSO} とのやり取りに CORS のサポートが必要な場合は、SSO_ENABLE_CORS 変数を true に設定します。

    • 一部のオーサリング環境では、複数のユーザーが同じ KIE Server に同時にサービスをデプロイできることを確認する必要があります。デフォルトでは、ユーザーは、Business Central を使用して KIE Server にサービスをデプロイして数秒待ってから追加サービスをデプロイする必要があります。OpenShiftStartupStrategy 設定はデフォルトで有効になり、この制限が発生します。制限を削除するには、コントローラーストラテジー を使用するように rhdm-authoring 環境を設定します。これについての特定のニーズがない限り、この変更を行わないでください。コントローラーストラテジーを有効にする場合は、Business Central と同じ環境内のすべての KIE Server でこの変更を行ってください。

      注記

      高可用性の Business Central を使用する環境でコントローラーストラテジーを有効にしないでください。この環境では、コントローラーストラテジーは正しく機能しません。

      KIE Server でコントローラーストラテジーを有効にするには、KIE_SERVER_STARTUP_STRATEGY 環境変数を ControllerBasedStartupStrategy に設定し、KIE_SERVER_CONTROLLER_OPENSHIFT_ENABLED 環境変数を false に設定します。

手順

1. podman login コマンドを使用して registry.redhat.io レジストリーの認証を行います。レジストリーの認証に関する詳細は、Red Hat コンテナーレジストリーの認証 を参照してください。

2. サポートされている KIE Server のベースイメージをダウンロードするには、次のコマンドを入力します。

   podman pull registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.8.0

3. ベースイメージをもとにカスタムイメージを定義する Dockerfile を作成します。このファイルで、現在のユーザーを root に変更して、yum コマンドで RPM パッケージをインストールしてから USER 185 (Red Hat JBoss EAP ユーザー) に戻します。以下の例では、Dockerfile ファイルの内容を示します。

   FROM registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.8.0
   USER root
   RUN yum -y install procps-ng
   USER 185

   必要に応じて RPM ファイルの名前を置き換えます。yum コマンドは自動的に Red Hat Enterprise Linux 8 リポジトリーからの全依存関係を自動的にインストールします。複数の RMP ファイルをインストールする必要がある場合があります。今回は、RUN コマンドを複数回使用します。

4. Dockerfile を使用してカスタムイメージをビルドします。レジストリー名など、イメージの完全修飾名を指定します。ベースイメージと同じバージョンタグを使用する必要があります。イメージをビルドするには、以下のコマンドを入力します。

   podman build . --tag registry_address/image_name:7.8.0

   以下に例を示します。

   podman build . --tag registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0

5. ビルドが完了したら、イメージを実行してログインし、カスタマイズが成功したことを確認します。以下のコマンドを入力します。

   podman run -it --rm registry_address/image_name:7.8.0 /bin/bash

   以下に例を示します。

   podman run -it --rm registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0 /bin/bash

   イメージのシェルプロンプトで、コマンドを入力して RPM がインストールされていることをテストし、exit と入力します。たとえば、procps-ng の場合は ps コマンドを実行します。

   [jboss@c2fab36b778e ~]$ ps
   PID TTY          TIME CMD
     1 pts/0    00:00:00 bash
    13 pts/0    00:00:00 ps
   [jboss@c2fab36b778e ~]$ exit

6. カスタムイメージをレジストリーにプッシュするには、次のコマンドを入力します。

   podman push registry_address/image_name:7.8.0 docker://registry_address/image_name:7.8.0

   以下に例を示します。

   podman push registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0 docker://registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0

手順

1. KIE Server で動作するカスタムライブラリーを開発します。以下のドキュメントと例を使用して、ライブラリーを開発できます。

   • KIE Server の管理およびモニターリング の KIE Server 機能および拡張
   • Domain-specific Prometheus metrics with Red Hat Process Automation Manager and Decision Manager
   • Extend KIE Server with additional transport
2. JAR ファイルが target ディレクトリーに配置されるように Maven を使用してライブラリーをビルドします。この例では、custom-kieserver-ext-1.0.0.Final.jar のファイル名を使用します。
3. podman login コマンドを使用して registry.redhat.io レジストリーの認証を行います。レジストリーの認証に関する詳細は、Red Hat コンテナーレジストリーの認証 を参照してください。

4. サポートされている KIE Server のベースイメージをダウンロードするには、次のコマンドを入力します。

   podman pull registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.8.0

5. ベースイメージをもとにカスタムイメージを定義する Dockerfile を作成します。このファイルは JAR ファイル (単数、複数を問わず) を /opt/eap/standalone/deployments/ROOT.war/WEB-INF/lib/ ディレクトリーにコピーする必要があります。以下の例では、Dockerfile ファイルの内容を示します。

   FROM registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.8.0
   COPY target/custom-kieserver-ext-1.0.0.Final.jar /opt/eap/standalone/deployments/ROOT.war/WEB-INF/lib/

6. Dockerfile を使用してカスタムイメージをビルドします。レジストリー名など、イメージの完全修飾名を指定します。ベースイメージと同じバージョンタグを使用する必要があります。イメージをビルドするには、以下のコマンドを入力します。

   podman build . --tag registry_address/image_name:7.8.0

   以下に例を示します。

   podman build . --tag registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0

7. カスタムイメージをレジストリーにプッシュするには、次のコマンドを入力します。

   podman push registry_address/image_name:7.8.0 docker://registry_address/image_name:7.8.0

   以下に例を示します。

   podman push registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0 docker://registry.example.com/custom/rhdm-kieserver-rhel8:7.8.0