コンテナー化された MID サーバーの展開と自動構成

リリースバージョン: Xanadu

更新日 2024年08月01日

所要時間：7分

エージェントアドミニストレーターは、MID サーバープロファイルを入力し、展開要求をインスタンス上で作成できます。その後、展開要求を YAML ファイルにエクスポートし、それを使用して MID サーバーを Kubernetes または OpenShift クラスターに展開できます。

コンテナー化された MID サーバーは、MID サーバーの Docker イメージを使用して、MID サーバーを迅速に展開できるようになります。「Linux 用の MID Server Docker イメージのビルド」のドキュメントには、手動での準備と展開の手順が記載されています。次のコンテナー化された MID サーバーの自動構成は、プロセスを簡素化し、拡張可能にします。

MID サーバープロファイル

MID サーバープロファイルには、新しい MID サーバーを構成するために必要なすべての設定が含まれています。ただし、パスワードや証明書などの機密データは含まれません。機密データは、K8s クラスターで作成されたシークレットを介して渡される必要があります。ユーザーは、展開要求にシークレット名と場所のみを入力します。プロファイルを作成または変更するには、agent_admin ロールが必要です。MID サーバープロファイルは、次のテーブルに保存されます。

mid_server_profile
mid_profile_config
mid_profile_wrapper_config
mid_profile_property
mid_profile_application_m2m
mid_profile_capability_m2m
mid_profile_ip_range_m2m
mid_profile_cluster_m2m

展開中、mid_profile_config および mid_profile_wrapper_config パラメーターが K8s クラスターに送信されます。これらのパラメーターは、新しい MID サーバーの config.xml と wrapper-override.conf に入力します。その他のパラメーターは、インスタンスの自動構成で使用されます。ユーザーは、インスタンスのモジュール MID サーバープロファイルから MID サーバープロファイルにアクセスできます。

プロファイルは複数の MID サーバーを展開するために使用できるため、MID サーバーの名前はプロファイルに必要ありません。代わりに、ユーザーは新しい展開要求の一部として MID サーバーの名前を入力するよう求められます。mid_profile_wrapper_config の場合、ユーザーは表示する任意のパラメーターを wrapper-override.conf に入力できます。例：


名前	[値]
wrapper.java.maxmemory	2048
wrapper.java.additional.3	-Djavax.net.debug=ssl:handshake

その他のプロファイル設定は、MID サーバーレコードと同じ方法で入力できます。

MID サーバーの展開要求

[MID サーバー] プロファイルを作成した後、ユーザーは新しい展開要求を作成して、展開プロセスを準備できます。展開要求は、コンテナーオーケストレーターごとに異なる場合があります。詳細については、「MID サーバーの展開要求」を参照してください。

手動展開の MID 展開要求をエクスポート

ユーザーは、K8s 展開 YAML ファイルにエクスポートできます。ユーザーは、kubectl apply –f<yaml_file> コマンドを使用して、YAML ファイルを K8s クラスターにダウンロードし、新しい MID サーバーを展開できます。

Docker イメージの準備

Docker イメージを準備するには、「MID サーバー Docker イメージをビルド」で説明されているように、最初に K8s クラスター上に MID サーバーイメージをビルドします。ビルドされたイメージをイメージレジストリーにアップロードし、docker pull registry/mid:<tag> コマンドを使用して、イメージをローカルイメージにプルします。リモートレジストリーから直接イメージをプルする際の制限事項については、「コンテナー化された MID サーバーの Docker レジストリーのセットアップ II (Docker Registry Setup for Containerized MID Server II)：自動構成 [KB1001380]」を参照してください。

Kubernetes の準備

「How to build and deployment Containerized MID Servers in Kubernetes using StatefulSets (StatefulSets を使用して Kubernetes でコンテナ化された MID サーバーをビルドおよび展開する方法) [KB1325173]」も参照してください。

Kubernetes サービスアカウントのセットアップ

リソースの作成、削除、およびリスト権限に対して、サービスアカウントに適切な RBAC が設定されていることを確認します。次の YAML ファイルの例では、デフォルトのサービスアカウントを使用しています。

apiVersion: rbac.authorization.k8s.io/v1 
 kind: ClusterRoleBinding 
 metadata:   
    name: default-service-acccount-as-cluster-admin 
 subjects:   

  - kind: ServiceAccount 
    # Reference to upper's `metadata.name`     
    name: default 
    # Reference to upper's `metadata.namespace`     
    namespace: default 
 roleRef:   
    kind: ClusterRole 
    name: cluster-admin 
    apiGroup: rbac.authorization.k8s.io

カスタムサービスアカウントを選択し、そのサービスアカウントと名前空間に ClusterRole を割り当てることができます。デフォルトの名前空間は defaultです。次の YAML ファイルの例では、カスタム名前空間、mynamespace を使用しています。

apiVersion: rbac.authorization.k8s.io/v1 
 kind: ClusterRoleBinding 
 metadata:   
    name: custom-serviceacccount-as-cluster-admin 
 subjects:   

  - kind: ServiceAccount 
    # Reference to upper's `metadata.name`     
    name: mycustomserviceaccount 
    # Reference to upper's `metadata.namespace`     
    namespace: mynamespace 
 roleRef:   
    kind: ClusterRole 
    name: cluster-admin 
    apiGroup: rbac.authorization.k8s.io

Kubernetes シークレットのセットアップ

相互認証用に mid-secrets.properties または PEM ファイル用のシークレットが作成されます。シークレットの作成方法の詳細については、「コンテナー化された MID サーバー」の該当セクションを参照してください。

新しいコンテナー化された MID サーバーを自動構成

MID サーバーがインスタンスに初めて接続されると、MID サーバーレコードが作成されます。MID サーバーレコードには、コンテナー ID、プロファイル ID、および展開名が入力されます。新しい MID サーバーレコードが [profile_id] フィールドのプロファイル ID で更新されると、[プロファイルから MID を自動構成 (Auto-Configure MID from profile)] ビジネスルールがトリガーされます。ビジネスルールは、そのプロファイル ID に関連付けられたプロファイル設定を検索し、それに応じて新しい MID サーバーを構成します。

MID サーバープロファイルを既存の MID サーバーに同期

関連する MID サーバーが自動構成されてかなり経ってからユーザーがプロファイルを更新すると、MID サーバープロファイルが、既存の MID サーバーの設定と同期しなくなる可能性があります。ユーザーは、インスタンスの [MID サーバーに同期] を選択することで、プロファイル設定を既存の MID サーバーに同期できます。