13 articles tagués avec « Infrastructure as Code »

Un dépôt d'infrastructure décrit tout ce qu'il faut pour reconstruire un service, sauf les secrets (mots de passe, jetons d'API, clés privées), qui restent dans un .env ignoré par Git, copié à la main d'une machine à l'autre, rarement sauvegardé. Les versionner en clair n'est pas envisageable ; les laisser hors du dépôt casse la promesse « le dépôt suffit à tout reconstruire ». git-crypt comble cet écart : certains fichiers sont chiffrés au moment du commit et déchiffrés au checkout, de façon transparente pour qui possède la clé.

Déployer une application web (un frontend, un backend, une base de données) enchaîne toujours les mêmes étapes : construire les images, les publier, provisionner l'infrastructure, déployer sur le cluster. Automatiser cet enchaînement du git push à l'application en ligne est l'objet d'un pipeline CI/CD. Cet article décrit une telle chaîne, bâtie avec GitHub Actions, Terraform et Helm sur AWS EKS.

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 naïve 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 : chaque ajout ou retrait d'AZ impose de copier ou de supprimer un bloc à la main.

Terraform calcule automatiquement l'ordre de création des ressources en analysant les références entre elles (voir le graphe de dépendances dans l'article Terraform). La plupart du temps, ce graphe de dépendances implicites suffit. Il existe cependant 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.

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.

Un dépôt Ansible décrit l'intégralité d'une infrastructure, y compris les mots de passe de bases de données, les clés d'API et les certificats nécessaires aux services. Ansible Vault chiffre ces données sensibles pour qu'elles puissent être versionnées avec le reste du code, puis les déchiffre en mémoire au moment de l'exécution des playbooks.