Infrastructure as Code et GitOps

1. Pourquoi l'IaC #

Des serveurs reproductibles.

Principes #

• L'infrastructure est décrite dans des fichiers versionnés, relus et testés comme du code.
• Un environnement se recrée à l'identique en quelques minutes (reprise après sinistre, nouvel environnement de test).
• Les changements passent par des pull requests : traçabilité et revue.
• Fin des serveurs « flocons de neige » configurés à la main et impossibles à reproduire.

2. Terraform #

Provisionner de façon déclarative.

Le cycle #

terraform {
  required_providers { docker = { source = "kreuzwerker/docker", version = "~> 3.0" } }
  backend "s3" { bucket = "tfstate-shop" key = "staging/terraform.tfstate" region = "eu-west-3" }
}
variable "replicas" { type = number, default = 2 }
resource "docker_image" "nginx" { name = "nginx:1.27" }
resource "docker_container" "web" {
  count = var.replicas
  name  = "web-${count.index}"
  image = docker_image.nginx.image_id
  ports { internal = 80, external = 8080 + count.index }
}
output "urls" { value = [for c in docker_container.web : "http://localhost:${c.ports[0].external}"] }

terraform fmt -check && terraform validate
terraform plan -out=plan.tfplan
terraform apply plan.tfplan
terraform state list
terraform plan -detailed-exitcode   # 2 = dérive détectée (utile en tâche planifiée)

L'état #

Terraform mémorise ce qu'il gère dans un fichier d'état. En équipe, il est stocké dans un backend distant (S3, GCS, Terraform Cloud, GitLab) avec verrouillage, pour éviter deux apply simultanés.

Erreur Courante : L'état contient souvent des secrets en clair : chiffrez le backend, restreignez son accès et ne le commitez jamais dans Git.

Modules et environnements #

• Factorisez en modules versionnés (réseau, cluster, base).
• Un répertoire ou un workspace par environnement, avec des variables différentes et le même code.
• Exécutez plan dans la pull request et apply après fusion, depuis la CI.
• Contrôlez la conformité avec tflint, checkov ou des politiques OPA.

3. Configuration et immuabilité #

Ansible et images immuables.

Ansible #

- name: Serveurs web
  hosts: web
  become: true
  tasks:
    - name: Installer nginx
      ansible.builtin.apt: { name: nginx, state: present, update_cache: true }
    - name: Déployer la configuration
      ansible.builtin.template: { src: site.conf.j2, dest: /etc/nginx/conf.d/site.conf }
      notify: Recharger nginx
  handlers:
    - name: Recharger nginx
      ansible.builtin.service: { name: nginx, state: reloaded }

Les modules Ansible sont idempotents : relancer le playbook ne change rien si l'état est déjà conforme. --check --diff montre les changements sans les appliquer.

Infrastructure immuable #

Plutôt que de modifier des serveurs en place (dérive inévitable), on construit une nouvelle image (Packer, image de conteneur) et on remplace les instances. C'est le modèle naturel des conteneurs et de Kubernetes.

4. GitOps #

Git comme source de vérité du déploiement.

Principes #

1. L'état souhaité du système est déclaratif.
2. Il est versionné dans Git, immuable et historisé.
3. Il est tiré automatiquement par un agent.
4. Il est réconcilié en continu : toute dérive est corrigée.

Argo CD #

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: shop-staging, namespace: argocd }
spec:
  project: default
  source:
    repoURL: https://github.com/mon-org/shop-deploy.git
    targetRevision: main
    path: overlays/staging
  destination: { server: https://kubernetes.default.svc, namespace: shop }
  syncPolicy:
    automated: { prune: true, selfHeal: true }
    syncOptions: [CreateNamespace=true]

Bonne Pratique : Séparez le dépôt applicatif (code, Dockerfile) du dépôt de déploiement (manifestes par environnement). La CI met à jour le tag d'image dans le dépôt de déploiement ; une promotion vers la production est une pull request.