Comment et pourquoi étendre un provider Terraform ?
La force de Terraform vient de son architecture modulaire qui a permis à la communauté de construire une galaxie de providers. Ces providers permettent de communiquer et configurer de nombreux services dans beaucoup de domaines facilitant grandement vos déploiements.
Sommaire
Si l'écosystème est riche, il arrive néanmoins qu’une fonctionnalité manque dans un provider, que ce besoin soit un cas particulier, ou simplement que le rythme de développement du projet Open-Source n’ait pas encore pu couvrir cette fonctionnalité.
La réponse la plus courante dans ce cas sera de développer soi-même le code manquant dans son projet, ce que j’ai été amené à faire.
Retour d’expérience
Pour répondre aux besoins de mon contexte que le provider communautaire Keycloak ne couvrait pas encore, j’ai créé un fork personnel du projet et ai écrit du code pour l’étendre selon mes besoins.
Ce code supplémentaire a été soumis en tant que contribution externe au projet upstream. Il est aujourd’hui publié dans la version 3.0.0.
La publication de cette nouvelle version majeure par le mainteneur a pris un peu de temps, j’ai donc moi-même publié un provider public pendant la phase de transition.
Détaillons maintenant l’approche qui a mené à ce résultat.
Étendre le provider dans un fork
Un provider Terraform public aura le plus souvent son code hébergé dans un dépôt Github, car c’est la plateforme qui a un support direct. Le code est écrit en Golang, comme pour le binaire Terraform lui-même dont le provider est un plugin. Il existe de nombreux tutoriels à propos du développement Terraform, je vous recommande ces pages : HashiCorp Provider Design Principles et Call APIs with Terraform Providers pour approfondir ce sujet. Le fait d’étendre un provider existant fournit déjà une base de code montrant les principes d’écriture.
Github aborde l’Open-Source en favorisant la création de fork des projets pour intégrer le code modifié. Il est donc conseillé de créer ce fork et d’écrire le code manquant pour la fonctionnalité désirée dans une branche dédiée.
La contribution en soumettant le code modifié dans une Pull Request dans le projet upstream du provider est vivement conseillée pour faciliter le suivi et le maintien des nouvelles fonctionnalités par la communauté, bien entendu à condition que la contribution soit acceptée.
Dans mon cas, j’avais travaillé la fonctionnalité de manière à la rendre le plus générique possible, ce qui a permis l’acceptation de ma PR sans aucun échange avec le mainteneur principal.
Utiliser le code étendu durant la transition
Il arrive parfois, parce que la fonctionnalité proposée ne correspond pas à la roadmap du provider Open-Source ou simplement pour une question de délai, que le traitement de la PR par la communauté soit retardé. Dans ces cas là, mais également pour pouvoir tester (pour moi qui débute en développement Golang par exemple) et utiliser le nouveau code dans des conditions réelles, on pourra alors publier sa propre nouvelle version du provider.
En effet, la gestion des providers dans Terraform a été grandement améliorée dans la version 0.13. Pour profiter au maximum de ses fonctionnalités, elle dépend cependant de l’accès à un système implémentant le standard API registry. La première implémentation qui est d’ailleurs la source par défaut de ce système est le Registry public officiel Terraform.
Le code source d’un provider déjà publié intègre un modèle de pipeline permettant la publication de nouvelles versions dans cette registry, il lui manquera juste les informations de connexion/authentification auprès du service. La publication passe par l'envoi des binaires signés par une clé GPG partagée avec le service de la registry.
Il existe plusieurs manières d’implémenter cet envoi, que vous pouvez retrouver documentées ici. La solution que je vous conseille passe par la mise en place d’un pipeline Github Actions exposé en exemple par l’éditeur de Terraform dans ce projet. Le workflow exploite des outils classiques du langage Golang.
La registry peut aussi s’enregistrer en tant qu’application auprès de Github pour suivre l'activité du projet via les événements pour publier les nouvelles versions.
La registry n’acceptera que les binaires par plateformes ciblées et portant un numéro de version respectant le semantic versioning. La registry récupérera automatiquement la documentation fournie accompagnant le provider dans le format suivant.
Le passage de ma version étendue à la version finale du provider communautaire intégrant ces fonctionnalités développées s’est fait très simplement : une référence à changer dans la déclaration du provider.
En conclusion
A vous de jouer ! Si vous tombez sur une fonctionnalité manquante dans un de vos providers favoris, vous savez quoi faire ! A l’heure où j’écris ces lignes, nous avons identifié un autre besoin non couvert par le provider Keycloak et allons contribuer à nouveau d’ici peu.
