Sortie de la version 0.2 du provider terraform pour cilium

5 min readApr 9, 2024

Une seconde version majeure du provider terraform pour cilium vient de sortir. La première version était sortie le 21 décembre 2023. C’est l’occasion de faire un bilan de 4 mois de développement du provider.

Si vous ne savez pas ce qu’est un provider terraform, je vous propose au moins de lire le début de cet article : Créer un provider Terraform (Partie 1).

Pourquoi créer un provider ?

Avant de vous donner les nouveautés de cette nouvelle version. Je vais vous expliquer pourquoi j’ai créé ce provider terraform.

Ma motivation numéro une était plus pour apprendre comment créer un provider terraform. J’utilise au quotidien terraform avec différents providers. Je pense avoir une expertise dessus : comment bien coder en terraform ? Comment organiser son code terraform ? Etc. Mais je ne connaissais pas bien l’autre partie de l’iceberg : l’écriture d’un provider terraform. L’intérêt de savoir cela va me permettre de contribuer en cas de nécessité d’une nouveauté dans un provider par exemple. Mais ça va également me permettre de comprendre aussi les bugs possibles des providers et mieux rapporter des détails sur les bugs en questions.

Ensuite une autre motivation était de créer un projet utile enfin j’espère. Pourquoi utiliser le provider terraform pour cilium plutôt qu’un provider plus générique comme helm ? Le principal cas d’utilisation qui n’est pas possible avec le provider helm est la création d’un Cluster Mesh avec Cilium. Le Cluster Mesh permet de communiquer entre pods de différents clusters kubernetes sans devoir passer par un ingress controller ou api gateway.

Voici par exemple une utilisation possible du Cluster Mesh :

Haute disponibilité en cluster kubernetes

Comme autre intérêt d’utiliser ce provider : pour les “débutants” ou pour ceux qui veulent avoir un Kubernetes avec cilium sans se prendre la tête : le provider va détecter automatiquement sur quel type de cluster Kubernetes il est ? EKS ? AKS ? Kind ? Il va alors éventuellement désactiver le CNI par défaut et mettre les bonnes options pour que cela fonctionne.

Enfin une resource kubeproxy-free a été créée pour supprimer les pods kube-proxy si on a besoin d’utiliser cilium avec le mode kubeproxy free (voir ici si vous ne savez pas ce que c’est). Je ne connais pas d’autres providers qui permettent de faire cela.

Comment j’ai fait cela en si peu de temps ?

J’ai commencé à créer ce provider en décembre 2023. Donc le provider a environ 4 mois. Par ailleurs je n’ai pas travaillé cela à plein temps. Je me suis basé sur deux choses :

le repo de “fondation” d’hashicorp : https://github.com/hashicorp/terraform-provider-scaffolding-framework pour bien partir
les bibliothèques de cilium-cli : https://github.com/cilium/cilium-cli

Pour les mises à jour de bibliothèques, j’utilise principalement renovate qui me fait des Pull Requests automatiquement.

J’ai mélangé le tout, j’ai rajouté quelques ingrédients et voilà c’est tout.

Les nouveautés de la 0.2

La version 0.1 marquait surtout la création des principales ressources utiles pour le déploiement de cilium, cilium_clustermesh pour le déploiement de cilium, Cluster Mesh, etc.

Depuis cette version, on peut noter de l’industrialisation de tests :

Création de tests d’acceptation dans la CI de la plupart des ressources
Création de tests fonctionnels dans la CI de quelques ressources
Les tests de CI sont faits avec terraform et avec opentofu (eh oui une première version stable d’opentofu est apparue depuis la 0.1)

Quelques fonctionnalités sympathiques :

La ressource cilium a maintenant une valeur helm_values qui permet de récupérer le fichier values.yaml de helm qui override les valeurs par défaut
Possibilité d’utiliser différentes helm release (utile si on veut faire une mise à jour de cilium avec le preflight)
Le namespace est uniquement défini sur le provider (tout comme helm release)
Création du provider pulumi prenant les bibliothèques du provider terraform (sera mis à jour si réellement utilisé)

Pas mal d’améliorations moins visibles :

Refactorisation du code pour que ça soit plus proche du code “standard” d’un provider (standard = proche du code de base du provider terraform scafolding).
Correction de bugs
Mise à jour des différentes bibliothèques qui dépendent du projet (notamment cilium-cli qui est passé de v0.15.19 vers v0.16.3)

J’ai également corrigé un bug au niveau de cilium-cli qui empêchait de supprimer le Cluster Mesh.

Pas de révolution mais surtout de la stabilisation du projet. La version 0.2 reste dans un statut expérimental notamment par le manque d’utilisateurs et par la jeunesse du projet). Il peut y avoir des breaking changes entre deux versions mineures. Je préfère ne pas avoir de dettes techniques pour l’instant comme je ne pense pas qu’il ait utilisé en production.

Que prévoir pour la version 0.3 ?

Je n’ai pas de roadmap sur les nouveautés. Ça va également dépendre du temps que j’ai à y consacrer et si j’ai des demandes.

À part des corrections de bugs et mise à jour de dépendances, quelques idées qui me viennent :

créer des repos qui vont aider les utilisateurs à utiliser le provider en créant des exemples avec différents kubernetes. Ça me permettra également de voir s’il y a des moyens d’améliorer le provider.
améliorer l’expérience de la création d’un Cluster Mesh. Je ne suis pas totalement satisfait de devoir passer par 3 ressources différentes pour en créer.
améliorer l’expérience de mise à jour de cilium
créer de nouvelles ressources pour le provider

Je ne promet pas que ça sera dans la version 0.3 ou qu’il n’y aura pas autres choses mais ce sont les idées que j’ai pour l’instant. Si vous en avez d’autres n’hésitez pas à me contacter.