Déployer Dynamic Engine avec les revendications PersistentVolumeClaims existantes

Configurez les graphiques Dynamic Engine Helm de sorte qu'ils référencent les revendications PersistentVolumeClaims existantes par leur nom au lieu d'utiliser le provisioning StorageClass dynamique.

Avant de commencer

Les définitions des ressources personnalisées dynamic-engine-crd doivent avoir été installées à l'aide du chart Helm oci://ghcr.io/talend/helm/dynamic-engine-crd. Si ce n'est pas le cas, exécutez les commandes suivantes pour l'installation :
1. Trouvez la version du chart à utiliser :
  - Exécutez la commande Helm suivante :
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Visualisez la version directement depuis Talend Management Console ou consultez le Dynamic Engine journal de modification de la version du chart dans votre version de Dynamic Engine.
  - Utilisez un appel d'API pour l'endpoint de version de Dynamic Engine (en anglais).
2. Exécutez la commande suivante pour installer le chart Helm dans une version donnée :
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Remplacez <helm_chart_version> par la version du chart supportée par votre version du Dynamic Engine.
  Si vous ne spécifiez pas la version, vous installez la dernière version disponible du chart dynamic-engine-crd.
Les trois ressources PersistentVolumeClaim (job-data, archive et custom-resources) sont créées à l'état Bound (Lié) dans l'espace de noms de l'environnement. Si vous utilisez docker-registry, la revendication docker-registry doit également être à l'état Bound (Lié) dans l'espace de noms du moteur.

Pourquoi et quand exécuter cette tâche

Utilisez cette procédure lorsque le stockage est déjà provisionné dans votre cluster, par exemple après avoir configuré EKS avec Amazon S3 (consultez Configurer Amazon EKS avec S3) ou un autre système de stockage pré-provisionné. Dans ce modèle, les graphiques Dynamic Engine Helm se lient aux revendications PersistentVolumeClaims nommées lors du déploiement au lieu de demander un stockage auprès d'une StorageClass. Il s'agit du modèle de provisioning statique. Pour le modèle de provisioning dynamique, dans lequel Kubernetes crée automatiquement des volumes à partir d'une StorageClass, consultez Provisionner une classe de stockage dédiée aux services d'environnements du Dynamic Engine.

Le graphique Dynamic Engine (pour le volume de registre embarqué) et le graphique Environnement Dynamic Engine (pour les trois volumes de traitement) doivent être configurés séparément.

Procédure

Définissez les variables d'environnement de votre déploiement :
```
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>
```
Remplacez les valeurs des espaces de noms par votre version Dynamic Engine, l'ID de moteur et l'ID d'environnement réels.

Vérifiez que les PersistentVolumes et les PersistentVolumeClaims requis existent et qu'ils sont à l'état Bound (Lié) :

kubectl get pv

Vérifiez que la sortie liste les volumes prévus avec le statut Bound (Lié) et les espaces de noms de revendication corrects. Par exemple :

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

Remarque : La valeur de capacité 1200Gi est requise par l'API Kubernetes, mais elle n'est pas appliquée. Pour les volumes sauvegardés dans S3, la capacité de stockage réelle est déterminée par le compartiment S3 et non par ce champ.

Configurer et déployer le graphique Dynamic Engine

Créez un fichier de valeurs personnalisées pour le graphique Dynamic Engine, spécifiant le nom de revendication docker-registry :

cat <<EOF > $DYNAMIC_ENGINE_ID-custom-set-static-pvc-values.yaml
configuration:
  dockerRegistry:
    persistence:
      existingClaim: docker-registry
EOF

Déployez Dynamic Engine à l'aide du fichier de valeurs de base et du fichier de valeurs personnalisées :

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

Configurer et déployer le graphique Environnement Dynamic Engine

Créez un fichier de valeurs personnalisées pour le graphique Environnement Dynamic Engine, spécifiant les trois noms de revendication de volume de traitement :
```
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
```
Note InformationsRemarque : L'API Graphiques Helm nécessite des traits de soulignement pour les clés persistentVolumeClaims (job_data, custom_resources). Les noms PersistentVolumeClaim correspondants utilisent des traits d'union (job-data, custom-resources). Cette asymétrie est volontaire.

Déployez l'Environnement Dynamic Engine à l'aide du fichier de valeurs de base et du fichier de valeurs personnalisées :

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

Résultats

Dynamic Engine et son environnement sont maintenant exécutés avec les revendications PersistentVolumeClaims existantes. Vérifiez que le pod docker-registry de l'espace de noms qlik-dynamic-engine et le pod dpe-di-job-deployer de l'espace de noms qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID sont en cours d'exécution.

Que faire ensuite

Exécutez les commandes suivantes pour vérifier que les pods sont exécutés dans les deux espaces de noms :

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

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.

Laissez vos commentaires ici