Preparing your environment#

概要#

前提条件#

結果#

  • 必要なシークレットTLS、認証、ストレージ、その他の必要なシークレットで構成されたKubernetesクラスター

  • 選択した高度な機能の構成IDP、マルチロケーション、TDEのKMS)

  • ハイブリッドマネージャーHMインストールの準備ができた完成および検証された``values.yaml`` 構成ファイル

注釈

EDBサポートコンテキスト ハイブリッドマネージャーの最終準備は、クラスターのライフサイクルオペレーションと同様、主に**顧客の責任**

Sovereign Systems を除く。 **プロフェッショナルサービス**は、作業ステートメントSoWを介して従事でき、**サポート**はナレッジベース記事を介して支援を提供できます。

次のフェーズ フェーズ5 Install Hybrid Manager

フェーズ4ガイド#

Kubernetesクラスターが実行されたため、HMプラットフォーム用に準備する必要があります。

これには、リモート管理ワークステーションを介した管理アクセスの確立、必要なアーティファクトとシークレットのクラスターへのステージング、およびアーキテクチャの決定を最終的な構成ファイルに変換することが含まれます。

環境の準備フェーズ4では、以下をカバーします。

  • 必要なインフラストラクチャシークレットの作成とTLSの実装

)* (A) self-managed Cert-Manager issuer

  • (B) custom CA

  • (C) custom certificate

  • (D) self-signed default

  • その他の必要なシークレットの作成

Fernetシークレットが必要 * カタログシークレットの作成 。

  • Constructing complex YAML configurations for your **Identity Provider** 。* TDEのKMSの実装 。

**Completing environment preparation:**

*内部バックアップフォルダーの構成と必須の User-0管理アカウントの保護。

  • **Finalizing the cluster configuration (`values.yaml):** <#finalizing-the-cluster-configuration-valuesyaml>` *上記の関連するすべての入力を最終的なHelmチャートのvalues.yaml ファイルに組み立てます。

  • 構成ファイルとランタイムの検証

  • values.yaml ファイルとランタイム環境を検証して、HMインストールの準備が整います。

必要なシークレットの作成#

警告

以下はオプションの構成ではありません。インストールを正常に完了するには、これらの準備手順を**完了する必要があります**。この構成では、関連する機能を利用する必要はありません。必要な場合に備えて、安全な実装を準備するだけです。

オブジェクトストレージ資格情報、データベースアクセストークン、またはその他の機密情報など、必要な資格情報のKubernetesシークレットを作成します。

イメージプルのシークレットを作成する#

警告

HMを正常にインストールするには、Image Pulシークレットを作成する必要があります。

依存関係#

  • k8s Secret edb-cred values.yaml のデフォルトedb-cred

edbctl を使用して、 ImagePullSecret 名前空間と必要なシークレットを作成します。

  1. 必要な名前空間を作成し、シークレットをプルします。

edbctl image-pull-secret create \
  --username <container registry username> \
  --password <container registry passowrd> \
  --registry <local registry URI>
  1. 現在のKubernetesコンテキストでProceed? [y/N] とプロンプトが表示されたら、 y を選択します。

次のような出力が表示されるはずです。

2025/02/10 10:10:10 Creating Kubernetes Namespaces and ImagePullSecrets with the provided credentials...
2025/02/07 15:29:08 Namespaces and ImagePullSecrets creation completed
  1. シークレットの作成を確認します。

edbctl image-pull-secret list

出力例

Current Kubernetes context is: <your-KubeContext>
Namespace edbpgai-bootstrap: exists, all set!
  Secret edb-cred: exists, all set!
Namespace upm-replicator: exists, all set!
  Secret edb-cred: exists, all set!

スポット検証#

  1. edb-cred シークレットがターゲット名前空間に存在することを確認します。

kubectl get secret edb-cred -n edbpgai-bootstrap
  1. デフォルトのサービスアカウントがedb-cred シークレットを参照していることを確認します。

kubectl get serviceaccount default -n edbpgai-bootstrap -o yaml | grep edb-cred
  1. テストポッドlassoを展開して、イメージのプルを検証します。

kubectl run lasso \
  --rm -it \
  --image=[docker.enterprisedb.com/pgai-platform/lasso:latest](https://docker.enterprisedb.com/pgai-platform/lasso:latest) \
  --restart=Never \
  -n edbpgai-bootstrap \
  --image-pull-policy=Always \
  -- bash
  1. (オプション)ポッドを説明して、imagePullSecretが設定されていることを確認します。

kubectl describe pod lasso -n edbpgai-bootstrap | grep -i imagepull

オブジェクトストレージシークレットの作成#

警告

HMを正常にインストールするには、Object Storageシークレットを作成する必要があります。オブジェクトストレージは完全にハイブリッドマネージャー専用である必要があります。 オブジェクトストレージに存在する以前のデータは、HMの正常なオペレーションを妨げます。 同様に、HMを削除して再インストールした場合、新しいインストールを開始する前にオブジェクトストレージを空にする必要があります。

フェーズ2システム要件の収集 を実装するには、 default 名前空間にedb-object-storage という名前のシークレットを作成する必要があります。

プロバイダーと一致する構成を選択します

AWS IAM EKSまたはROSA#

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage # the name cannot be changed
  namespace: default # the namespace cannot be changed
stringData:
  auth_type: workloadIdentity
  aws_region: <AWS_BUCKET_REGION>
  aws_role_arn: <PRIMARY_IDENTITY_ROLE_ARN>
  bucket_name: <AWS_BUCKET_NAME>
  secondary_role_arn: <SECONDARY_IDENTITY_ROLE_ARN>
  secondary_role_external_id: <SECONDARY_IDENTITY_EXTERNAL_ID>

AWS / その他のK8静的資格情報#

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage
  namespace: default
stringData:
  auth_type: credentials
  aws_region: <AWS_BUCKET_REGION>
  bucket_name: <AWS_BUCKET_NAME>
  aws_access_key_id: <AWS_ACCESS_KEY_ID>
  aws_secret_access_key: <AWS_SECRET_ACCESS_KEY>
  secondary_role_arn: <SECONDARY_IDENTITY_ROLE_ARN>
  secondary_role_external_id: <SECONDARY_IDENTITY_EXTERNAL_ID>

Azure Blob Storage#

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage
  namespace: default
stringData:
  provider: azure
  subscription_id: <AZURE_SUBSCRIPTION_ID>
  resource_group_name: <AZURE_RESOURCE_GROUP>
  storage_account_name: <AZURE_STORAGE_ACCOUNT>
  storage_account_container_name: <AZURE_STORAGE_CONTAINER>
  storage_account_key: <AZURE_STORAGE_KEY>
  region: <AZURE_REGION>
  client_id: <AZURE_CLIENT_ID>
  client_secret: <AZURE_CLIENT_SECRET>
  tenant_id: <AZURE_TENANT_ID>

GCPオブジェクトストレージ#

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage
  namespace: default
stringData:
  provider: gcp
  location_id: <GCP_BUCKET_REGION>
  project_id: <GCP_PROJECT_ID>
  bucket_name: <GCP_BUCKET_NAME>
  credentials_json_base64: <GCP_CREDENTIAL_BASE64>

その他のS3互換ストレージ#

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage
  namespace: default
stringData:
    auth_type: credentials
    # Optional: Base64 CA bundle if not using a well-known CA
    aws_ca_bundle_base64: <CA_BUNDLE_BASE64>
    aws_endpoint_url_s3: <S3_ENDPOINT_URL>
    aws_access_key_id: <AWS_ACCESS_KEY_ID>
    aws_secret_access_key: <AWS_SECRET_ACCESS_KEY>
    bucket_name: <S3_BUCKET_NAME>
    aws_region: <S3_REGION>
    # Set to true if server-side encryption is disabled on the bucket
    server_side_encryption_disabled: <true|false>

その他の必要なシークレットの作成#

警告

以下はオプションの構成ではありません。インストールを正常に完了するには、これらの準備手順を**完了する必要があります**。この構成では、関連する機能を利用する必要はありません。必要な場合に備えて、安全な実装を準備するだけです。

HMインストールを成功させるには、他にも作成する必要があるシークレットがあります。

GenAI Builderシークレットの作成#

警告

HMを正常にインストールするには、GenAI Builderシークレットを作成する必要があります。

GenAI Builderを使用する予定がない場合でも、シークレットの作成は必要な手順です。

特定のCORSポリシーを使用して暗号化キーと専用のS3互換バケットを手動で設定する必要があります。

準備チェックリスト

  1. 名前空間 upm-griptape 名前空間を作成します。

  2. 暗号化 Fernetキーを生成し、その名前空間内にfernet-secret を作成します。

  3. ストレージ 専用のオブジェクトストレージバケットDataLakeを作成します。

  4. ネットワーキング CORS構成をバケットに適用して、ポータルドメインからのアクセスを許可します。

**SOP: Enabling GenAI Builder**

** ガイドFernetキーとCORS JSON構成を生成するためのスクリプト。*

カタログシークレットの作成#

警告

HMを正常にインストールするには、カタログシークレットを作成する必要があります。

GenAIと同様に、 Catalogサービスを使用しない場合でも、暗号化されたストレージ資格情報を作成する必要があります。

準備チェックリスト

  1. 名前空間 upm-lakekeeper 名前空間を作成します。

  2. 暗号化 Fernetキーを生成し、その名前空間にシークレットを作成します。

  3. 構成 values.yaml で インストール時 カタログインフラストラクチャ/OSイメージを構成します。

**SOP: Enabling data catalogs**

** ガイド 交絡するキー、名前空間、およびシークレットを作成するためのコマンド。 *

Migration Portalシークレットのカスタマイズ#

警告

HMを正常にインストールするには、移行ポータルのシークレットをカスタマイズする必要があります。

名前空間edb-migration-portal およびedb-migration-copilot にシークレットを作成します。

**SOP: Customizing Migration Portal secrets for secure internal communication**

** ガイダンス 移行ポータルを使用するためのカスタムシークレットを作成するコマンド。*

TLSを実装する#

フェーズ2システム要件の収集 フェーズ中に選択したTLS戦略を実装する必要があります。一部の戦略は、シークレットの作成が必要です。

オプションA カスタム証明書マネージャー発行者#

  • ユースケース クラスターで実行されている既存のClusterIssuer またはIssuer たとえば、Let’s Encrypt、HashCorp Vault、または企業CAなどがあります。

注釈

このオプションでは、シークレットをHMに渡す必要はありません。 既存の発行者は既に自分の資格情報を管理しています。

依存関係#

  • 既存のClusterIssuer またはIssuer が構成され、ターゲットクラスタで使用できることを確認します。

  • values.yaml で発行者名と種類を指定します。 ``parameters.global.portal_certificate_issuer_kind:<ClusterIssuer or Issuer>`` portal_certificate_issuer_name:<my_issuer>

  • **SOP: Set up a custom cert-manager issuer for the HM Portal **

オプションB カスタム認証局CA#

  • ユースケース HMに証明書マネージャー発行者を作成し、独自の企業CAを使用して証明書に署名します。

依存関係#

  • 独自のカスタムCAを設定します。

  • CA署名キーペア証明書とキーを含む<ca_secret_name> のKubernetesシークレットを作成します。

  • values.yaml parameters.global.ca_secret_name:(<ca_secret_name) で<ca_secret_name> を指定します。

  • SOP: :ref:`独自のプライベート認証局を使用する <独自のプライベート認証局を使用する>` .

オプションC カスタム証明書#

ユースケース 独自のx.509証明書があり、デフォルトの自己署名HM証明書に変更したいと考えています

依存関係#

  • パブリック証明書ファイルと暗号化されていないプライベートキーの証明書チェーン全体のエクスポートを含む<my_portal_certificate> のKubernetesシークレットを作成します。

  • values.yaml parameters.global.portal_certificate_secret:<my_portal_certificate> で<my_portal_certificate> を指定します。

  • **SOP: Set up a custom x.509 certificate for the Hybrid Manager Portal **

オプションD 自己署名証明書デフォルト#

  • ユースケース 非実稼働テスト。

HMは、 デフォルト で自己署名証明書を自動的に生成します。

依存関係#

該当なし

高度な機能の設定#

マルチロケーションアーキテクチャの構成#

複数の場所マルチDCにHMを展開するには、プライマリおよびセカンダリクラスターが安全に通信できるようにするための大幅な準備が必要です。

信頼ドメインを確立し、ストレージシークレットを同期し、セカンダリの場所を登録するようにBeaconエージェントを構成する必要があります。

準備チェックリスト

  1. ネットワーク クラスター間のポート8444 SPIREおよび9445 Beaconでの接続を確認します。

  2. ストレージ すべてのクラスターでedb-object-storage シークレットを同期します。

  3. Identity: クラスター間の信頼を許可するようにSPIREフェデレーションを構成します。

  4. 構成 一意のbeacon_location_id 値とvalues.yaml の信頼ドメインを定義します。

**SOP: Configuring multiple data centers for Hybrid Manager**

** ガイド SPIREフェデレーションとDCクロス配線をセットアップするための詳細な手順。*

IDプロバイダーIdPの構成#

アクション idpConnectors 構成ブロックを構成します。

IdPを構成するには、values.yaml で複雑な配列を構成する必要があります。

IdPプロバイダーOkta、Active Directoryなどから特定の値を収集して、 portal.authentication.idpConnectors セクションにデータを入力する必要があります。

**SOP: Configuring your own identity provider**

** ガイド LDAPおよびSAML統合の詳細なYAML例。*

TDEのKMSの実装#

データベースTDEの保存時の暗号化が必要な場合は、キー管理サービスKMSプロバイダーを有効にし、今すぐキーを作成する必要があります。

**SOP: Adding KMS support**

使用しているKMSに応じて、以下のガイドを参照して、必要なvalues.yaml フラグを特定し、キーを作成します。

フェーズ1 アーキテクチャの計画 および フェーズ2システム要件の収集 フェーズ中に決定された構成戦略を実装します。

環境の準備の完了#

内部バックアップフォルダーを設定する#

これは、ディザスターリカバリーとマルチロケーションのためのHMバックアップの世界的に一意のフォルダー名です。

依存関係#

  • values.yaml パラメーター global.internal_backup_folder 。

必須の静的User-0パスワードを変更します#

依存関係#

values.yaml のpgai.portal.authentication.staticPasswords の下で次の4つの値を構成する必要があります。

  1. ``userID`` c5998173-a605-449a-a9a5-4a9c33e26df7 に設定する必要があります。

  2. ``username`` 管理アカウントのログインユーザー名。

  3. ``email`` 管理アカウントに関連付けられたメールアドレス。

  4. ``hash`` 目的のパスワードのbcryptハッシュ。

新しいパスワードにはハッシュを使用します#

新しいパスワードのハッシュを生成するには

オプション1

bcrypt hash of the string "password": $(echo password | htpasswd -BinC 10 admin | cut -d: -f2)

オプション2

echo password | htpasswd -BinC 10 admin | cut -d: -f2

クラスター構成の完成 values.yaml#

次に、最終的なvalues.yaml ファイルをコンストラクトまたは以前に作成した場合は更新します。

このファイルは、 システム要件 ストレージ、ネットワークなど、 環境設定 、および準備した 機能構成 を参照します。

以下は、HMインストールを成功させるために決定する必要があるすべてのキーを含むテンプレート構成です。

system: <Kubernetes>
bootstrapImageName: <Container Registry Domain>/pgai-platform/edbpgai-bootstrap/bootstrap-<Kubernetes>
bootstrapImageTag: <Version>
containerRegistryURL: "<Container Registry Domain>/pgai-platform"
parameters:
  global:
    internal_backup_folder: <twelveCharacterString>
    portal_domain_name: <Portal Domain>
    storage_class: <Block Storage>
    portal_certificate_issuer_kind: <ClusterIssuer>
    portal_certificate_issuer_name: <my-issuer>
    trust_domain: <Portal Domain>
  upm-beacon:
    beacon_location_id: <Location>
    server_host: <Agent Domain>
  transporter-rw-service:
    domain_name: <Migration Domain>
  transporter-dp-agent:
    rw_service_url: https://<Migration Domain>/transporter
beaconAgent:
  provisioning:
    imagesetDiscoveryAuthenticationType: <Authentication Type for the Container Registry>
    imagesetDiscoveryContainerRegistryURL: "<Container Registry Domain>/pgai-platform"
  transparentDataEncryptionMethods:
    - <available_encryption_method>
pgai:
  portal:
    authentication:
      idpConnectors:
        - config:
            caData: <base64 encyrption of Certificate Authority from SSO provider>
            emailAttr: email
            groupsAttr: groups
            entityIssuer: https://<Portal Domain>/auth/callback
            redirectURI: https://<Portal Domain>/auth/callback
            ssoURL: [https://login.microsoft.com/](https://login.microsoft.com/)<azure service identifier>/saml2
            usernameAttr: name
          id: azure
          name: Azure
          type: saml
      staticPasswords:
        - email: <email>
          hash: <hashed_password>
          userID: c5998173-a605-449a-a9a5-4a9c33e26df7
          username: <email-or-username>
resourceAnnotations:
  - name: istio-ingressgateway
    kind: Service
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-scheme: internal
      service.beta.kubernetes.io/load-balancer-source-ranges: 10.0.0.0/8

構成ファイルとランタイムの検証#

展開に進む前に、構成ファイルとランタイム環境の両方を検証します。

構成構文の検証#

values.yaml が有効で、Helmによって処理できることを確認します。

<your-registry-url> を、 values.yaml たとえば docker.enterprisedb.com または内部Harbor/Artifactoryなどで定義したレジストリに置き換えます。

helm template edb-pgai oci://<your-registry-url>/pgai-platform/edb-pgai \
  --values values.yaml \
  --version <target-version> > /dev/null

このコマンドがエラーなしで完了した場合、YAML構文は有効です。

シークレットを検証する#

構成で参照されたシークレットがクラスター内に存在することを確認します。

kubectl get secrets -n default

以下を確認します edb-object-storage 、edb-cred 、およびTLSシークレット

ロードバランサーの検証#

クラスターが外部ロードバランサーサービスイングレスに必要をプロビジョニングできることを確認します。

kubectl create service loadbalancer test-lb --tcp=80:80
kubectl get svc test-lb
  • 成功 ロードバランサーコントローラが機能している場合、test-lbサービスには外部IPまたはホスト名が割り当てられます。

  • クリーンアップ kubectl delete svc test-lb

診断ツールを実行する#

クラスターの準備状況を包括的にチェックするには、診断プラグインを使用します。

次のフェーズ#

管理ワークステーションの準備が整い、イメージの同期、シークレットの作成、高度な機能の構成、values.yaml のファイナライズ、およびYAMLの検証が行われたので、HMをインストールする準備が整います。

** Install Hybrid Manager **