Fiche : Platform engineering et Infrastructure as Code (IaC)
1. Définitions
- Platform engineering : construire une plateforme interne en libre-service (IDP) pour les développeurs, traitée comme un produit.
- IaC : décrire l'infrastructure (serveurs, réseaux, bases, droits) dans des fichiers versionnés, plutôt que de la configurer à la main.
- Lien : l'IaC est la fondation technique de la plateforme. Les templates du portail développeur déclenchent du code IaC en arrière-plan.
2. Concepts clés
| Concept | Explication |
|---|---|
| Déclaratif | On décrit l'état final voulu, l'outil calcule les actions (Terraform, Crossplane). |
| Impératif | On décrit les étapes à exécuter (scripts shell, Pulumi/CDK dans une certaine mesure). |
| Idempotence | Rejouer le code donne le même résultat, sans doublons ni effets de bord. |
| State (état) | Fichier qui mémorise ce que l'outil a créé (Terraform). À stocker à distance et verrouiller. |
| Drift | Écart entre le code et la réalité (modification manuelle dans la console). |
| Immutable / mutable | Immutable : on remplace le serveur (image Packer). Mutable : on le modifie en place (Ansible). |
| GitOps | Git est la source de vérité, un opérateur synchronise automatiquement le cluster. |
3. Les outils de base
Terraform / OpenTofu : provisionner l'infrastructure
- Rôle : créer des ressources cloud ou on-premise (VM, réseaux, bases, DNS, IAM) via des providers.
- Langage : HCL, déclaratif.
- Point fort : le plan (
plan) montre les changements avant application. Très large écosystème de providers. - Note : OpenTofu est le fork open source (Linux Foundation) créé après le changement de licence de Terraform (BSL). Syntaxe quasi identique.
resource "aws_s3_bucket" "logs" {
bucket = "entreprise-logs-prod"
tags = { equipe = "plateforme" }
}
terraform init # télécharge providers et configure le backend
terraform plan # prévisualise les changements
terraform apply # applique
terraform destroy # supprime
Ansible : configurer et orchestrer
- Rôle : configuration des serveurs (paquets, fichiers, services), déploiement d'applications, tâches d'exploitation.
- Langage : YAML (playbooks), sans agent (connexion SSH/WinRM).
- Point fort : simple à lire, idéal pour l'existant (VM, bare metal, équipements réseau).
- hosts: webservers
become: true
tasks:
- name: Installer nginx
ansible.builtin.package:
name: nginx
state: present
- name: Démarrer nginx
ansible.builtin.service:
name: nginx
state: started
enabled: true
ansible-playbook -i inventaire.ini site.yml --check # simulation
ansible-playbook -i inventaire.ini site.yml
Packer : fabriquer des images
- Crée des images de VM ou de conteneurs reproductibles (AMI, image Azure, etc.), souvent avec Ansible pour la configuration.
- Alimente une approche immutable.
Kubernetes, Helm, Kustomize : décrire les applications
- Kubernetes : manifestes YAML déclaratifs (Deployment, Service, Ingress...).
- Helm : gestionnaire de paquets (charts) avec paramétrage.
- Kustomize : surcharges par environnement sans templating.
Argo CD / Flux : GitOps
- Surveillent un dépôt Git et synchronisent le cluster avec son contenu. Ils détectent et corrigent le drift.
Crossplane : IaC via l'API Kubernetes
- Permet de provisionner du cloud avec des ressources Kubernetes (CRD) et de construire des APIs de plateforme maison (ex. « une base de données » = un objet simple). Très utilisé dans les IDP.
Pulumi, CDK, Bicep, CloudFormation
- Pulumi / AWS CDK : IaC avec de vrais langages (Python, TypeScript, Go).
- CloudFormation (AWS) / Bicep (Azure) : IaC natif du cloud concerné.
Outils complémentaires
| Besoin | Outils |
|---|---|
| Organisation du code Terraform | Terragrunt, modules, Terraform Cloud/Spacelift/env0 |
| Secrets | HashiCorp Vault, cloud KMS, External Secrets, SOPS |
| Policy as code | OPA/Gatekeeper, Kyverno, Sentinel, Checkov, tfsec/Trivy |
| Portail développeur | Backstage, Port, Humanitec |
| CI/CD | GitLab CI, GitHub Actions, Jenkins |
4. Terraform vs Ansible : qui fait quoi ?
| Critère | Terraform / OpenTofu | Ansible |
|---|---|---|
| Usage principal | Provisionner l'infrastructure | Configurer les systèmes |
| Approche | Déclarative, avec state | Procédurale (tâches ordonnées), sans state |
| Exemple | Créer un VPC, 3 VM, une base | Installer nginx, déployer la config, créer des utilisateurs |
| Agent | Non (API des providers) | Non (SSH/WinRM) |
| Cycle de vie | Fort (création, modification, destruction suivies) | Plus faible (pas de mémoire des ressources) |
Les deux sont complémentaires : Terraform crée les machines, Ansible les configure. Dans une approche conteneurisée, Packer, Kubernetes et le GitOps prennent une grande partie du rôle d'Ansible.
5. Chaîne type dans une plateforme
Développeur → Portail (template) → Dépôt Git → Pipeline CI/CD
→ Terraform/Crossplane (infra) → Ansible/Packer (config/images)
→ Argo CD (déploiement Kubernetes) → Observabilité + sécurité
6. Bonnes pratiques
- Tout est dans Git (revue de code, historique, retour arrière).
- State distant et verrouillé, jamais en local ni dans Git.
- Modules réutilisables et versionnés : ce sont les briques des golden paths.
- Un environnement = les mêmes modules avec des variables différentes (dev, recette, prod).
- Aucune modification manuelle en console : sinon, drift.
- Pas de secrets en clair dans le code.
- Intégrer dans la CI :
fmt,validate,plan, scans de sécurité, puisapplyaprès validation. - Tester (Terratest, Molecule pour Ansible) et documenter.
7. Pièges fréquents
- State corrompu ou partagé sans verrou.
- Gros monolithe Terraform unique : préférer plusieurs états par domaine.
- Mélanger les rôles : utiliser Ansible pour créer du cloud, ou Terraform pour configurer des serveurs en détail.
- Modules trop paramétrables, donc illisibles et difficiles à maintenir.
8. À retenir en une phrase
Terraform crée l'infrastructure, Ansible la configure, Kubernetes + GitOps exécutent et synchronisent les applications, et la plateforme expose tout cela aux développeurs sous forme de services simples en libre-service.
Backlinks:
??? backlink "None"