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

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む8読むのに数分
  • エージェント管理者は、インスタンスの [MID Server] プロファイルを入力し、展開要求を K8s クラスターに送信できます。新しい MID Server が自動的に構成されます。 [MID Server] プロファイルが変更された場合、関連するコンテナー化された MID Server もオンデマンドで更新できます。

    構成フェーズのインジケーターを設定するMID Server がネットワークの内部と外部の要素に接続できることを確認するMID Server を Linux または Windows ホストにダウンロードしてインストールするMID Server を構成MID Server セキュリティを設定MID Server がネットワークの内部と外部の要素に接続できることを確認するMID Server を Linux または Windows ホストにダウンロードしてインストールするMID Server を構成MID Server セキュリティを設定

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

    MID Server プロファイル

    MID Server プロファイルには、新しい MID Server を構成するために必要なすべての設定が含まれています。ただし、パスワードや証明書などの機密データは含まれません。機密データは、K8s クラスターで作成されたシークレットを介して渡される必要があります。ユーザーは、展開要求にシークレット名と場所のみを入力します。プロファイルを作成または変更するには、agent_admin ロールが必要です。MID Server プロファイルは、次のテーブルに保存されます。
    • 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 Server の config.xmlwrapper-override.conf に入力します。その他のパラメーターは、インスタンスの自動構成で使用されます。ユーザーは、インスタンスのモジュール MID Server プロファイルから MID Server プロファイルにアクセスできます。

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

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

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

    MID Server の展開要求

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

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

    ユーザーは、各展開要求を ECC キューに送信するか、K8s 展開 YAML ファイルにエクスポートするかを選択できます。

    新しい展開要求で、ユーザーが [YAML ファイルにエクスポート] を選択すると、YAML ファイルが作成され、同じ要求レコードに添付されます。ユーザーは、エクスポート操作で使用する展開テンプレートを MID Server 展開テンプレートテーブルから選択できます。テンプレートが選択されている場合、ユーザー入力は、展開 YAML ファイルを生成するときに、展開要求でテンプレートデータと結合されます。ユーザーは、kubectl apply –f<yaml_file> コマンドを使用して、YAML ファイルを K8s クラスターにダウンロードし、新しい MID Server を展開できます。

    Docker イメージの準備

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

    Kubernetes の準備

    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 Server」の該当セクションを参照してください。

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

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

    MID Server プロファイルを既存の MID Server に同期

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