Operator を使用した Red Hat OpenShift Container Platform への Red Hat Decision Manager 環境のデプロイメント

手順

1. Red Hat OpenShift Container Platform が Red Hat レジストリーへのアクセス用に、ユーザー名とパスワードで設定されているかを判断します。必須の設定に関する詳細は、レジストリーの場所の設定 を参照してください。OpenShift オンラインサブスクリプションを使用する場合は、Red Hat レジストリー用のアクセスはすでに設定されています。

2. Red Hat OpenShift Container Platform は、ユーザー名とパスワードで Red Hat レジストリーにアクセスするように設定した場合には、これ以上何もする必要はありません。設定していない場合には、以下の手順を実行してください。

   1. oc コマンドで OpenShift にログインして、プロジェクトがアクティブであることを確認します。
   2. Registry Service Accounts for Shared Environments で説明されている手順を実行します。Red Hat カスタマーポータルにログインして、このドキュメントにアクセスし、レジストリーサービスアカウントを作成する手順を実行します。
   3. OpenShift Secret タブを選択し、Download secret のリンクをクリックして、YAML シークレットファイルをダウンロードします。
   4. ダウンロードしたファイルを確認して、name: エントリーに記載の名前をメモします。

   5. 以下のコマンドを実行します。

      oc create -f <file_name>.yaml
      oc secrets link default <secret_name> --for=pull
      oc secrets link builder <secret_name> --for=pull

      <file_name> はダウンロードしたファイルに、<secret_name> はファイルの name: のエントリーに記載されている名前に置き換えてください。

手順

1. Decision Server の SSL 暗号化の秘密鍵および公開鍵を使用して SSL キーストアを生成します。プロダクション環境で、期待する Decision Server の URL に一致する有効な署名付き証明書を生成します。キーストアを keystore.jks ファイルに保存します。証明書の名前と、キーストアファイルのパスワードを記録します。

   自己署名または購入した SSL 証明書でキーストアを作成する方法は、SSL 暗号化キーおよび証明書 を参照してください。

2. oc コマンドを使用して、新しいキーストアファイルからシークレット kieserver-app-secret を生成します。

   $ oc create secret generic kieserver-app-secret --from-file=keystore.jks

手順

1. Business Central の SSL 暗号化の秘密鍵および公開鍵を使用して、SSL キーストアを生成します。実稼働環境で、期待する Business Central の URL に一致する有効な署名付き証明書を生成します。キーストアを keystore.jks ファイルに保存します。証明書の名前と、キーストアファイルのパスワードを記録します。

   自己署名または購入した SSL 証明書でキーストアを作成する方法は、SSL 暗号化キーおよび証明書 を参照してください。

2. oc コマンドを使用して、新しいキーストアファイルからシークレット decisioncentral-app-secret を生成します。

   $ oc create secret generic decisioncentral-app-secret --from-file=keystore.jks

手順

1. OpenShift Web クラスターコンソールでプロジェクトに移動します。
2. OpenShift Web コンソールのナビゲーションパネルで、Operators を選択してから Catalog Sources を選択します。
3. ビジネスオートメーション を検索します。見つかった場合は、その横にある Create Subscription をクリックします。

4. Business Automation エントリーがない場合には、以下の手順を実行してください。

   1. 管理者として OpenShift 環境にログインします。

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

      $ oc create -f https://raw.githubusercontent.com/kiegroup/kie-cloud-operator/1.0.1/deploy/catalog_resources/redhat/catalog-source.yaml

   3. ブラウザーで OpenShift Web コンソールを更新します。
   4. Business Automation を再度検索します。その横にある Create Subscription をクリックします。
5. 新規サブスクリプションの YAML 記述が表示されます。Create をクリックして、サブスクリプションを作成してください。

手順

1. OpenShift Web クラスターコンソールでプロジェクトに移動します。
2. OpenShift Web コンソールのナビゲーションパネルで、Operators を選択してから Subscriptions を選択します。
3. businessautomation を含むサブスクリプションの名前をクリックします。このサブスクリプションに関する情報が表示されます。
4. Installed version 見出しの下で、サブスクリプションのバージョン名をクリックします。サブスクリプションの概要が表示されます。
5. Create KieApp をクリックします。YAML ソースが表示されます。
6. name フィールドに、プロジェクトで一意のアプリケーション名を設定します。

7. environment フィールドには、必須の環境タイプを設定します。これらのタイプはそれぞれ、デフォルトのデプロイメントパターンです。このパターンは、YAML ソースを編集して変更できます。完了後でもデプロイメントを変更できます。利用可能なタイプは以下のとおりです。

   • rhdm-trial: すばやく設定して、アセットの開発や実行を評価またはデモで確認するのに使用できる試用版の環境。Business Central と Decision Server 1 台が含まれています。この環境では永続ストレージを使用しないため、この環境で実行した作業内容は保存されません。
   • rhdm-authoring: Business Central を使用してサービスを作成し、変更する環境。この環境は、オーサリングの作業用の Business Central と、サービスのテスト実行用の Decision Server 1 台で設定されます。この環境を使用して、ステージングおよび実稼働の目的でサービスを実行することも可能です。環境に Decision Server を追加して、同じ Business Central で管理できます。
   • rhdm-authoring-ha: Business Central を使用してサービスを作成し、変更する環境。この環境は、オーサリングの作業用の Business Central と、サービスのテスト実行用の Decision Server 1 台で設定されます。このバージョンのオーサリング環境は、高可用性が確保されるように Business Central Pod のスケーリングをサポートします。
   • rhdm-production-immutable: ステージングおよび実稼働目的で既存のサービスを実行するための別の環境。Decision Server の複製 Pod を 1 つまたは複数設定して、ソースからサービスを構築できます。この環境では、Process Server の Pod のデプロイ時に、サービスまたはサービスグループをロードおよび起動するイメージをビルドします。この Pod でサービスを停止したり、新しいサービスを追加したりすることはできません。サービスの別のバージョンを使用したり、別の方法で設定を変更する必要がある場合は、新規のサーバーイメージをデプロイして、古いサーバーと入れ替えます。このシステムでは、Decision Server は OpenShift 環境の他の Pod のように実行されます。コンテナーベースの統合ワークフローを使用でき、他のツールを使用して Pod を管理する必要はありません。

8. 本書に参考用として記載されているスニペットを使用し、YAML ソースに行を追加して、環境を変更します。

   • 以下のスニペットは、イミュータブルの Decvision Server Pod を追加して、ソースからサービスを構築します。イミュータブルな環境を作成する場合には、このスニペットのコピーを 1 つ以上追加する必要があります。

       objects:
         servers:
           - build:
               kieServerContainerDeployment: <deployment>
               gitSource:
                 uri: <url>
                 reference: <branch>
                 contextDir: <directory>

     以下の値を置き換えます。

     • <deployment>: ソースからビルドしたデシジョンサービス (KJAR ファイル) の識別情報。形式は <containerId>=<groupId>:<artifactId>:<version> になります。区切り記号 | を使用して 2 つ以上の KJAR ファイルを指定できます (例: containerId=groupId:artifactId:version|c2=g2:a2:v2)。Maven ビルドプロセスは、Git リポジトリーのソースからこのようなファイルをすべて生成する必要があります。
     • <url>: デシジョンサービスのソースを含む Git リポジトリーの URL。
     • <branch>: Git リポジトリーのブランチ。
     • <directory>: Git リポジトリーからダウンロードしたプロジェクトのソースへのパス。

   • 以下のスニペットでは、Decision Server の数と設定を設定し、お使いの環境にすでに存在する Business Central で管理します。このスニペットでは、3 種の名前セットの中にサーバー 6 台が含まれています。

     apiVersion: app.kiegroup.org/v1
     kind: KieApp
     metadata:
       name: server-config
     spec:
       environment: <environment_type>
       objects:
         console:
           env:
             - name: MY_VALUE
               value: "example"
         servers:
           # Kieserver sets will be named sequentially server-config-kieserver1, server-config-kieserver1-2
           - deployments: 2
             # Env variables that will be added to all the kie servers in this set
             env:
               - name: MY_VALUE
                 value: "example"
             # Override default memory limits for all the kie servers in this set
             resources:
               limits:
                 memory: 2Gi
           # Kieserver sets will be named sequentially server-config-kieserver2, server-config-kieserver2-2
           - deployments: 2
             # Env variables that will be added to all the kie servers in this set
             env:
               - name: MY_VALUE
                 value: "example"
           # Kieserver sets will be named sequentially server, server-2
           - name: server
             deployments: 2
             env:
               - name: MY_VALUE
                 value: "example"
             # Override default memory limits for all the kie servers in this set
             resources:
               limits:
                 memory: 2Gi

     <environment_type> は、設定する環境タイプに置き換えます。

   • 以下のスニペットでは、実稼働環境での要件に応じて、HTTPS 通信の既存のシークレットを使用して Decision Servers と Business Central を設定します。この例では、server-a-keystore シークレットを使用して 2 つのサーバーが作成されます。(シークレットの作成手順については、「Business Central へのシークレットの作成」と「Decision Server にシークレットの作成」 を参照してください。)

     apiVersion: app.kiegroup.org/v1
     kind: KieApp
     metadata:
       name: keystore-config
     spec:
       environment: <environment_type>
       objects:
         console:
           keystoreSecret: console-keystore
         servers:
           - name: server-a
             deployments: 2
             keystoreSecret: server-a-keystore
           - name: server-b
             keystoreSecret: server-b-keystore

     <environment_type> は、設定する環境タイプに置き換えます。

   • 以下のスニペットでは、管理者ユーザー (admin) のパスワードと、アプリケーション名 (app2) を設定します。

       commonConfig:
         adminPassword: password
         applicationName: app2

   • 以下のスニペットは LDAP 認証を設定します。このパラメーターは Red Hat JBoss EAP の LdapExtended ログインモジュールに対応します。これらの設定に関する説明は、LdapExtended ログインモジュール を参照してください。

     auth:
       ldap:
         url: ldaps://myldap.example.com
         bindDN: uid=admin,ou=users,ou=exmample,ou=com
         bindCredential: s3cret
         baseCtxDN: ou=users,ou=example,ou=com
         baseFilter: (uid={0})
         searchScope: SUBTREE_SCOPE
         roleAttributeID: memberOf
         rolesCtxDN: ou=groups,ou=example,ou=com
         roleFilter: (memberOf={1})
         defaultRole: guest
       roleMapper:
         rolesProperties: /conf/roleMapper.properties
         replaceRole: true

     LDAP サーバーがデプロイメントに必要な全ロールを定義していない場合は、LDAP グループを Red Hat Decision Manager ロールにマッピングしてください。LDAP ロールマッピングを有効にするには、/opt/eap/standalone/configuration/rolemapping/rolemapping.properties など、ロールマッピングを定義するファイルの完全修飾パス名に、rolesProperties の値を設定してください。このファイルを指定して、適用可能なデプロイメント設定のこのパスにマウントする必要があります。このファイルを指定する方法は、「LDAP ロールマッピングファイルの指定」 を参照してください。

     replaceRole パラメーターが true に設定されている場合には、LDAP サーバーに定義されているロールは、マッピングされたロールに置き換えられます。このパラメーターが false に設定されている場合には、マッピングされたロールおよび LDAP サーバーに定義されているロール両方がユーザーアプリケーションロールとして設定されます。デフォルトの設定は false です。

9. YAML ソースの変更を完了したら、Createをクリックしてアプリケーションを作成します。

手順

1. OpenShift Web クラスターコンソールでプロジェクトに移動します。
2. OpenShift Web コンソールのナビゲーションパネルで、Operators を選択してから Subscriptions を選択します。
3. businessautomation を含むサブスクリプションの名前をクリックします。このサブスクリプションに関する情報が表示されます。
4. Installed version 見出しの下で、サブスクリプションのバージョン名をクリックします。サブスクリプションの概要が表示されます。
5. Instances タブを選択します。
6. デプロイした環境の名前をクリックします。
7. YAML タブを選択します。YAML ソースが表示されます。
8. パスワードなどの共通の設定を変更するには、commonConfig: の値を編集します。

9. 新しい Decision Server を追加する場合は、以下の例に示されているように、servers: のブロックの最後に対応の記述を追加します。

   • 名前が server-a と server-a-2 のサーバー 2 台を追加するには、以下の行を追加します。

     - deployments: 2
       name: server-a

   • S2I プロセスのソースから構築するサービスを含む、イミュータブルな Decision Server を追加するには、以下の行を追加します。

     - build:
         kieServerContainerDeployment: <deployment>
         gitSource:
           uri: <url>
           reference: <branch>
           contextDir: <directory>

     以下の値を置き換えます。

     • <deployment>: ソースからビルドしたデシジョンサービス (KJAR ファイル) の識別情報。形式は <containerId>=<groupId>:<artifactId>:<version> になります。区切り記号 | を使用して 2 つ以上の KJAR ファイルを指定できます (例: containerId=groupId:artifactId:version|c2=g2:a2:v2)。Maven ビルドプロセスは、Git リポジトリーのソースからこのようなファイルをすべて生成する必要があります。
     • <url>: デシジョンサービスのソースを含む Git リポジトリーの URL。
     • <branch>: Git リポジトリーのブランチ。
     • <directory>: Git リポジトリーからダウンロードしたプロジェクトのソースへのパス。
10. Decision Server をスケーリングする場合は、servers: のブロックに含まれるサーバーの記述を検索して、その記述の下に replicas: 設定を追加します。たとえば、replicas: 3 はサーバーを Pod 3 つにスケーリングします。
11. Save Changes をクリックします。
12. This object has been updated のポップアップメッセージが表示されるまで待機します。
13. Reload をクリックして、環境の新しい YAML の記述を表示します。

手順

1. my-role-map など、ロールマッピングのプロパティーファイルを作成します。ファイルには、次の形式のエントリーが含まれている必要があります。

   ldap_role = product_role1, product_role2...

   以下に例を示します。

   admins = kie-server,rest-all,admin

2. 以下のコマンドを入力して、このファイルから OpenShift 設定ファイルのマッピングを作成します。

   oc create configmap ldap-role-mapping --from-file=<new_name>=<existing_name>

   <new_name> は、Pod に指定するファイルの名前 (AUTH_ROLE_MAPPER_ROLES_PROPERTIES ファイルで指定した名前と同じである必要があります) に置き換えます。また、<existing_name> は、作成したファイル名に置き換えます。以下に例を示します。

   oc create configmap ldap-role-mapping --from-file=rolemapping.properties=my-role-map

3. ロールマッピング用に指定した全デプロイメント設定に設定マップをマウントします。

   すべてのデプロイメント設定について、以下のコマンドを実行します。

    oc set volume dc/<deployment_config_name> --add --type configmap --configmap-name ldap-role-mapping --mount-path=<mapping_dir> --name=ldap-role-mapping

   <mapping_dir> は、/opt/eap/standalone/configuration/rolemapping など、AUTH_ROLE_MAPPER_ROLES_PROPERTIES で設定したディレクトリー名 (ファイル名なし) に置き換えます。