Une infrastructure ne reste jamais réduite à un seul environnement. Dev, staging et prod partagent la même architecture (réseau, base de données, application) mais diffèrent sur des paramètres précis : taille des instances, plage CIDR, nombre de réplicas, niveau de logging. Terraform propose deux approches pour gérer cette variation sans dupliquer intégralement la configuration : les workspaces natifs et la structuration par répertoires.
Une configuration Terraform naive duplique les blocs dès qu'il faut plusieurs instances d'une même ressource. Trois subnets dans trois availability zones se traduisent par trois blocs resource quasi-identiques, dont la seule différence est le numéro d'AZ et la plage CIDR. Ajouter une quatrième AZ exige de copier un quatrième bloc. Retirer une AZ laisse un bloc orphelin à supprimer manuellement. Ce mode de fonctionnement produit de la configuration qui ne se maintient pas.
Terraform fournit deux métas-arguments pour éviter cette duplication (count et for_each) et le bloc locals pour nommer et réutiliser des valeurs calculées. Ces trois outils répondent à des problèmes distincts et se composent.
Terraform calcule automatiquement l'ordre de création des ressources en analysant les références entre elles. La plupart du temps, ce graphe de dépendances implicites suffit. Mais il existe des situations où les dépendances ne se lisent pas dans le code HCL, ou où le comportement par défaut lors d'une modification ou d'une destruction est dangereux. Deux mécanismes permettent de prendre le contrôle dans ces cas : depends_on et le bloc lifecycle.
Une configuration Terraform qui grandit accumule des ressources dans main.tf jusqu'à ce que le fichier devienne difficile à lire et à modifier. Réseau, base de données, stockage, IAM coexistent dans le même fichier sans séparation claire. Les modules permettent de découper cette configuration en blocs autonomes, réutilisables entre environnements et projets.
Le fichier terraform.tfstate est la mémoire de Terraform. Il contient l'état réel de l'infrastructure telle que Terraform la connaît : identifiants, ARN, attributs de chaque ressource créée. Sans lui, Terraform ne sait plus ce qu'il a créé et tenterait de tout recréer depuis zéro. Stocker ce fichier localement fonctionne pour un développeur seul, mais pose des problèmes structurels dès qu'une équipe ou un pipeline CI/CD entre en jeu.
EKS est Kubernetes hébergé sur AWS. Le plan de contrôle (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) est géré par AWS dans un compte isolé, non accessible. Ce qui reste à la charge de l'utilisateur : les nœuds workers, le réseau, le stockage, et les intégrations IAM.
EKS Auto Mode, disponible depuis fin 2024, étend ce périmètre géré. En plus du control plane, AWS prend en charge le provisionnement des nœuds (via Karpenter intégré), le driver de stockage EBS, et le contrôleur de load balancing. Pour quelqu'un qui vient de kubeadm on-premise, c'est l'équivalent d'avoir Karpenter, le EBS CSI Driver et le AWS Load Balancer Controller préconfigurés et maintenus par AWS.
Terraform ne gère pas toujours l'intégralité d'une infrastructure. En pratique, une configuration s'appuie sur des ressources qui existent en dehors de son périmètre : une région cloud avec ses availability zones, un compte AWS avec son identifiant, des AMIs publiées par des tiers. Les data sources permettent d'interroger ces valeurs sans en prendre la gestion.
Terraform est un outil d'Infrastructure as Code qui permet de décrire des ressources cloud sous forme de fichiers de configuration texte, puis de les créer, modifier et supprimer via une séquence de commandes. La configuration décrit un état désiré — quelles ressources doivent exister, avec quels attributs — et Terraform calcule les opérations nécessaires pour atteindre cet état depuis la situation actuelle.
Une API REST expose des ressources que des clients peuvent créer, lire, modifier et supprimer. La structuration de ces opérations — les codes HTTP à retourner, la forme des corps de requête et de réponse, la gestion des erreurs — détermine la qualité et la prévisibilité de l'interface. FastAPI fournit les outils pour formaliser cette structure, et son système de dépendances permet d'y adjoindre une couche d'authentification de manière composable.
Cet article suppose une connaissance de base de FastAPI. Pour une introduction au framework, voir l'article précédent sur FastAPI.
Écrire du SQL dans une application Python pose un problème récurrent : le code SQL est du texte, alors que les données manipulées sont des objets. À chaque lecture, il faut convertir une ligne de résultat en dictionnaire ou en objet. À chaque écriture, il faut construire une chaîne SQL en s'assurant de ne pas introduire d'injection. SQLAlchemy résout ce problème en faisant correspondre des classes Python à des tables de base de données, et des instances de ces classes à des lignes.