# 既存のPersistentVolumeClaimを使用したDynamic Engineのデプロイ

Dynamic Engine Helmチャートを構成し、動的なStorageClassプロビジョニングを使用する代わりに、既存のPersistentVolumeClaimを名前で参照するように設定します。

## 始める前に

* dynamic-engine-crdカスタムリソース定義は、oci://ghcr.io/talend/helm/dynamic-engine-crd Helmチャートを使用してインストールされている必要があります。インストールされていない場合は、次のコマンドを実行してインストールしてください。
  1. 使用するチャートのバージョンを見つけます。

     * 次のHelmコマンドを実行します:
       ```
       helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
       ```
     * Talend Management Consoleから直接バージョンを見るか、自分のDynamic Engineバージョンに含まれているチャートバージョンの[Dynamic Engine変更ログ](https://help.qlik.com/talend/en-US/dynamic-engine-changelog/Cloud)をチェックしてください。
     * [Dynamic Engineバージョンエンドポイント](https://talend.qlik.dev/apis/dynamic-engine/2021-03/#operation_return-all-supported-dynamic-engine-versions)へのAPIコールを使用します。

  2. 次のコマンドを実行し、目的のバージョンのHelmチャートをインストールします。

     ```
     helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
     ```

     &lt;helm\_chart\_version&gt;を、お使いのDynamic Engineバージョンでサポートされているチャートのバージョンに置換します。

     バージョンを指定しないと、利用可能な最新のdynamic-engine-crdチャートバージョンがインストールされます。
* 環境のネームスペース内には、3つのPersistentVolumeClaimリソース(job-data、archive、custom-resources)が作成されており、Bound状態になっている必要があります。docker-registryを使用している場合は、engineネームスペース内のdocker-registryクレームもBound状態になっている必要があります。

## このタスクについて

この手順は、クラスターにストレージがすでにプロビジョニングされている場合(例: Amazon S3を使用したEKSのセットアップ後([Amazon EKSとS3のセットアップ](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/install-dynamic-engine-eks-with-s3 "Dynamic Engineおよびその環境をデプロイする前に、共有ストレージのバックエンドとしてAmazon S3を使用するAmazon EKSクラスターをセットアップします。")を参照)または他の事前プロビジョニングされたストレージシステムの場合)に使用します。このモデルでは、Dynamic Engine Helmチャートはデプロイ時に名前付きのPersistentVolumeClaimにバインドされ、StorageClassに対してストレージを要求しません。これが、静的プロビジョニングモデルです。KubernetesがStorageClassに基づいてボリュームを自動的に作成する動的プロビジョニングモデルについては、[Dynamic Engine環境サービス専用のストレージクラスをプロビジョニング](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/deploy-dynamic-engine-with-specific-storageclass "デフォルトのKubernetesストレージクラスを使用する代わりに、Dynamic Engine環境サービス専用のストレージクラスを設定します。")を参照してください。

Dynamic Engineチャート(組み込みレジストリ用ボリューム)とDynamic Engine Environmentチャート(3つの処理用ボリューム)は、それぞれ個別に設定する必要があります。

情報メモ重要: Dynamic Engine 1.6.x以前のバージョンではデフォルト設定となっている永続共有ストレージが有効な場合(configuration.persistence.enabled=true)、S3へのデプロイにおいてこの手順が必要となります。永続化が無効の場合(configuration.persistence.enabled=false)、Dynamic Engineは自身のサービスに対してPVCのセットアップを必要としません。ただし、Talend Management Consoleタスクに永続ストレージが必要な場合や、タスクデータをS3に保持する場合は、依然として静的PVCを設定する必要があります。

## 手順

1. デプロイメントの環境変数を設定します。
   ```
   export DYNAMIC_ENGINE_VERSION=<your-dynamic-engine-version>
   export DYNAMIC_ENGINE_ID=<your-dynamic-engine-id>
   export DYNAMIC_ENGINE_ENVIRONMENT_ID=<your-dynamic-engine-environment-id>
   ```

   プレースホルダーの値を、実際のDynamic Engineバージョン、エンジンID、環境IDに置き換えます。
2. 必要なPersistentVolumeおよびPersistentVolumeClaimが存在し、かつバインド状態になっていることを確認します。
   ```
   kubectl get pv
   ```

   出力結果に、期待するボリュームがバインド状態で表示されており、クレームのネームスペースが正しいことを確認します。例:
   ```
   NAME               CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM
   docker-registry    1200Gi     RWX            Retain           Bound    qlik-dynamic-engine/docker-registry
   archive            1200Gi     RWX            Retain           Bound    qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID/archive
   custom-resources   1200Gi     RWX            Retain           Bound    qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID/custom-resources
   job-data           1200Gi     RWX            Retain           Bound    qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID/job-data
   ```

   情報メモ注: 1200Giの容量値はKubernetes APIによって必須とされていますが、実際には強制されません。S3をバックエンドとするボリュームの場合、実際のストレージ容量はこのフィールドではなくS3バケットによって決定されます。

Dynamic Engineチャートの設定とデプロイ

1. Dynamic Engineチャート用のカスタムvaluesファイルを作成し、docker-registryクレーム名を指定します。
   ```
   cat <<EOF > $DYNAMIC_ENGINE_ID-custom-set-static-pvc-values.yaml
   configuration:
     dockerRegistry:
       persistence:
         existingClaim: docker-registry
   EOF
   ```
2. ベースのvaluesファイルとカスタムvaluesファイルを使用して、Dynamic Engineをデプロイします。
   ```
   helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
     -n qlik-dynamic-engine \
     -f $DYNAMIC_ENGINE_ID-values.yaml \
     -f $DYNAMIC_ENGINE_ID-custom-set-static-pvc-values.yaml \
     oci://ghcr.io/talend/helm/dynamic-engine \
     --version $DYNAMIC_ENGINE_VERSION
   ```

Dynamic Engine環境チャートの設定とデプロイ

1. Dynamic Engine環境チャート用のカスタムvaluesファイルを作成し、3つの処理用ボリュームのクレーム名を指定します。
   ```
   cat <<EOF > $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-set-static-pvc-values.yaml
   configuration:
     persistence:
       persistentVolumeClaims:
         job_data:
           persistentVolumeClaimName: job-data
         archive:
           persistentVolumeClaimName: archive
         custom_resources:
           persistentVolumeClaimName: custom-resources
   EOF
   ```

   情報メモ注: HelmチャートAPIでは、persistentVolumeClaimsのキーにアンダースコア(job\_data、custom\_resources)を使用する必要があります。一方、対応するPersistentVolumeClaim名にはハイフン(job-data、custom-resources)が使用されます。この表記の不一致は意図的なものです。
2. ベースのvaluesファイルとカスタムvaluesファイルを使用して、Dynamic Engine環境をデプロイします。
   ```
   helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
     -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-set-static-pvc-values.yaml \
     oci://ghcr.io/talend/helm/dynamic-engine-environment \
     --version $DYNAMIC_ENGINE_VERSION
   ```

## タスクの結果

Dynamic Engineとその環境は、既存のPersistentVolumeClaimを使用して実行されています。qlik-dynamic-engineネームスペース内のdocker-registryポッドと、qlik-processing-env-$DYNAMIC\_ENGINE\_ENVIRONMENT\_IDネームスペース内のdpe-di-job-deployerポッドが実行中であることを確認してください。

## 次のタスク

次のコマンドを実行して、両方のネームスペースでポッドが実行中であることを確認します。

```
kubectl get pods -n qlik-dynamic-engine
kubectl get pods -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID
```