Effectuer des traitements temporaires lors du déploiement d'un helm chart
Tags: kubernetes, sre, devops
Published: 2023-02-27 15:11:00

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*
```yaml
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*

```yaml
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*
```yaml
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
- https://helm.sh/docs/topics/charts_hooks/

---

J'espère que ça vous aidera! 🍺

---

<center><h3>Vous voulez me supporter?</h3></center>
<a href="https://www.buymeacoffee.com/mxguilbert7" target="_blank"><img src="https://cdn.buymeacoffee.com/buttons/default-orange.png" alt="Buy Me A Coffee" height="41" width="174"></a>