Lorsqu'on déploie un helm chart, il est possible que l'on veut pouvoir effectuer quelques traitements avant et/ou après. On pense alors à utiliser des Job, mais ces dernières ne sont pas forcément les meilleures vis à vis de la configuration sur le moment où les exécuter, de plus leur suppression automatisée n'est pas optimale. (cf https://dev.to/mxglt/supprimer-automatiquement-une-job-dans-kubernetes-3d5g).
Du coup, si vous utilisez Helm, on va voir aujourd'hui quelque chose qui va résoudre tout ces soucis : les Hooks.
Qu'est-ce que sont les hooks?
Les Hooks sont un mécanisme qui permettent d'exécuter des traitements particuliers à des moments précis du cycle de vie du chart.
Pour définir ces traitements, on va ajouter des annotations à une Job Kubernetes qui vont permettre de définir 3 choses :
- Le moment où la job doit être exécutée
- Sa priorité (si jamais plusieurs jobs sont déclanchées par le même hook)
- Comment la supprimer
Moment où la job doit être exécutée
C'est l'annotation helm.sh/hook qui va nous permettre de définir le(s) moment(s) où la job va être lancée. Actuellement, voici les hooks disponibles:
-
pre-install: Exécuté après le rendu des templates, mais avant que les ressource du chart soient créées dans le cluster Kubernetes (Ne s'exécute pas lors d'une mise à jour) -
post-install: Exécuté après la création de toutes les ressources dans Kubernetes (Ne s'exécute pas lors d'une mise à jour) -
pre-delete: Exécuté avant la suppression d'un chart -
post-delete: Exécuté après la suppression d'un chart -
pre-upgrade: Exécuté après le rendu des templates, mais avant la mise à jour des ressources (Ne s'exécute pas lors d'une installation) -
post-upgrade: Exécuté après la mise à jour des ressources sur Kubernetes (Ne s'exécute pas lors d'une installation) -
pre-rollback: Exécuté avant un retour à une version précédente -
post-rollback: Exécuté après un retour à une version précédente -
test: Exécuté avec la commande helm test
Avec un panel de possibilités comme celui-ci, il devient alors facile de :
- installer des CRDs avant l'installation d'un opérateur
- d'exécuter un script de nettoyage après une suppression
- d'avoir de manière automatisé l'ensemble des commandes à exécuter pour passer d'une version A à B et inversement
Exemple
annotations:
"helm.sh/hook": post-install,post-upgrade
La priorité
Pour définir la priorité d'une job dans l'ensemble des jobs lancées via un même hook, il faut utiliser l'annotation helm.sh/hook-weight. Comme valeur, il suffit de donner un nombre positif ou négatif, mais qui doit être déclaré en tant que string.
Exemple
annotations:
"helm.sh/hook-weight": "-5"
La méthode de suppression
Après qu'une job se soit terminée, on veut être capable de pouvoir la supprimer. Helm nous permet de le définir avec l'annotation helm.sh/hook-ddelete-policy.
3 valeurs sont possibles :
-
before-hook-creation: Qui va supprimer l'ancienne instance de la job avant qu'un nouveau hook soit déclanché (par défaut) -
hook-succeeded: Qui supprime la job si tout s'est bien déroulé durant l'exécution du hook -
hook-failed: Qui va supprimer la job si il y a eu un soucis durant l'exécution du hook.
Exemple
annotations:
"helm.sh/hook-delete-policy": hook-succeeded
En conclusion, vous pouvez voir que Helm permet au travers de ces hooks d'ajouter une couche de dynamisme qui sait se montrer très utile dans le processus d'automatisation d'une solution.
Liens
J'espère que ça vous aidera! 🍺
Vous voulez me supporter?
Top comments (0)