opentofu-modules

Modules OpenTofu réutilisables pour installer des operators Kubernetes (CRD + manifests officiels) sur un cluster déjà provisionné.

Repo complémentaire à opentofu-scaleway-modules, qui exclut volontairement toute ressource Kubernetes de son périmètre. Les modules qui font exception à cette règle — parce qu'un module d'installation d'operator sans ces ressources n'aurait aucune substance — vivent ici plutôt que là-bas.

Modules disponibles

Module	Rôle
elasticsearch-operator	Installation de l'operator ECK (Elastic Cloud on Kubernetes)
rabbitmq-operator	Installation des operators RabbitMQ (Cluster Operator + Messaging Topology Operator)

Chaque module a son propre README.md avec un exemple d'utilisation et les particularités à connaître.

Conventions

• Pas de bloc provider dans les modules : chaque module hérite des providers configurés par le repo consommateur (bonne pratique pour un module destiné à être réutilisé dans des contextes différents — clusters, credentials distincts). Typiquement, le provider kubernetes est configuré côté repo consommateur à partir des outputs du module kubernetes-cluster de opentofu-scaleway-modules (apiserver_url, token/kubeconfig, cluster_ca_certificate).
• Aucune version par défaut pour les versions d'operator (eck_version, cluster_operator_version...) : chaque repo consommateur maîtrise explicitement la version installée et sa montée de version.
• patch_dir : chaque module accepte un répertoire de patches (strategic merge patch, fichiers <Kind>--<name>.yml) permettant de personnaliser un manifest sans forker le module.

Consommation depuis un repo applicatif

Chaque module se référence via une source git versionnée par tag, par exemple :

module "elasticsearch_operator" {
  source = "git::https://<url-de-ce-repo>//modules/elasticsearch-operator?ref=elasticsearch-operator-vX.Y.Z"
  # ...
}

L'intégration dans les repos client (remplacement du code dupliqué par des appels à ces modules, choix des tags de version) est gérée séparément, hors périmètre de ce repo.

Ajouter un nouveau module

1. Créer modules/<nom-du-module>/ avec la structure habituelle : main.tf, variables.tf, outputs.tf, versions.tf (bloc terraform.required_providers, sans bloc provider, cf Conventions), et un README.md (rôle du module, exemple d'utilisation, remarques). Ne pas créer de CHANGELOG.md : il est généré par release-please (cf Publication des releases).
2. Ajouter une ligne au tableau Modules disponibles ci-dessus.
3. Enregistrer le module dans release-please, dans les deux fichiers à la racine du repo :
   • release-please-config.json : ajouter une entrée "modules/<nom-du-module>": {"component": "<nom-du-module>", "changelog-path": "CHANGELOG.md"}.
   • .release-please-manifest.json : ajouter "modules/<nom-du-module>": "0.0.0" (version de départ avant toute release — release-please calculera la première version réelle, typiquement 1.0.0, à partir des commits).
4. Valider avec tofu fmt -recursive puis, dans le répertoire du module, tofu init -backend=false && tofu validate (cf Validation) ; supprimer ensuite .terraform/ et .terraform.lock.hcl générés par cette validation avant de commit.
5. Committer avec un message conventionnel feat(<nom-du-module>): ... (déclenche un bump minor côté release-please), ouvrir une PR et la merger sur main.
6. release-please ouvre alors automatiquement une PR séparée chore(main): release <nom-du-module> X.Y.Z avec le CHANGELOG.md du module ; la merger crée le tag <nom-du-module>-vX.Y.Z et la release GitHub, immédiatement utilisable via ref=<nom-du-module>-vX.Y.Z (cf Consommation depuis un repo applicatif).

Publication des releases

Les tags et les releases GitHub sont générés automatiquement par release-please, à partir des messages de commit conventionnels. Il n'y a jamais de tag ni de version à créer ou éditer à la main : tout part d'un commit conventionnel, tout se termine par un merge de PR sur GitHub.

Versioning indépendant par module : chaque module du tableau Modules disponibles a son propre numéro de version et son propre tag, au format <module>-vX.Y.Z (ex: elasticsearch-operator-v1.0.0). release-please détermine, pour chaque module, quels commits ont modifié des fichiers sous modules/<module>/ depuis son dernier tag, et en déduit le bump (fix → patch, feat → minor, !/BREAKING CHANGE → major).

1. En local

1. Faire le changement dans modules/<module>/ et le committer avec un message conventionnel dont le type correspond au bump voulu :

   • fix(<module>): ... (patch) :
     incrémente le dernier chiffre (ex. 1.0.0 → 1.0.1). À utiliser pour une correction de bug.

   • feat(<module>): ... (minor) :
     incrémente le chiffre du milieu (ex. 1.0.0 → 1.1.0).
     À utiliser pour l'ajout d'une nouvelle fonctionnalité sans rupture de compatibilité.

   • feat(<module>)!: ... ou mention dans le footer BREAKING CHANGE: ... (major) :
     incrémente le premier chiffre (ex. 1.0.0 → 2.0.0).
     À utiliser pour une modification majeure qui casse la compatibilité.
     La mention peut se placer dans le titre via ! ou dans le pied de page (footer) du commit via BREAKING CHANGE:.

   • chore, docs, refactor… (pas de bump) : n'incrémente aucun numéro de version.
     Le changement est enregistré dans l'historique Git,
     mais ne génère aucune nouvelle version du module.

2. Ouvrir une PR normale avec ce commit et la merger sur main (revue de code habituelle, rien de spécifique à release-please à ce stade).

Rien d'autre à faire en local : pas de tag git tag, pas de fichier de version à modifier à la main (.release-please-manifest.json est réécrit automatiquement par la PR de release décrite ci-dessous).

2. Sur l'interface GitHub

3. Le merge sur main déclenche une Action GitHub qui ouvre (ou met à jour si elle existe déjà) une pull request chore(main): release <module> X.Y.Z par module impacté, avec le CHANGELOG.md proposé pour ce module. Un commit qui touche plusieurs modules à la fois (à éviter autant que possible) fait apparaître une PR de ce type par module touché.
4. Relire cette PR de release (numéro de version proposé, contenu du changelog) — c'est un commit généré, mais il reste éditable si besoin avant de merger.
5. Merger la PR de release directement depuis GitHub (bouton "Merge"). C'est ce merge, et lui seul, qui crée le tag Git <module>-vX.Y.Z et la release GitHub associée.
6. Le tag est alors immédiatement utilisable via ref=<module>-vX.Y.Z dans les repos consommateurs (cf Consommation depuis un repo applicatif).

Validation

Chaque module a été vérifié avec tofu init -backend=false && tofu validate et formaté avec tofu fmt -recursive.