Infrastructure immuable et Cloud-Init

1. Vue d'ensemble du concept et problème systémique

L'administration manuelle traditionnelle via SSH mène inévitablement au chaos :

• Un ingénieur se connecte au serveur un vendredi à 22h00, modifie en urgence une ligne dans la configuration Nginx, oublie de documenter le changement et rentre chez lui.
• Six mois plus tard, il faut migrer le serveur vers un autre hébergeur ou le mettre à l'échelle.
• Le nouveau serveur est déployé selon l'ancien guide — et rien ne fonctionne ! Personne ne se souvient des paquets installés manuellement ni des permissions appliquées dans /etc.

L'Infrastructure Immuable (Immutable Infrastructure) interdit définitivement la mutation des serveurs actifs : si vous devez modifier ne serait-ce qu'un paramètre, vous ne patchez pas l'ancien serveur — vous déployez une nouvelle instance prête à l'emploi, basculez le trafic et détruirez l'ancienne.

2. Taxonomie architecturale et modèle mental

┌─────────────────────────────────────────────────────────────┐
│                 IMMUTABLE PROVISIONING CYCLE                │
├─────────────────────────────────────────────────────────────┤
│ 1. INFRASTRUCTURE AS CODE (Git Repository):                 │
│    • `cloud-init.yaml`: Security hardening, UFW, Docker      │
│    • `docker-compose.prod.yml`: Application stack           │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Trigger: Provision New VPS (API) │
├─────────────────────────────────────────────────────────────┤
│ 2. CLOUD-INIT BOOTSTRAP (< 90 seconds on Hetzner):          │
│    • Disable root login & password authentication           │
│    • Provision non-root user `deployer` with SSH keys       │
│    • Lock down UFW (allow ONLY ports 80, 443, WireGuard)    │
│    • Install Docker Engine & Tailscale daemon               │
├─────────────────────────────────────────────────────────────┤
│ 3. TRAFFIC SWAP & ZERO DOWNTIME CUTOVER:                    │
│    • Healthcheck PASS ➔ Point DNS / Floating IP to NEW VPS  │
│    • Terminate OLD VPS ➔ Zero leftovers, zero drift!        │
└─────────────────────────────────────────────────────────────┘

3. Scénarios d'ingénierie pratiques en production

01. Script Cloud-Init de référence pour la commande d'un VPS sécurisé

Transmis dans le champ User Data lors de la création du serveur :

#cloud-config
users:
  - name: orlov
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...
package_update: true
packages:
  - ufw
  - fail2ban
  - docker.io
runcmd:
  - ufw default deny incoming
  - ufw default allow outgoing
  - ufw allow 22/tcp
  - ufw allow 80/tcp
  - ufw allow 443/tcp
  - ufw --force enable
  - systemctl enable --now docker

4. Pièges courants, erreurs typiques et sécurité

• Tentative de persistance de l'état local sur un serveur immuable : Si l'application stocke les fichiers téléchargés par les utilisateurs directement sur le disque local du serveur, ces données seront perdues lors du remplacement de l'instance. Tout état utilisateur doit être conservé dans des espaces de stockage dédiés (S3, Cloudflare R2) ou des bases de données.
• Erreurs dans le script d'initialisation : Si une erreur de syntaxe affecte la clé SSH dans le fichier cloud-init.yaml, le serveur démarrera sans accès possible. Testez toujours vos configurations d'initialisation sur des machines de test peu coûteuses.

5. Conclusion stratégique pour l'ingénieur de 2026

L'infrastructure immuable libère les ingénieurs de la peur des pannes de serveurs. Lorsque chaque nœud de votre système peut être détruit et reconstruit en une minute et demie avec une simple pression de touche, l'infrastructure devient prévisible, facilement scalable et immunisée contre l'erreur humaine.