J’ai aussi volontairement omis certaines bonnes pratiques qui auraient pu rendre la stack plus robuste, plus performante ou plus sécurisée.

A présent, j’ai un peu plus de temps, je vais reprendre cette série pour améliorer la stack et corriger les oublis.

Un onboarding plus simple

La stack étant un clone d’un repo proposé par HashiCorp, il n’y a qu’une configuration minimale pour que la stack fonctionne (en même temps c’est ce qu’on lui demande …).

Ici nous allons adopter quelques bonnes pratiques pour rendre l’onboarding plus simple et plus rapide pour un nouvel arrivant ou pour reprendre la main sur le repo après plusieurs années d’abandon.

Ajout d’un Makefile pour simplifier les commandes

Je suis un peu paresseux et je trouve les commandes terraform assez pénibles à taper, en solo j’utilise beaucoup d’alias pour me simplifier la vie. En équipe il est préférable d’avoir un moyen uniformisé pour centraliser les commandes et éviter les drifts de configuration, j’ai choisi ici d’utiliser un Makefile.

Installation

Page officielle de Make

Sinon :

scoop install main/make #Windows
brew install make #MacOS
make --version

Ensuite créez un fichier Makefile à la racine du repo et ajoutez-y les commandes terraform que vous utilisez le plus souvent.

Exemple minimal

TFVARS_FILE := terraform.tfvars

.PHONY: init validate fmt plan apply destroy output clean

install:
	scoop install terraform

init:
	terraform init

validate: init
	terraform validate

plan: init
	terraform plan -var-file=$(TFVARS_FILE)

apply: init
	terraform apply -var-file=$(TFVARS_FILE)

Notez ici la présence de la commande install qui permet d’installer terraform sur votre machine.

Utilisation

make install
make plan
make apply

Vous pouvez trouver un exemple complet dans le repo TheForge Si vous préférez le yaml vous pouvez aussi utiliser Task qui fonctionne de la même manière.

Mise à jour du README

C’est LE point d’entrée pour un nouvel arrivant sur le projet. Il est donc important de le tenir à jour et de le rendre le plus clair possible. Je me suis focalisé sur les éléments primordiaux :

• Pre-requis
  • Outils à installer (terraform, kubectl, helm, …)
  • Accès aux différents comptes cloud (AWS, GCP, Azure, …)
• Architecture
  • Diagramme d’architecture
  • Description des différents composants et de leurs interactions
• Usage
  • Comment installer le nécessaire pour le repo
  • Comment appliquer les changements

La liste est bien entendu exhaustive mais il s’agit d’un bon début.

Une boucle de feedback plus rapide

Une fois que vous avez installer l’essentiel et que vous vous êtes familiarisé avec la stack, il est temps de passer à l’étape suivante : améliorer la boucle de feedback pour gagner du temps et éviter les erreurs.

Pre-commit : le dernier garde fou avant la CI

J’affectionne particulièrement pre-commit, un outil qui permet d’exécuter des hooks avant chaque commit et qui est très pratique pour vérifier la qualité du code, le formatage, la sécurité, etc.

Pour l’installer je m’appuie sur mon Makefile en rajoutant la configuration suivante :

install:
	scoop install terraform
	pip install pre-commit
	pre-commit install

Mon choix d’outils pour le pre-commit

J’aime beaucoup m’appuyer sur pre-commit-terraform qui proposent une série de hooks pré-configurés pour vérifier la qualité du code, le formatage, la sécurité, etc.

Utilisation

.precommit-config.yaml

-   repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.106.0
    hooks:
      - id: terraform_fmt
      - id: terraform_validate
      - id: terraform_tflint
      - id: terraform_checkov

Ici l’idée est d’optimiser les étapes pour que le développeur puisse avoir un feedback rapide sur son code avant de pousser ses changements vers la CI/CD et d’aller plus loin dans le process de développement. On détecte les erreurs le plus tôt possible pour éviter de perdre du temps et de l’énergie à corriger des erreurs qui auraient pu être évitées.

Voici typiquement un scénario GitOps approprié :

  flowchart TD
    A[Changement locaux] -->|commit| B[Validation avec pre-commit]
    B --> |push git + PR| C[Revue de code + CI/CD]
    C -->|merge| D[Application des changements sur le cluster]

Les hooks

La stratégie peut varier en fonction de l’équipe et du projet, mais voici quelques hooks que j’utilise personnellement pour mes projets Terraform :

• terraform_fmt: pour formater le code Terraform
• terraform_validate: pour valider la syntaxe et la structure du code Terraform
• tflint: pour détecter les erreurs et les problèmes de style dans le code Terraform
• checkov: pour détecter les problèmes de sécurité dans le code Terraform

N’hésitez pas à consulter la liste des hooks disponibles sur le repo pre-commit-terraform.

Conclusion

Dans cet article nous avons fait un pas supplémentaire vers une implémentation state of the art de GitOps dans un repository Terraform. Dans la prochaine partie nous allons nous intéresser à la CI/CD.