Terraform on Zwindler's Reflection

Mes lectures des derniers mois - de novembre à mars 2025

Fri, 28 Mar 2025 12:00:00 +0200

Aparté : la dernière fois que je vous ai parlé de bouquins, j’ai commencé par vous dire que j’avais passé 6 mois pourris. Du coup, j’en profite d’avoir relu ça pour vous dire que ça va beaucoup mieux.

Après une sélection de livres pas super rigolos la dernière fois (hashtag VSS), on retrouve le sourire et j’ai dépiler 4 nouveaux livres, donc trois techniques (dans le sens, pour le travail).

Vous êtes prêt·es ? Zé bartyyyyyy

L’infrastructure as Code avec Terraform

Comme il me l’a offert (merci 😘), c’est avec une attention toute particulière que j’ai lu le livre de Julien Wittouck “L’infrastructure as Code avec Terraform”.

Je pense pas que j’ai besoin d’expliquer le contenu du livre. C’est un livre technique, ça parle de terraform, en partant des bases et de plus en plus complexe jusqu’à ce que vous connaissiez l’état de l’art.

C’était intéressant, même si je me suis rendu compte que je connaissais plus de choses que je pensais sur terraform et son univers, après années de pratique un peu “passive”.

J’ai appris quelques trucs sympa (c’est tout l’intérêt de ce genre de livres, on découvre toujours quelque chose), notamment sur les manipulations de states, quelques outils tiers bien sympathiques, et tout le chapitre sur les tests en 1.6+, car je m’étais arrêté sur terratest et n’avait pas suivi les évolutions dans le standard.

Sur les réseaux, on m’a demandé quel était l’intérêt de ce genre de livres alors qu’il y a pléthore d’articles et d’exemples sur Internet. Je passe volontairement le côté peut être pas super agréable du commentaire pour dire que je trouve toujours un intérêt aux bons vieux bouquins. Quand ils sont bien écrits, ils permettent de revoir depuis le début et avec toutes les bases bonnes pratiques qu’on aurait pu louper, même (surtout ?) après quelques années d’expérience en tant qu’autodidacte.

Cela étant dit, je pense que ça s’adresse quand même plutôt aux débutants, et probablement un peu moins pour les profils déjà (très) expérimentés.

Aveux coupable : j’ai quasiment sauté la partie certification (je pense que vous m’avez déjà suffisament entendu râler / troller sur Hashicorp pour savoir ce que j’en pense) mais de ce que j’ai vu il y a des conseils utiles pour celles et ceux qui ne savent pas comment ces épreuves se déroulent.

Julien Wittouck - L’infrastructure as Code avec Terraform

Tech Talks - How to get started speaking at technical conferences

La vie, c’est parfois du hasard, mais ce sont souvent plutôt des rencontres.

Robin Kanatzar, senior iOS engineer est une conférencière expérimentée. Après avoir coaché de nombreuses personnes débutantes dans les présentations techniques en conf, elle avait décidé d’écrire un livre pour rassembler tous ses conseils au sein d’un même ouvrage.

Pour alimenter son livre de point de vue tiers, elle avait fait un appel à d’autres speakers. Mon ancienne collègue et amie Chahrazed m’a mis en relation et j’ai eu la chance de pouvoir échanger avec Robin sur nos expériences respectives en conférence.

Une fois le livre sorti, Robin m’a gentiment offert le livre final, que j’ai dévoré l’ouvrage en trois jours (un peu comme celui de Pascal Martin, dont je parle ici).

Le point de vue de Robin est très rafraîchissant, c’est toujours incroyablement enrichissant de voir comment d’autres speakers abordent des difficultés que nous sommes nombreux / nombreuses à rencontrer (planification, stress, …). Comme après la lecture du livre de Pascal, j’ai gardé quelques tips que j’appliquerai à ma prochaine conférence (DevoxxFR).

Si certains conseils se recoupent évidemment entre les deux livres, l’angle est quand même globalement différent, beaucoup plus centrée sur la personne que sur la technique. À mon avis, ils sont complémentaires et je ne vous en conseille pas forcément l’un plus que l’autre. Seule différence notable, celui de Pascal est en français, alors que celui de Robin est en anglais, donc si vous n’êtes pas à l’aise avec une des deux langues, vous saurez lequel prioriser.

Robin Kanatzar - Tech Talks: How to get started speaking at technical conferences

Note : si le livre vous intéresse, j’ai quelques codes promo qu’il me reste (je ne gagne rien sur la vente, je dis ça en totale impartialité).

Visual thread intelligence - an illustrated guide for threat researchers

J’ai découvert ce livre en courant. Pour être parfaitement honnête, j’ai découvert l’existence de ce livre en écoutant le podcast de mon éminent collègue Martial, hôte de Hack and Speak, et qui invitait Thomas Roccia, auteur du livre.

L’idée derrière le bouquin est de combiner sur une double-page d’un côté une synthèse des différents concepts de la threat intel en cybersécurité, et une explication écrite pour l’accompagner.

Si j’ai bien aimé ce format hybride, très ludique et extrêmement efficace, je suis resté un peu sur ma faim.

Le livre promet s’adresser aux professionnels de la cybersécurité de tous les niveaux. Et clairement, c’est pas du tout mon ressenti.

Ne connaissant rien au sujet, j’ai appris beaucoup de chose et ma curiosité sur le sujet a été assouvie, mais je n’imagine pas une seule seconde qu’un professionnel de la cyber apprenne tant que ça au-delà d’un débutant, le livre reste sur des concepts plus de rentrer dans le dur de la technique.

Ce n’est pas un mauvais livre, au contraire ! Cependant, je pense que la vraie cible est plutôt les débutants ou les gens curieux comme moi qui ne travaillent pas dans la cybersécurité.

Coups et blessures

Un peu d’humour pour finir.

J’adore le côté humour absurde dans un dessin mignon de Sandrine Deloffre. J’ai donc participé il y a quelques mois à un crowdfunding pour un nouveau livre qu’elle était sur le point d’écrire.

Je ne vais pas mentir, je suis déçu… Oui, c’est bien l’humour de Sandrine Deloffre. Résolument absurde, parfois amusant, souvent potache, toujours mignon. Mais à aucun moment, je n’ai éclaté de rire, contrairement aux petits stickers rigolos que je lui ai achetés dans le passé.

J’ai quand même mon pins du club de la bagarre et un magnifique marque page (aussi absurde que cette phrase), donc ça valait tout de même le coup ?

Sandrine Deloffre - coups et blessures

T’en as pas oublié un ???

Lors de la Kubecon EU 2024, j’ai récupéré le livre “Kubernetes Patterns” (k8spatterns.com) que je n’ai toujours pas lu… 🙈

Et tant que je parle de Kubernetes, si vous ne le savez encore pas, j’ai terminé d’écrire un livre sur Kubernetes… Je vous invite à aller sur le site que j’ai créé à l’occasion :

50 nuances de Kubernetes - 50ndk.zwindler.fr

Il se pourrait qu’il y ait une grosse annonce dans les jours qui viennent. Et il y a une newsletter. Je dis ça, je dis rien ;-)

D’open source à BullShit Licence (BSL)

Wed, 16 Aug 2023 12:00:00 +0200

Résumé des épisodes précédents

Il y a à peine un mois, j’écrivais mon billet d’humeur annuel sur une boite, championne de l’open source (RHEL), qui utilise une faille de la licence GPL pour gratter un peu de thune en fermant ses sources aux “rebuilders” (je parle évidemment de l’article “Oracle à la rescousse de Linux ? Quelle blague!”).

Je ne pensais pas que je devrais REFAIRE un article d’humeur sur un sujet similaire, un mois plus tard.

Car jusqu’à présent, c’était plutôt des incidents “isolés” et dans des contextes assez spécifiques. En 2021, c’était Elastic qui passait à la licence SSPL pour “lutter” contre les offres managées par AWS (après Mongo qui avait fait pareil en 2018).

Si AWS était évidemment fautif dans cette histoire, ce move est catastrophique et a amorcé pas mal de backlash côté communauté (justifié, à mon avis) ainsi qu’une tempête de FUD de tous les côtés. Au final, c’est l’open source, qui devenait tout juste respectée en entreprise, qui en pâtie.

RHEL ouvre une brèche, l’open source se referme

Car à peine quelque jour après le move de RHEL pour faire la nique à Rocky+Alma, on pensait souffler mais non, les mauvaises nouvelles s’enchaînent.

Canonical, créateur de l’outil LXD (solution pour manager des containers LXC, que j’affectionne particulièrement) retire l’outil du Linux Containers project, un projet communautaire, qui le chapeautait.

While the team behind Linux Containers regrets that decision and will be missing LXD as one of its projects, it does respect Canonical’s decision and is now in the process of moving the project over.

linuxcontainers.org/lxd/

On peut aussi noter que ce move le lendemain de la démission d’un des développeurs de LXD chez Canonical :

stgraber.org/2023/07/10/time-to-move-on/

Et que le créateur de LXD l’a forké :

linuxiac.com/incus-project-lxd-fork/

In response to Canonical’s takeover of LXD, the independent Incus project arose as a fork for this container and virtual machine manager.

Moi je l’aime bien la MPL…

Et la semaine dernière (pendant mes vacances, ces cochons), Hashicorp a changé la licence de leurs produits de la MPL (Mozilla Public Licence, que je trouve être un bon compromis) à la BSL, une licence plus restrictive :

BSL is a new alternative to closed source or open core licensing models. Under BSL, the source code is always publicly available. Non-production use of the code is always free, and the licensor can also make an Additional Use Grant allowing limited production use.

Qu’est ce que la BSL ?

Grosso modo, c’est une licence qui n’est PAS open source (cf ce post de Sentry qui reconnait que BSL n’est pas open source dans le sens OSI du terme), et qui permet à Hashicorp dans le cas présent de tuer la concurrence dans l’oeuf.

You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp’s products

Dans le billet de blog pour parler du changement de licence, voilà comment c’est dit :

Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.

Si vous voulez creuser un peu plus les réactions, The Register a fait un article assez cool sur ce move, les réactions et les conséquences que ça va avoir.

www.theregister.com/2023/08/11/hashicorp_bsl_licence/

Et je vous partage aussi cet excellent thread sur Twitter et son tout aussi excellent follow up de iamvlaaaaaaad

Autant dire que de nombreuses personnes, dont des développeurs qui ont contribué à un projet open source et qui se retrouvent à avoir engraissé gratuitement Hashicorp, sont assez mécontents.

Pour essayer d’éteindre l’incendie, il y a évidemment une FAQ pour dire que rien ne va changer et que l’utilisateur n’a rien à craindre, mais comme à chaque fois dans ces histoires de licences, c’est la licence qu’il faut lire, pas la FAQ. Ce n’est pas la FAQ qui vous sauvera du tribunal…

C’était exactement la même salade avec MongoDB et Elastic. Beaucoup de craintes, du FUD, notamment de la part des opposants aux modèles open source (ahah vous voyez c’est pas clair l’open source !), et surtout un flou juridique immense que personne n’a encore réellement éclairci…

Le point positif, c’est que ça fait travailler les devrels et les avocats (cf le thread de vlad).

Hashi, c’est fini

Note: ce sous titre est gracieusement offert par (volé à) Clementd.

Autant dans le cas du bras de fer entre Mongo/Elastic avec AWS, j’arrivais à peu près à comprendre les motivations. En revanche, pour Hashicorp, on peine à trouver qui est visé par cette modification.

Qu’avait à gagner Hashicorp à changer son modèle de licence, à part une communauté à dos et un fork dans les start-in blocks ?

La seule cible qui me vient en tête n’est pas un gros méchant cloud provider, mais plutôt des offres alternatives à Terraform Cloud/Entreprise, comme Env0 ou Spacelift. Et aussi de petit éditeurs / cloud providers locaux qui se reposent sur ces outils pour fournir de l’automatisation à leurs clients…

On est bien loin des méchants GAFAM qui “piquent not’ travail” (ref south park, j’innove peu), ici il s’agit d’offres qui se sont construites “au-dessus” de Terraform, car elles ont apporté des choses en plus qu’on ne trouvait pas dans les offres d’Hashicorp. Ces offres se retrouvent tuées dans l’oeuf maintenant qu’elles sont concurrentes à certains produits d’Hashicorp. Pratique…

Plus cynique encore, on pourrait imaginer un scénario où une boite se créerait au dessus de terraform ou tout autre produit d’Hashicorp en étant totalement PAS concurrente de leurs offres, qui se mettrait à bien marcher. Hashicorp n’aurait qu’à artificiellement créer un produit concurrent (même tout pourri) et hop, on rafle le marché.

On est plus proche du EEE que de la philosophie open source.

Sauf que maintenant, c’est plus Microsoft : c’est RHEL, Canonical, Hashicorp…

Conclusion (rédigée par ChatGPT, pour le lulz)

Dans ce spectacle de l’open source, les spectateurs ne savent plus s’ils doivent rire ou pleurer

Les entreprises qui semblaient autrefois être les champions du partage et de la collaboration semblent désormais être en compétition pour le titre de “Licence la plus énigmatique”.

Et tandis que le rideau se lève sur ces actes étonnants, les développeurs, les utilisateurs et la communauté open source dans son ensemble se demandent peut-être si tout cela est un rêve étrange, ou simplement une réalité nouvelle et ironique.

Bonus

Avec Terragrunt, ne répétez plus vos variables Terraform 358 fois

Mon, 29 Aug 2022 06:45:00 +0200

Cet article a initialement été écrit avec ma collègue Chahrazed Yousfi (zed) en anglais. C’est donc une traduction pour mes copains francophiles ;-).

Mais pourquoi tu fais çaaaaaa ???

L’article qui suit parle d’un cas d’usage avancé de Terraform qui n’est probablement pas nécessaire d’aborder pour un débutant. Si jamais vous voulez un aperçu de ce qu’on peut faire avec Terraform, vous pouvez aller relire mon article Premiers pas avec Terraform.

Au travail, la majorité de notre infrastructure est hébergée sur site (hors d’un cloud) et dans la plupart des cas ça nous convient.

Mais maintenir un service en ligne avec des infras en propre c’est parfois compliqué et il arrive que les services proposés par les cloud providers soient plus adaptés à nos besoins que ce que nous, l’équipe SRE, pouvons apporter à nos utilisateurs (les développeurs).

Pour gérer de manière “DevOps” ces services “cloud”, nous utilisons un outil d’Infrastructure as Code (IaC) : Terraform de Hashicorp.

Terraform is an open-source infrastructure as code software tool that provides a consistent CLI workflow to manage hundreds of cloud services. Terraform codifies cloud APIs into declarative configuration files. – Terraform website

Ce que nous aimons vraiment avec Terraform c’est que cet outil nous permet de construire une infrastructure “répétable” avec seulement quelques lignes de HCL (le domain-specific-langage de Hashicorp). L’état de l’infrastructure est stocké soit en local (dans un fichier) soit sur un système de stockage externe. Seule la différence entre ce qu’on écrit dans le code et ce qui est stocké dans ce state est appliquée/modifiée. Dernier point, l’outil est devenu un standard de-facto, ce qui est beaucoup à obtenir des services fiables et facilite l’onboarding des équipes de dev.

Pour donner une idée de notre usage de Terraform, le répository sur lequel nous stockons notre IaC représente :

Pratiquement 1000 fichiers “.tf” de Terraform, pour environ 35k lignes
Environ 4000 commits, 1500 pull-requests
Plus de 40 contributeurs venant de diverses équipes

Les limites de Terraform ?

Tant que vous avez peu d’objets dans Terraform, tout va bien.

Mais quand vous commencez à avoir des centaines de fichiers (comme nous), cela devient compliqué de travailler simultanément sur le même code Terraform. Le fichier qui stocke l’état de l’infrastructure doit être à jour et synchronisé entre tous les contributeurs.

Cela provoque des problématiques de “locking”, le calcul des “diffs” est de plus en plus long. En scalant, l’expérience utilisateur de Terraform se dégrade dans le temps.

Il y a plusieurs stratégies pour contourner cela, mais nous n’avons pas trouvé de solution qui éclipsait tous nos problèmes.

Par exemple, il est possible de découper le code Terraform dans différents dépôts git et avoir un état Terraform pour chacun d’entre eux. De cette manière, chaque équipe devient autonome est peut travailler de manière indépendante sur leur infrastructure. Cependant, le code Terraform tend à être dupliqué de projet en projet, puis d’équipe en équipe (même en utilisant les modules Terraform, on en parlera plus tard).

D’expérience, du code dupliqué conduit à des erreurs humaines et nous essayons donc d’éviter ça le plus possible.

Une autre solution pourrait être de créer un gros “monorepo” dans lequel on dépose tous les projets Terraform dans des répertoires différents (chacun avec son “state”). On peut utiliser des modules Terraform pour factoriser le code HCL commun de ses dossiers, soit directement dans le même monorepo, soit dans des dépôts distants.

Mais même comme ça, on se retrouve toujours à dupliquer toujours les mêmes variables (comme le “billing account” de votre cloud provider, par exemple, ou toute autre valeur que vous utilisez tout le temps).

Arrive alors Terragrunt !

Pour contourner certaines des limitations de Terraform, la société Gruntwork a créé un outil appelé Terragrunt, qui pour le dire simplement, est un wrapper de Terraform.

Note : vous connaissez peut-être déjà Gruntwork pour certains autres outils “cloud native”, notamment “Terratest” (qui permet de tester son code Terraform), “AWS Infrastructure as Code Library”, “Gruntwork Landing Zone for AWS”, etc.

L’idée principale mise en avant par Terragrunt est que le code Terraform devrait pouvoir être écrit de manière à ne jamais avoir à répéter quoique ce soit (philosophie DRY pour Don’t Repeat Yourself).

Dans ce post, je vous montrerai donc une façon (opinionated) d’utiliser les fonctions principales de Terragrunt, pour vous montrer qu’on peut éviter de se répéter 358 fois ;-).

On se prépare

La première chose à faire pour commencer à travailler avec Terragrunt est bien sûr de l’installer ;-). Le code source de Terragrunt est disponible ici et les binaires précompilés sont disponibles là.

Pour avoir une bonne idée des fonctionnalités offerts par Terragrunt, je vous propose d’utiliser un environnement cloud de démo avec la hiérarchie suivante :

Note : Pour cet exemple on a choisi Google Cloud Platform comme cloud provider, mais Terragrunt peut évidemment être utile dans bien d’autres contextes. L’avantage de GCP dans ce cas là, c’est qu’il existe des folders et des projects, qui nous permettent de gérer les droits par département, équipe, etc.

Dans cette démo, on va utiliser un dépôt git, qui contient initialement du code Terraform classique, et on va ensuite le dé-dupliquer étape par étape avec l’aide de Terragrunt.

github.com/deezer/terragrunt-example/

Pour des raisons de lisibilité, on va décrire les actions étapes par étapes mais pas afficher le code entier à chaque fois. Vous pouvez naviguer entre les commits pour voir le résultat.

Factoriser les variables

Avoir beaucoup de projets différents implique qu’on va avoir beaucoup de variables à déclarer. Et beaucoup de ces variables vont souvent être identiques ou similaires d’un projet à l’autre. Le souci, c’est que copier le code d’un projet devient alors source importante d’erreurs humaines. Si on oublie de changer une variable au milieu de celles qui doivent être copiées, le résultat peut être fâcheux.

C’est d’abord pour cette raison que nous avons cherché une solution pour factoriser nos variables Terraform (nous ne pouvions pas être les seuls à avoir ce problème).

Nous cherchions également une solution qui serait compatible avec un système d’héritage et nous avons trouvé Terragrunt !

La capture d’écran qui suit est un aperçu de ce qu’on a pu faire avec Terragrunt pour les variables d’un “projet” GCP. Nous disposons maintenant d’un moyen pour factoriser la quasi-totalité de nos variables à différents niveaux hiérarchiques, et je vais vous montrer comment ! 😉

Un fichier de configuration

La première chose qu’on va faire est de créer un fichier terragrunt.hcl qui va contenir les informations utilisées par Terragrunt pour fonctionner.

Ce fichier est écrit dans la même syntaxe que Terraform (c’est du HCL), avec en plus des fonctions supplémentaires. Pour plus de détails, vous pouvez aller voir la page officielle de documentation.

Pour notre démo, j’ai besoin de créer le fichier terragrunt.hcl à 2 niveaux dans mon repository :

un premier au niveau de mon projet (là où sont mes fichiers .tf), pour indiquer à Terragrunt qu’il peut s’éxecuter ici. Pour faire simple j’appelerai ça le “fichier de configuration local”
un second au niveau de la racine de mon dépôt git, où on mettra toute la configuration qui sera commune à tous les répertoires. Je l’appellerai “fichier de configuration global”

Le dépôt va avoir la structure suivante :

Au niveau du projet (dans le fichier de conf “local”), on va ajouter un bloc include, suivi par la fonction find_in_parent_folders(). Cette fonction recherche dans les répertoires parents jusqu’à trouver un autre fichier terragrunt.hcl. La fonction renvoie ensuite le chemin pour retrouver le fichier terragrunt.hcl “global” (situé à la racine), qui contient toute la configuration commune à tous les fichiers terragrunt.hcl.

Ce bloc nous permet donc de récupérer la configuration déclarée à la racine. Les projets ne contiennent donc pas de configuration spécifique, puisque vous est basé sur la configuration “globale”.

include "root" {
 path = find_in_parent_folders("terragrunt.hcl")
}

Variables globales

Admettons maintenant qu’on veut qu’un certain nombre de variables soient identiques pour tous les projets, comme pour le “billingID” par exemple. Pour le faire, on va ajouter des inputs dans le fichier de configuration globale :

inputs = {
 billing_account = "012345-ABCDEF-UVWXYZ"
 organization_id = "12345678"
 region = "europe-west1"
 zone = "europe-west1-b"
}

Les inputs permettent de remplacer des variables déclarées (mais vides) dans les projets. Souvent, on déclare ces variables dans un fichier variables.tf, au niveau du projet lui-même.

Une fois que vous déclarez la variable et son type, elle sera automatiquement remplacée par la valeur déclarée globalement (plus haut), par Terragrunt.

variable "billing_account" {
 type = string
}

De cette manière, on peut donc déclarer une seule fois les variables qui sont valables pour TOUS les projets.

Mais comment faire si jamais on a envie de mutualiser des valeurs qu’avec une partie de nos projets et pas tous ?

Variables intermédiaires

Contrairement aux fonctions, qui ne sont utilisables que dans le fichier de configuration terragrunt.hcl, il est possible de configurer des inputs dans d’autres fichiers “.hcl”. On peut donc les mettre où on veut dans notre dépôt, idéalement à un endroit intelligent dans notre hiérarchie de dossiers, histoire que tous les projets similaires héritent des mêmes variables.

Pour le faire, on va utiliser la fonction read_terragrunt_config dans la configuration globale pour tous les fichiers “.hcl” qu’on va vouloir inclure, puis fusionner tout ça ensemble.

Pour donner un exemple, si pour dossier et sous-dossiers donné on a un même tag “team leader” ou “point de contact”, on va positionner un fichier team.hcl dans le dossier qui les englobe tous.

inputs = merge(
 read_terragrunt_config(find_in_parent_folders("global.hcl")).inputs,
 read_terragrunt_config(find_in_parent_folders("team.hcl")).inputs,
)

Dans le cas de la team-a, ce fichier pourrait être placé ici : dept-datascience/team-a/team.hcl, avec les valeurs suivantes :

inputs = {
 tech_lead = "Freddie Mercury"
 contact = "fmercury@gmail.com"
}

Pour la team-b, dept-datascience/team-b/team.hcl et les valeurs :

inputs = {
 tech_lead = "Abel Tesfaye"
 contact = "atesfaye@gmail.com"
}

Notre arborescence d’exemple devrait ressembler à ça maintenant :

Variables non factorisables

On ne peut pas toujours factoriser toutes les variables pour tous les projets. Il arrive qu’il soit nécessaire de faire des exceptions, par exemple, un projet va être déployé dans une région inhabituelle.

Si jamais vous avez besoin d’écraser la valeur par défaut, déclarée dans un niveau supérieur, c’est possible. Il suffit de déclarer un inputs dans la configuration locale de Terragrunt en utilisant le même nom.

Allez plus haut

En tant que SREs, on cherche toujours à automatiser toujours plus de tâches manuelles.

Grâce aux fonctions de Terragrunt, nous avons trouvé comment automatiser la configuration de la variable “name” de nos projets GCP. Nous avons décidé que tous les projets (name + ID) devraient être définis directement par le nom du répertoire dans lequel le code Terraform/Terragrunt est stocké.

On peut le faire de la façon suivante dans le fichier de configuration global

inputs = {
 project_name = "basename(get_terragrunt_dir())"
}

De cette manière, nous n’avons plus à ne pas oublier de changer le project_name ou projet_id dans nos ressources Terraform ou notre variables.tf quand on copie du code. On se base simplement sur la variable project_name, qui est déduite automatiquement du dossier concerné.

Configuration du backend Terraform

Au travail, pour stocker nos états Terraform (les fameux fichiers de state), nous utilisons un bucket GCS. Tous les états des projets sont stockés dans des chemins différents et parfois dans des buckets GCS différents. Mais ce chemin doit toujours contenir le nom du projet et le nom du bucket concerné.

terraform {
 backend "gcs"{
 bucket = "tfstate-team-a"
 prefix = "team-a-proj-product1"
 }
}

Avec Terraform, il est impossible de variabiliser cette partie backend.

a backend block cannot refer to named values (like input variables, locals, or data source attributes).

Heureusement, Terragrunt propose lui la possibilité de le faire, dans un bloc remote_state à ajouter dans le fichier de configuration global.

Dans notre exemple, nous avons décidé de créer des buckets qui seraient mutualisés pour quelques projets chacun.

On les définit donc dans un fichier backend.hcl placé au plus haut des sous dossiers que le bucket va gérer. On réutilise la même technique que précédemment (inputs + find_in_parent_folders() + read_terragrunt_config())

Par exemple, tous les projets de la team-a utilisent le même “tfstate-teamA”, on va donc créer le backend.hcl à la racine du dossier team-a.

Pour ce qui est du préfixe (le chemin du state dans le bucket), on utilise ensuite une fonction path_relative_to_include() qui renvoie le chemin relatif depuis la racine du dépôt.

Dans l’exemple, le path pour team-a-proj-product1 ça serait dept-datascience/team-a/product1/team-a-proj-product1. Ca nous permet de nous assurer que le state est toujours stocké dans un endroit unique.

remote_state {
 backend = "gcs"
 config = {
 bucket = read_terragrunt_config(find_in_parent_folders("backend.hcl")).inputs.bucket
 prefix = path_relative_to_include()
 }
}

Note : dans cet exemple particulier, on voit bien que la façon dont on nomme nos dossiers ainsi que la hiérarchie des dossiers est très importante pour faciliter la façon dont on décrit notre configuration. Pour autant, ce n’est qu’un exemple et on peut tout à fait gérer cela différemment tout en profitant des fonctions de Terragrunt.

Dans notre projet, on devra remplacer la configuration du backend par l’extrait suivant. La configuration du backend sera automatiquement remplie par terragrunt à partir de la configuration globale.

terraform {
 backend "gcs" {}
}

Une commande pour les contrôler toutes…

Une commande que nous n’attendions pas et que nous avons découverte avec Terragrunt est l’ajout d’un run-all.

run-all est une commande de la CLI Terragrunt qui permet de lancer de manière terragrunt dans tous les sous-dossiers contenant un terragrunt.hcl.

Si vous avez changé une des globales variables, vous pouvez appliquer le changement à tous vos projets d’un seul coup avec la commande suivante :

$ terragrunt run-all apply

On peut également utiliser cette fonction dans une CI/CD pour s’assurer que l’infrastructure est toujours à jour et qu’il n’y a pas eu de “drift”.

Conclusion

J’espère vous avoir convaincu que Terragrunt peut réellement être utile lorsque vous travaillez avec un grand nombre de fichiers Terraform.

Cela nécessite un peu de rigueur et de réflexion pour créer une hiérarchie de dossiers, de manière à mutualiser de manière intelligente les variables dans l’arborescence.

Même si Terragrunt ajoute un peu de complexité, il permet également d’obtenir de nouvelles fonctions et facilite l’automatisation et la factorisation du code.

Tout ceci permet ensuite d’avoir du code plus propre, plus maintenable, moins dupliqué.

Je ne conseille pas de commencer directement avec Terragrunt si vous débutez dans Terraform (ça ajoute quand même un peu de complexité pour peu de gain). Cependant, si vous commencez à avoir beaucoup de fichier, de contributeurs, vous devriez clairement le tester.

D’autres ressources externes sur le sujet

Import manuel de records DNS route53 avec Terraform

Mon, 20 Sep 2021 06:10:00 +0000

Terraform et l’Infrastructure as Code

Ce n’est pas la première fois que je parle de terraform, l’outil d’Infrastructure as Code particulièrement efficace dans les environnements cloud (mais pas que) de Hashicorp.

J’avais fait un petit « tour d’horizon » de l’outil quand il était encore en v0.10 (Hashicorp a passé terraform en v1.0 en juin), si vous avez besoin d’un petit rafraîchissement de mémoire ou que vous découvrez l’outil.

Pour la faire courte, l’intérêt de terraform (et de l’infrastructure as code) par rapport à l’automatisation plus classique est de passer dans un mode « déclaratif » où vous déclarez dans des manifests l’état souhaité de votre infrastructure plutôt que de dérouler un script qui fait les opérations unes à unes.

Vos manifests deviennent la « source de vérité », auditable, versionnable, absolue (pas de diff possible entre ce que vous pensez avoir déployé et le bidule modifié à la main hier que vous avez oublié).

Réconcilier l’existant avec l’infrastructure as code

Tout ça c’est super si jamais vous venez de commencer à travailler dans le cloud et que vous partez de 0.

Si vous avez déjà de l’existant, c’est plus compliqué puisque vous vous retrouvez avec une partie décrite dans votre dépôt Git et une autre partie « historique ».

Et même si on peut se dire que cette partie « historique » va finir par disparaitre au profit des nouveaux projets gérés par IaC, il existe une zone floue où on ne sait plus très bien si c’est géré à la main ou en IaC.

Du coup, autant en profiter quand on a le temps pour réintégrer le legacy dans l’IaC.

Route53, le DNS by AWS

Je suis donc arrivé dans un contexte technique où le DNS externe est géré par AWS depuis bien longtemps, et qu’on intègre progressivement les nouveaux records dans terraform. Cependant, j’avais besoin de modifier un record déjà existant (de type TXT) et je n’avais pas envie de le faire à la main.

Sachez donc qu’il existe pour une grande partie (tous ?) des providers terraform une commande terraform import qui permet comme son nom l’indique d’importer l’existant dans terraform.

Le souci est que cette import n’est réalisée que dans le « state » de terraform, pas la configuration elle même.

The current implementation of Terraform import can only import resources into the state. It does not generate configuration. A future version of Terraform will also generate configuration.

Vous allez donc devoir écrire le pavé HCL à la main.

D’un certain côté, c’est presque plus rassurant quand on y réfléchit, car ça permet de bien se poser la question de comment on souhaite découper nos projets, comment on veut construire l’IaC (avec des variables, avec des boucles, etc).

Récupérer les IDs uniques

L’idée ici va être de récupérer le record en donnant à terraform toutes les infos nécessaire pour qu’il retrouve celui qui nous intéresse. A la suite de terraform import, on doit lui donner les informations suivantes :

terraform import {resource_type}.{resource_name} {zone_id}_{record_name}_{record_type}

Dans mon cas, le resource_type était aws_route53_record, le resource_name mytxtrecord (le nom que je veux lui donner dans ma conf et mon state terraform). La zone ID dépend de votre compte AWS/route53, le record_name, c’est le nom du record (comme sur la console) et le record_type dans mon cas, un TXT mais ça aurait très bien pu être un A, un AAAA, un CNAME, etc.

terraform import aws_route53_record.mytxtrecord ABCDE1234567890_awesomeexample.org_TXT
aws_route53_record.mytxtrecord: Importing from ID "ABCDE1234567890_awesomeexample.org_TXT"...
aws_route53_record.mytxtrecord: Import prepared!
Prepared aws_route53_record for import

A l’issue de la commande, si tout s’est bien passé, vous devriez avoir un message qui indique le succès de l’opération et l’ajout du record dans le state de votre terraform. Il ne reste plus qu’à rédiger le pavé HCL pour votre IaC qui a cette tête là dans mon exemple :

resource "aws_route53_record" "mytxtrecord" {
zone_id = data.aws_route53_zone.awesomedomain.zone_id
name = "awesomeexample.org"
type = "TXT"
ttl = "60"
records = ["existingsuperimportantdata"]
}

On peut commiter ça, puis faire nos modifications comme d’habitude et en toute sécurité :-)

terraform plan
[...]
Terraform will perform the following actions:
# aws_route53_record.mytxtrecord will be updated in-place
~ resource "aws_route53_record" "mytxtrecord" {
fqdn = "awesomeexample.org"
id = "ABCDE1234567890_awesomeexample.org_TXT"
name = "awesomeexample.org"
~ records = [
+ "newtxtstring=veryimportantdata",
"existingsuperimportantdata",
]
~ ttl = 300 -> 60
type = "TXT"
zone_id = "ABCDE1234567890"
}
Plan: 0 to add, 1 to change, 0 to destroy.

Informations/sources additionnelles

Premiers pas avec Terraform

Tue, 16 Jan 2018 12:45:42 +0000

Terraform ?

Si vous avec passé un peu de temps sur Twitter, LinkedIn ou dans n’importe quel conf un peu orientée DevOps, vous ne pouvez pas avoir loupé Terraform.

Terraform est un outil d’Infrastructure as Code développé par Hashicorp. Que le nom de cette entreprise vous dise quelque chose ou pas, vous avez très probablement entendu parlé de Vagrant (eh oui c’est eux) et de Consul (peut être même de Packer, Vault ou Nomad). Bref, l’entreprise propose un certain nombre d’outils pour faciliter l’exploitation et l’automatisation de ressources, particulièrement dans le cloud.

Ok, mais Terraform c’est quoi ?

Des fois le plus simple est de laisser les développeurs en parler d’eux même ;-)

What is Terraform?
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Il y a deux phrases, et les deux sont importantes. En Français :

Terraform est un outil pour construire, changer, versionner l’infrastructure de manière sécurisée et efficace (efficiente?).
Terraform peut gérer des fournisseurs de services (comprenez cloud plublic) mais aussi des solutions maison sur site (comprenez cloud privé).

Pourquoi c’est important ?

Comme je le disais un peu plus haut, même s’ils disent le contraire, Terraform est quand même (historiquement) plutôt à destination des cloud providers.

C’est là où Terraform a apporté la plus-value qui a fait sa renommée. Il permet une gestion plus agnostique des ressources et permet de passer facilement d’un cloud à l’autre.

Et mon cluster VMware/Openstack on-premise alors ?

Heureusement, l’outil s’enrichit de jour en jour et on dispose aujourd’hui de beaucoup de providers au delà des AWS, Azure et GCP et s’ouvre à d’autres usages comme MySQL, Kubernetes, Grafana, … La liste complète est disponible sur le site de Hashicorp.

Le tutoriel « officiel » est disponible à l’adresse suivante, mais on reste un peu sur sa faim. Et surtout on ne voit pas comment faire du on-premise (ou que vous êtes allergiques à AWS).

Quelques concepts

Je ne peux pas faire un article sans vous donner un minimum de concepts pour appréhender Terraform. La première chose à savoir est que Terraform utilise un langage de configuration appelé HCL qui lui est propre HashiCorp Configuration Language. C’est avec ce langage de configuration qu’on va décrire l’infrastructure à construire et l’état dans lequel on souhaite avoir cette infrastructure. Moi qui suis habitué au YAML, dommage…

On va donc devoir décrire un provider, qui sera notre point d’entrée pour créer/interagir avec l’infrastructure (un login/mdp pour AWS, un serveur vCenter et les logins/mdp privilégiés, etc). Il est très probable qu’on ait plusieurs providers.

Ensuite on pourra commencer à décrire nos ressources (tout objet nécessaire pour notre application, que ce soit une VM, un container, un réseau virtuel, une URL dans un loadbalancer, etc).

Assez de théorie, la pratique !

Pour voir autre chose et mettre un peu plus les mains dans le cambouis, je vous propose donc un petit exemple avec un cluster VMware que vous auriez sous la main.

La première chose à faire est sans surprise de récupérer terraform (ici)

Installer et configurer Terraform

Si vous travaillez sur un Linux, un petit curl et on en parle plus.

curl https://releases.hashicorp.com/terraform/0.10.6/terraform_0.10.6_linux_amd64.zip -o terraform_0.10.6_linux_amd64.zip
unzip terraform_0.10.6_linux_amd64.zip
mv terraform /usr/local/bin

Sous Windows, le plus simple est de télécharger le binaire, de le déposer dans un dossier de votre disque et d’alimenter le PATH (modifier les variables d’environnement du systèmes)

On peut maintenant tester que la commande répond correctement :

Mon premier script Terraform

Dans cet exemple, je me base sur le provider vSphere, dont vous retrouvez la documentation ici. Ce simple script va se connecter à mon vcenter, créer un répertoire test à la racine du cluster, puis créer une VM dans ce répertoire.

cat example_vsphere.tf
# Configure the VMware vSphere Provider
provider "vsphere" {
user = "root"
password = "xxxx"
vsphere_server = "vcenter.zwindler.fr"
# if you have a self-signed cert
allow_unverified_ssl = true
}
# Create a folder
resource "vsphere_folder" "test" {
path = "test"
datacenter = "VMware zwindler"
}
# Create a virtual machine within the folder
resource "vsphere_virtual_machine" "test" {
name = "terraform-test"
datacenter = "VMware zwindler"
cluster = "Cluster_VMware"
folder = "${vsphere_folder.test.path}"
vcpu = 2
memory = 4096
network_interface {
label = "Virtual Network"
ipv4_address = "192.168.1.100"
ipv4_prefix_length = "24"
ipv4_gateway = "192.168.1.1"
}
disk {
template = "tmpl-rhel-7-3"
datastore = "VMFS01"
}
}

On récapitule. Le premier objet de base dans terraform est le « provider », qui nous permet de prendre le contrôle du cluster. Les deux autres objets sont les « ressources » qu’on souhaite créer/modifier.

It’s alive!

La première commande à lancer est terraform init, dans le dossier qui contient notre fichier de définition de l’infrastructure. Cela permet d’initialiser le contexte recherché ainsi que des variables. terraform plan permet ensuite de faire un essai à blanc des modifications pour s’assurer que tout fonctionnera bien comme attendu (dry run).

terraform init
terraform plan

Et pour finir, on exécute notre plan avec terraform apply (création du dossier et génération de la machine virtuelle) :

terraform apply

A l’issue de ces commandes, une VM devrait être créée dans votre cluster comme spécifiée. Vous remarquerez également la présence dans le même dossier que votre fichier example_vsphere.tf un fichier terraform.state. Ce fichier terraform.tfstate (qui enregistre l’état dans lequel est l’infrastructure) est important et doit être disponible pour tous les postes/utilisateurs qui utilisent terraform pour cette infrastructure (sinon ça ne marche pas).

Hashicorp conseille d’utiliser un moyen de rendre ce fichier disponible à distance, par exemple avec un serveur Consul (de Hashicorp, bien sûr). On peut utiliser etcd ou artifactory ou même un simple partage mais il y aura des risques d’accès concurrents (il n’y aura pas de locking au niveau Terraform).

With remote state, Terraform stores the state in a remote store. Terraform supports storing state in Terraform Enterprise, Consul, S3, and more.
Remote state is a feature of backends. Configuring and using backends is easy and you can get started with remote state quickly. If you want to migrate back to using local state, backends make that easy as well.

Si vous voulez en savoir plus, allez lire cette page.

Conclusion

J’ai essayé de faire bref pour vous donner un aperçu très rapide de ce qu’est Terraform et de ce qu’on peut faire avec mais il reste forcément encore beaucoup de choses à dire. Déjà, j’ai résumé à l’extrême la partie théorie et n’ai pratiquement expliqué aucun concept. Ensuite, je n’ai pas beaucoup exploré les limites de Terraform, notamment dans l’utilisation à plusieurs et les manques par rapport à d’autres outils.

Pour ma part j’ai trouvé l’outil intéressant mais je ne peux pas m’empêcher de faire le parallèle avec Ansible, que je maitrise beaucoup mieux.

Que peut faire Terraform que ne peux pas faire Ansible ? Peut être une meilleure gestion de fournisseurs de services autres que AWS Azure et GCP (Dyn, Datadog ou Mailgun).

A l’inverse, Ansible permet de faire beaucoup plus de choses que Terraform, car c’est un outil bien plus fourni (à date) et surtout plus généraliste, qui sert à la fois à déployer ET à configurer.

Pour autant, je ne m’interdis pas de l’utiliser dans un prochain contexte professionnel qui devrait justement me demander plus d’interaction avec les clouds public.

Have fun !

[Bonus]Life in graphic, it’s fantastic

Une fonctionnalité sympathique de Terraform est la possibilité offerte de générer un « graphe » de vos ressources et de leurs dépendances les unes aux autres. Certes, dans des cas concrets et complexes c’est peut être un peu gadget, mais l’idée est bonne.

En réalité, c’est même pour cette raison que je me suis intéressé à Terraform. A la base, on m’a demandé de trouver un outil permettant de visualiser une infrastructure complexe. Or celle ci étant changeante car en pleine conception, je n’avais pas envie de repasser 50 fois sur un diagramme de type Visio. J’ai donc cherché une solution pour le faire de manière automatique.

Voilà le genre de résultats que vous pouvez attendre de Terraform :

Notre example_vsphere.tf donne ceci en graphe

Pour se faire, installez simplement la bibliothèque graphviz et utilisez la commande terraform graph.

yum install graphviz
terraform graph | dot -Tpng > terraform-graph.png

A noter : je n’ai pas trouvé la solution satisfaisante et c’est pour ça que j’ai commencé à développer ma propre bibliothèque Python pour grapher des infrastructures. Quand ça ressemblera à quelque chose je ferai un article dessus (#Teasing).