Frontière IaC — Terraform, Ansible, GitOps

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Fiche d'arbitrage (provisionner / configurer / déployer)
Provisionner (jour 0) Terraform, Crossplane
Configurer (jour 1) Ansible
Déployer (jour 2) GitOps (ArgoCD, Flux)
Voir aussi Terraform — Concepts fondamentaux · Terraform — Providers on-prem · Crossplane — Panorama

Fiche d'arbitrage. Trois familles d'outils se chevauchent partiellement. La question n'est pas « lequel est le meilleur », mais « qui provisionne, qui configure, qui déploie ». Cette page fixe la frontière.

Les trois responsabilités

<mermaid> flowchart LR 

   subgraph J0[Jour 0 — Provisionnement]
     TF[Terraform / OpenTofu
ou Crossplane]
   end
   subgraph J1[Jour 1 — Configuration]
     ANS[Ansible]
   end
   subgraph J2[Jour 2 — Déploiement continu]
     GITOPS[GitOps — ArgoCD / Flux]
   end
   TF -->|VM, réseau, cluster| ANS
   ANS -->|OS durci, paquets, services| GITOPS
   GITOPS -->|workloads, addons| APP[(Applications)]

</mermaid>

  • Provisionner = faire exister l'infrastructure (VM, réseau, cluster, buckets). Déclaratif, orienté state. → Terraform, Crossplane.
  • Configurer = amener un système à un état interne voulu (paquets, fichiers, utilisateurs, durcissement). Procédural idempotent. → Ansible.
  • Déployer = maintenir en continu l'état applicatif d'un cluster depuis un dépôt Git. Réconciliation permanente. → GitOps (ArgoCD/Flux).

Tableau comparatif

Dimension Terraform Ansible GitOps (ArgoCD)
Rôle principal Provisionner l'infra Configurer les systèmes Déployer/réconcilier dans K8s
Paradigme Déclaratif (state) Procédural idempotent Déclaratif (réconciliation)
Modèle d'exécution Push, à la demande (apply) Push, à la demande (playbook) Pull, continu (agent in-cluster)
Source de vérité State + code HCL Playbooks (pas de state) Dépôt Git
Gère le drift Au prochain plan/apply Non (relance manuelle) En continu, automatique
Périmètre idéal Cloud, vSphere, DNS, clusters OS, durcissement, appliances Manifests/Helm dans K8s
Secrets Vault provider, state chiffré Ansible Vault, lookups ESO, Sealed Secrets
Frontière typique Jusqu'au cluster existant Du BIOS au démon systemd Du namespace au pod

Zones de recouvrement (et arbitrage)

  • Terraform peut installer des charts Helm (provider helm) — à éviter pour l'applicatif : on perd la réconciliation continue. Réserver au bootstrap minimal (ArgoCD lui-même), puis laisser GitOps prendre le relais (app of apps).
  • Ansible peut provisionner du cloud (modules) — à éviter au-delà de l'appoint : pas de state, pas de plan/diff, pas de gestion fine du drift.
  • Configuration OS dans K8s — préférer des images durcies (construites en amont) plutôt qu'Ansible sur des nœuds éphémères ; réserver Ansible aux nœuds/appliances persistants (pare-feu, LDAP, stockage).

Règle de décision

  1. L'objet naît-il (VM, cluster, réseau) ? → Terraform/Crossplane.
  2. L'objet est un système à configurer (OS, appliance) ? → Ansible.
  3. L'objet vit dans Kubernetes et doit rester aligné sur Git ? → GitOps.

Pour l'alternative « control plane » à Terraform, voir Crossplane — Panorama.

Voir aussi

Récupérée de "https://wiki.nexiat.fr/index.php?title=Frontière_IaC_—_Terraform,_Ansible,_GitOps&oldid=1876"