Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Gérer les hooks d'exécution de protection Trident

Contributeurs netapp-aruldeepa
PDF

Un hook d'exécution est une action personnalisée que vous pouvez configurer pour qu'elle s'exécute conjointement avec une opération de protection des données d'une application gérée. Par exemple, si vous disposez d'une application de base de données, vous pouvez utiliser un hook d'exécution pour suspendre toutes les transactions de base de données avant un instantané et reprendre les transactions une fois l'instantané terminé. Cela garantit des instantanés cohérents avec les applications.

Types de hooks d'exécution

Trident Protect prend en charge les types de hooks d'exécution suivants, en fonction du moment où ils peuvent être exécutés :

  • Pré-instantané

  • Post-instantané

  • Pré-sauvegarde

  • Post-sauvegarde

  • Post-restauration

  • Après le basculement

Ordre d'exécution

Lorsqu'une opération de protection des données est exécutée, les événements de hook d'exécution se produisent dans l'ordre suivant :

  1. Tous les hooks d’exécution de pré-opération personnalisés applicables sont exécutés sur les conteneurs appropriés. Vous pouvez créer et exécuter autant de hooks de pré-opération personnalisés que vous le souhaitez, mais l'ordre d'exécution de ces hooks avant l'opération n'est ni garanti ni configurable.

  2. Des blocages du système de fichiers se produisent, le cas échéant. "Apprenez-en davantage sur la configuration du gel du système de fichiers avec Trident Protect.".

  3. L'opération de protection des données est effectuée.

  4. Les systèmes de fichiers gelés sont dégelés, le cas échéant.

  5. Tous les hooks d’exécution post-opération personnalisés applicables sont exécutés sur les conteneurs appropriés. Vous pouvez créer et exécuter autant de hooks post-opération personnalisés que vous le souhaitez, mais l'ordre d'exécution de ces hooks après l'opération n'est ni garanti ni configurable.

Si vous créez plusieurs hooks d'exécution du même type (par exemple, pré-snapshot), l'ordre d'exécution de ces hooks n'est pas garanti. Cependant, l'ordre d'exécution des hooks de différents types est garanti. Par exemple, voici l’ordre d’exécution d’une configuration qui possède tous les différents types de hooks :

  1. Hooks pré-instantanés exécutés

  2. Hooks post-instantanés exécutés

  3. Hooks de pré-sauvegarde exécutés

  4. Hooks post-sauvegarde exécutés

Remarque L'exemple de commande précédent ne s'applique que lorsque vous exécutez une sauvegarde qui n'utilise pas d'instantané existant.
Remarque Vous devez toujours tester vos scripts d’exécution avant de les activer dans un environnement de production. Vous pouvez utiliser la commande « kubectl exec » pour tester facilement les scripts. Après avoir activé les hooks d’exécution dans un environnement de production, testez les snapshots et les sauvegardes résultants pour vous assurer qu’ils sont cohérents. Vous pouvez le faire en clonant l’application dans un espace de noms temporaire, en restaurant l’instantané ou la sauvegarde, puis en testant l’application.
Remarque Si un hook d’exécution pré-snapshot ajoute, modifie ou supprime des ressources Kubernetes, ces modifications sont incluses dans le snapshot ou la sauvegarde et dans toute opération de restauration ultérieure.

Remarques importantes sur les hooks d'exécution personnalisés

Tenez compte des éléments suivants lors de la planification des hooks d’exécution pour vos applications.

  • Un hook d'exécution doit utiliser un script pour effectuer des actions. De nombreux hooks d’exécution peuvent référencer le même script.

  • Trident Protect exige que les scripts utilisés par les hooks d'exécution soient écrits au format de scripts shell exécutables.

  • La taille du script est limitée à 96 Ko.

  • Trident Protect utilise les paramètres d'exécution et tous les critères correspondants pour déterminer quels hooks sont applicables à une opération de snapshot, de sauvegarde ou de restauration.

Remarque Étant donné que les hooks d'exécution réduisent ou désactivent souvent complètement les fonctionnalités de l'application sur laquelle ils s'exécutent, vous devez toujours essayer de minimiser le temps d'exécution de vos hooks d'exécution personnalisés. Si vous démarrez une opération de sauvegarde ou de snapshot avec des hooks d'exécution associés, mais que vous l'annulez ensuite, les hooks sont toujours autorisés à s'exécuter si l'opération de sauvegarde ou de snapshot a déjà commencé. Cela signifie que la logique utilisée dans un hook d’exécution post-sauvegarde ne peut pas supposer que la sauvegarde a été terminée.

Filtres de crochet d'exécution

Lorsque vous ajoutez ou modifiez un hook d'exécution pour une application, vous pouvez ajouter des filtres au hook d'exécution pour gérer les conteneurs auxquels le hook correspondra. Les filtres sont utiles pour les applications qui utilisent la même image de conteneur sur tous les conteneurs, mais peuvent utiliser chaque image à des fins différentes (comme Elasticsearch). Les filtres vous permettent de créer des scénarios dans lesquels les hooks d'exécution s'exécutent sur certains conteneurs identiques, mais pas nécessairement sur tous. Si vous créez plusieurs filtres pour un seul hook d'exécution, ils sont combinés avec un opérateur AND logique. Vous pouvez avoir jusqu'à 10 filtres actifs par hook d'exécution.

Chaque filtre que vous ajoutez à un hook d’exécution utilise une expression régulière pour faire correspondre les conteneurs de votre cluster. Lorsqu'un hook correspond à un conteneur, le hook exécutera son script associé sur ce conteneur. Les expressions régulières pour les filtres utilisent la syntaxe d'expression régulière 2 (RE2), qui ne prend pas en charge la création d'un filtre excluant les conteneurs de la liste des correspondances. Pour plus d'informations sur la syntaxe prise en charge par Trident Protect pour les expressions régulières dans les filtres de hook d'exécution, consultez "Prise en charge de la syntaxe des expressions régulières 2 (RE2)" .

Remarque Si vous ajoutez un filtre d'espace de noms à un hook d'exécution qui s'exécute après une opération de restauration ou de clonage et que la source et la destination de restauration ou de clonage se trouvent dans des espaces de noms différents, le filtre d'espace de noms est appliqué uniquement à l'espace de noms de destination.

Exemples de crochets d'exécution

Visitez le "Projet GitHub NetApp Verda" pour télécharger de véritables hooks d'exécution pour des applications populaires telles qu'Apache Cassandra et Elasticsearch. Vous pouvez également voir des exemples et obtenir des idées pour structurer vos propres hooks d'exécution personnalisés.

Créer un point d'accroche d'exécution

Vous pouvez créer un point d'exécution personnalisé pour une application utilisant Trident Protect. Vous devez disposer des autorisations de propriétaire, d'administrateur ou de membre pour créer des points d'exécution.

Utilisez un CR
Étapes

  1. Créez le fichier de ressource personnalisée (CR) et nommez-le. trident-protect-hook.yaml .

  2. Configurez les attributs suivants pour qu'ils correspondent à votre environnement Trident Protect et à la configuration de votre cluster :

    • metadata.name : (Obligatoire) Le nom de cette ressource personnalisée ; choisissez un nom unique et pertinent pour votre environnement.

    • spec.applicationRef: (Obligatoire) Le nom Kubernetes de l'application pour laquelle exécuter le hook d'exécution.

    • spec.stage: (Obligatoire) Une chaîne de caractères indiquant à quelle étape de l'action le hook d'exécution doit s'exécuter. Valeurs possibles :

      • Pré

      • Poste

    • spec.action: (Obligatoire) Une chaîne indiquant l'action que le hook d'exécution entreprendra, en supposant que tous les filtres de hook d'exécution spécifiés correspondent. Valeurs possibles :

      • Instantané

      • Sauvegarde

      • Restaurer

      • Basculement

    • spec.enabled: (Optionnel) Indique si ce point d'accroche d'exécution est activé ou désactivé. Si aucune valeur n'est spécifiée, la valeur par défaut est « vrai ».

    • spec.hookSource: (Obligatoire) Une chaîne contenant le script de hook encodé en base64.

    • spec.timeout: (Optionnel) Un nombre définissant la durée en minutes pendant laquelle le hook d'exécution est autorisé à s'exécuter. La valeur minimale est de 1 minute, et la valeur par défaut est de 25 minutes si elle n'est pas spécifiée.

    • spec.arguments: (Optionnel) Une liste YAML d'arguments que vous pouvez spécifier pour le hook d'exécution.

    • spec.matchingCriteria: (Optionnel) Une liste facultative de paires clé-valeur de critères, chaque paire constituant un filtre de crochet d'exécution. Vous pouvez ajouter jusqu'à 10 filtres par point d'exécution.

    • spec.matchingCriteria.type: (Optionnel) Une chaîne identifiant le type de filtre de crochet d'exécution. Valeurs possibles :

      • Image conteneur

      • Nom du conteneur

      • Nom du pod

      • Étiquette de podcast

      • Nom de l'espace de noms

    • spec.matchingCriteria.value: (Optionnel) Une chaîne de caractères ou une expression régulière identifiant la valeur du filtre du point d'exécution.

      Exemple de YAML :

    apiVersion: protect.trident.netapp.io/v1
kind: ExecHook
metadata:
  name: example-hook-cr
  namespace: my-app-namespace
  annotations:
    astra.netapp.io/astra-control-hook-source-id: /account/test/hookSource/id
spec:
  applicationRef: my-app-name
  stage: Pre
  action: Snapshot
  enabled: true
  hookSource: IyEvYmluL2Jhc2gKZWNobyAiZXhhbXBsZSBzY3JpcHQiCg==
  timeout: 10
  arguments:
    - FirstExampleArg
    - SecondExampleArg
  matchingCriteria:
    - type: containerName
      value: mysql
    - type: containerImage
      value: bitnami/mysql
    - type: podName
      value: mysql
    - type: namespaceName
      value: mysql-a
    - type: podLabel
      value: app.kubernetes.io/component=primary
    - type: podLabel
      value: helm.sh/chart=mysql-10.1.0
    - type: podLabel
      value: deployment-type=production

  3. Après avoir rempli le fichier CR avec les valeurs correctes, appliquez le CR :

    kubectl apply -f trident-protect-hook.yaml
Utiliser la CLI
Étapes

  1. Créez le point d'exécution en remplaçant les valeurs entre crochets par les informations provenant de votre environnement. Par exemple:

    tridentctl-protect create exechook <my_exec_hook_name> --action <action_type> --app <app_to_use_hook> --stage <pre_or_post_stage> --source-file <script-file> -n <application_namespace>

Exécuter manuellement un hook d'exécution

Vous pouvez exécuter manuellement un hook d'exécution à des fins de test ou si vous devez le réexécuter manuellement après un échec. Vous devez disposer des autorisations de propriétaire, d'administrateur ou de membre pour exécuter manuellement les hooks d'exécution.

L'exécution manuelle d'un hook se compose de deux étapes de base :

  1. Créez une sauvegarde des ressources, qui collecte les ressources et en crée une copie, déterminant ainsi où le hook s'exécutera.

  2. Exécutez le script d'exécution sur la sauvegarde

Étape 1 : Créer une sauvegarde des ressources
Utilisez un CR
Étapes

  1. Créez le fichier de ressource personnalisée (CR) et nommez-le. trident-protect-resource-backup.yaml .

  2. Configurez les attributs suivants pour qu'ils correspondent à votre environnement Trident Protect et à la configuration de votre cluster :

    • metadata.name : (Obligatoire) Le nom de cette ressource personnalisée ; choisissez un nom unique et pertinent pour votre environnement.

    • spec.applicationRef: (Obligatoire) Le nom Kubernetes de l'application pour laquelle créer la sauvegarde de ressource.

    • spec.appVaultRef: (Obligatoire) Le nom de l'AppVault où sont stockés les contenus de sauvegarde.

    • spec.appArchivePath : Chemin d’accès dans AppVault où sont stockés les contenus de sauvegarde. Vous pouvez utiliser la commande suivante pour trouver ce chemin :

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'

      Exemple de YAML :

    ---
apiVersion: protect.trident.netapp.io/v1
kind: ResourceBackup
metadata:
  name: example-resource-backup
spec:
  applicationRef: my-app-name
  appVaultRef: my-appvault-name
  appArchivePath: example-resource-backup

  3. Après avoir rempli le fichier CR avec les valeurs correctes, appliquez le CR :

    kubectl apply -f trident-protect-resource-backup.yaml
Utiliser la CLI
Étapes

  1. Créez la sauvegarde en remplaçant les valeurs entre crochets par les informations provenant de votre environnement. Par exemple:

    tridentctl protect create resourcebackup <my_backup_name> --app <my_app_name> --appvault <my_appvault_name> -n <my_app_namespace> --app-archive-path <app_archive_path>

  2. Consultez l'état de la sauvegarde. Vous pouvez utiliser cette commande d'exemple à plusieurs reprises jusqu'à ce que l'opération soit terminée :

    tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name>

  3. Vérifiez que la sauvegarde a réussi :

    kubectl describe resourcebackup <my_backup_name>
Étape 2 : Exécuter le hook d’exécution
Utilisez un CR
Étapes

  1. Créez le fichier de ressource personnalisée (CR) et nommez-le. trident-protect-hook-run.yaml .

  2. Configurez les attributs suivants pour qu'ils correspondent à votre environnement Trident Protect et à la configuration de votre cluster :

    • metadata.name : (Obligatoire) Le nom de cette ressource personnalisée ; choisissez un nom unique et pertinent pour votre environnement.

    • spec.applicationRef : (Obligatoire) Assurez-vous que cette valeur corresponde au nom de l’application de la ressource de sauvegarde que vous avez créée à l’étape 1.

    • spec.appVaultRef : (Obligatoire) Assurez-vous que cette valeur correspond à l’appVaultRef de la ressource CR ResourceBackup que vous avez créée à l’étape 1.

    • spec.appArchivePath : Assurez-vous que cette valeur correspond à appArchivePath de la ressource personnalisée ResourceBackup que vous avez créée à l’étape 1.

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'

    • spec.action: (Obligatoire) Une chaîne indiquant l'action que le hook d'exécution entreprendra, en supposant que tous les filtres de hook d'exécution spécifiés correspondent. Valeurs possibles :

      • Instantané

      • Sauvegarde

      • Restaurer

      • Basculement

    • spec.stage: (Obligatoire) Une chaîne de caractères indiquant à quelle étape de l'action le hook d'exécution doit s'exécuter. Cette opération d'accrochage ne permettra pas d'accrocher les hameçons à aucune autre étape. Valeurs possibles :

      • Pré

      • Poste

        Exemple de YAML :

    ---
apiVersion: protect.trident.netapp.io/v1
kind: ExecHooksRun
metadata:
  name: example-hook-run
spec:
  applicationRef: my-app-name
  appVaultRef: my-appvault-name
  appArchivePath: example-resource-backup
  stage: Post
  action: Failover

  3. Après avoir rempli le fichier CR avec les valeurs correctes, appliquez le CR :

    kubectl apply -f trident-protect-hook-run.yaml
Utiliser la CLI
Étapes

  1. Créer la requête d'exécution manuelle du hook :

    tridentctl protect create exechooksrun <my_exec_hook_run_name> -n <my_app_namespace> --action snapshot --stage <pre_or_post> --app <my_app_name> --appvault <my_appvault_name> --path <my_backup_name>

  2. Vérifiez l'état d'exécution du hook. Vous pouvez exécuter cette commande à plusieurs reprises jusqu'à ce que l'opération soit terminée :

    tridentctl protect get exechooksrun -n <my_app_namespace> <my_exec_hook_run_name>

  3. Décrivez l'objet exechooksrun pour voir les détails et l'état finaux :

    kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>