# Deploying Dynamic Engine with existing PersistentVolumeClaims Configure the Dynamic Engine Helm charts to reference existing PersistentVolumeClaims by name instead of using dynamic StorageClass provisioning. ## Before you begin * The three PersistentVolumeClaim resources (job-data, archive, and custom-resources) are created and in Bound state in the environment namespace. If you are using docker-registry, the docker-registry claim must also be in Bound state in the engine namespace. ## About this task Use this procedure when storage is already provisioned in your cluster, for example after setting up EKS with Amazon S3 (see [Setting up Amazon EKS with S3](https://help.qlik.com/talend/en-US/dynamic-engine-configuration-guide/Cloud/install-dynamic-engine-eks-with-s3 "Before deploying Dynamic Engine and its environments, set up an Amazon EKS cluster with Amazon S3 as the shared storage backend.")) or another pre-provisioned storage system. In this model, the Dynamic Engine Helm charts bind to named PersistentVolumeClaims at deployment time rather than requesting storage from a StorageClass. This is the static provisioning model. For the dynamic provisioning model, where Kubernetes creates volumes automatically from a StorageClass, see [Provisioning a storage class dedicated to Dynamic Engine environment services](https://help.qlik.com/talend/en-US/dynamic-engine-configuration-guide/Cloud/deploy-dynamic-engine-with-specific-storageclass "Configure a specific storage class for Dynamic Engine environment services instead of using the default Kubernetes storage class."). Both the Dynamic Engine chart (for the embedded registry volume) and the Dynamic Engine Environment chart (for the three processing volumes) must be configured separately. Information noteImportant: When persistent shared storage is enabled (configuration.persistence.enabled=true), which is the default in Dynamic Engine 1.6.x or older versions, this procedure is required for S3 deployments. When persistence is disabled (configuration.persistence.enabled=false), Dynamic Engine does not require PVC setup for its own services. However, you should still set up static PVCs if your Talend Management Console tasks require persistent storage or if you want to preserve task data on S3. ## Procedure 1. Set the environment variables for your deployment: ``` export DYNAMIC_ENGINE_VERSION= export DYNAMIC_ENGINE_ID= export DYNAMIC_ENGINE_ENVIRONMENT_ID= ``` Replace the placeholder values with your actual Dynamic Engine version, engine ID, and environment ID. 2. Verify that the required PersistentVolumes and PersistentVolumeClaims exist and are in Bound state: ``` kubectl get pv ``` Confirm that the output lists the expected volumes with Bound status and the correct claim namespaces. For example: ``` 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 ``` Information noteNote: The 1200Gi capacity value is required by the Kubernetes API but is not enforced. For S3-backed volumes, actual storage capacity is determined by the S3 bucket, not by this field. Configure and deploy the Dynamic Engine chart 1. Create a custom values file for the Dynamic Engine chart, specifying the docker-registry claim name: ``` cat < $DYNAMIC_ENGINE_ID-custom-set-static-pvc-values.yaml configuration: dockerRegistry: persistence: existingClaim: docker-registry EOF ``` 2. Deploy the Dynamic Engine using the base values file and the custom values file: ``` 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 ``` Configure and deploy the Dynamic Engine Environment chart 1. Create a custom values file for the Dynamic Engine Environment chart, specifying the three processing volume claim names: ``` cat < $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 ``` Information noteNote: The Helm chart API requires underscores for the persistentVolumeClaims keys (job\_data, custom\_resources). The corresponding PersistentVolumeClaim names use hyphens (job-data, custom-resources). This asymmetry is intentional. 2. Deploy the Dynamic Engine Environment using the base values file and the custom values file: ``` 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 ``` ## Results Dynamic Engine and its environment are now running with the existing PersistentVolumeClaims. Confirm that the docker-registry pod in the qlik-dynamic-engine namespace and the dpe-di-job-deployer pod in the qlik-processing-env-$DYNAMIC\_ENGINE\_ENVIRONMENT\_ID namespace are running. ## What to do next Run the following commands to confirm that the pods are running in both namespaces: ``` kubectl get pods -n qlik-dynamic-engine kubectl get pods -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID ```