Infrastructure as Workflow : au-delà du Terraform statique

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Gérer les opérations cloud du Day 2 : traiter l'infrastructure comme un processus métier avec état et de longue durée.

La limite de l'« Infrastructure as Code » : Day 1 vs Day 2

Nous adorons Terraform (IaC). Il a résolu le problème du provisionnement du « Day 1 ». Vous décrivez l'état souhaité (10 instances EC2, 1 RDS, 1 VPC), vous lancez terraform apply, et le fournisseur cloud s'en charge. C'est parfait pour les ressources statiques. C'est déclaratif, idempotent et versionné. C'est le socle du DevOps moderne.

Mais la réalité des opérations cloud, c'est que la complexité se trouve au Day 2. Le Day 1, c'est le mariage ; le Day 2, c'est la vie de couple. Le Day 2 concerne des processus, pas seulement des ressources. Il s'agit du cycle de vie bien vivant du système, à mesure qu'il évolue dans le temps.

Prenez le cycle de vie d'une mise à niveau critique de base de données. Ce n'est pas un événement statique ; c'est un workflow :

1. Préparation : Créer un snapshot de la base principale vers S3, par sécurité.

2. Attente : Il faut attendre la fin du snapshot. Pour une grosse base de plusieurs To, cela peut prendre de 30 à 45 minutes.

3. Provisionnement : Démarrer une nouvelle instance de base à partir du snapshot avec la nouvelle version du moteur.

4. Attente : Attendre que la nouvelle instance soit « Available » et « Healthy ».

5. Migration : Se connecter à la nouvelle instance et exécuter un script de migration de schéma (Flyway ou Liquibase). Cela peut prendre 1 heure.

6. Vérification : Lancer une série de smoke tests sur la nouvelle base pour garantir l'intégrité des données.

7. Bascule : En cas de succès, mettre à jour le CNAME DNS pour qu'il pointe vers la nouvelle base.

8. Rollback : Si une étape échoue, il faut rétablir le DNS et détruire l'instance défaillante.

Terraform est mal adapté à cela. Il est déclaratif, pas impératif. time_sleep et les provisioners local-exec existent comme échappatoires pour « attendre 30 minutes » ou « exécuter un script SQL et vérifier le code de sortie », mais Terraform n'a pas de modèle de processus durable, reprenable et soumis à approbation. Pour y remédier, les équipes enveloppent généralement Terraform dans des pipelines Jenkins, des jobs CircleCI ou des scripts Python. On retombe dans la « Glue Code Crisis » évoquée plus tôt dans cette série, mais cette fois pour l'infrastructure. Ces scripts sont fragiles, sans état et impossibles à déboguer lorsqu'ils échouent au milieu d'une opération de 4 heures.

Traiter les opérations comme des workflows durables

Chez SchemaBridge, nous pensons que les opérations d'infrastructure sont des workflows métier. Elles ont les mêmes exigences qu'un flux de traitement de paiements : fiabilité, auditabilité, gestion d'état et reprise sur erreur.

En déplaçant vos opérations du Day 2 dans SchemaBridge, vous bénéficiez de la puissance d'un orchestrateur durable pour votre cloud :

Le pattern « plan de contrôle » : intégration avec AWS, K8s et Terraform

SchemaBridge ne remplace pas Terraform ; il l'orchestre. Nous utilisons le pattern du plan de contrôle pour unifier les mondes statique et dynamique.

1. Le déclencheur : Un développeur pousse du code ou déclenche un workflow « Provision Dev Env » depuis votre portail développeur en appelant l'URL du webhook du workflow.

2. Le provisionnement : SchemaBridge appelle l'API de Terraform Cloud (ou l'endpoint HTTP de votre propre runner) pour lancer l'exécution qui crée les ressources physiques. SchemaBridge n'invoque pas terraform via un shell : les scripts de workflow s'exécutent, par conception, dans un sandbox GraalVM sans accès aux processus ni au système de fichiers.

3. L'attente : Une étape Delay durable attend, puis une étape Gateway vérifie le statut de l'exécution Terraform. Les workflows sont des graphes acycliques : au lieu d'une boucle de polling infinie, vous enchaînez un nombre borné d'étapes d'attente et de vérification, ou vous faites en sorte que le workflow se relance lui-même après un Delay — la même récursion qu'utilise notre propre workflow système de déploiement progressif.

4. Le post-provisionnement (la « couche logique ») : Une fois l'infrastructure en place, SchemaBridge appelle les endpoints qui exécutent les migrations de base, injectent les données de test et lancent les tests d'acceptation — l'API de votre système de CI, ou un petit service d'exploitation que vous contrôlez au sein du nouveau cluster.

Ce pattern vous permet de garder vos ressources définies en HCL (HashiCorp Configuration Language) tout en définissant votre logique opérationnelle dans un graphe visuel.

Environnements éphémères : le Saint Graal de la vélocité des développeurs

Toute équipe d'ingénierie moderne veut des environnements éphémères — une réplique complète de la production pour chaque Pull Request (PR). Cela permet une véritable isolation et évite les bugs avant qu'ils ne soient fusionnés dans main.

Les approches traditionnelles échouent parce que le nettoyage est difficile. Vous démarrez des ressources pour la PR-123, mais le développeur oublie de fermer la PR, ou le script de nettoyage échoue. Votre facture cloud explose avec des « instances RDS zombies » et des « load balancers orphelins ».

Avec SchemaBridge, un environnement est un workflow au cycle de vie défini.

1. Démarrage : Démarrer les ressources (RDS, un cache, des services ECS) via votre API de provisionnement.

2. Attente : Une étape Delay durable arme le démantèlement dès la création — par exemple avec un TTL de 24 heures. L'attente ne mobilise ni worker ni conteneur ; l'heure de réveil est persistée.

3. Nettoyage : À l'expiration du minuteur, le workflow se réveille et appelle votre API de provisionnement pour détruire l'environnement. Pour « démanteler dès que la PR est fusionnée », pointez le webhook de merge de votre fournisseur Git vers un workflow de démantèlement distinct, et rendez ce démantèlement idempotent pour qu'il soit sans danger si les deux se déclenchent.

Comme le minuteur de démantèlement est armé dans la même exécution que celle qui a créé l'environnement, il est difficile à oublier. Même si tout le cluster SchemaBridge redémarre, le minuteur persisté se déclenche quand même et l'environnement de la PR-123 est détruit comme prévu. C'est le « Garbage Collection du cloud ».

Scénario illustratif : déploiement blue/green sans intervention pour un service sensible à la latence

Imaginez une équipe qui exploite un moteur de matching sensible à la latence et doit mettre à jour son service central sans la moindre microseconde d'indisponibilité.

Le défi

Un rolling update Kubernetes standard ne serait pas assez sûr si l'équipe devait vérifier l'exactitude de la nouvelle version sur des données réelles pendant 10 minutes avant de basculer le trafic. Il lui faudrait un déploiement complexe en « Shadow Mode ».

L'approche SchemaBridge

L'équipe pourrait construire un « Blue/Green Deployment Workflow » dans SchemaBridge :

1. Déployer Green : Démarrer la nouvelle version du moteur à côté de l'ancienne (Green).

2. Trafic miroir : Configurer l'API Gateway pour envoyer une copie générique du trafic réel vers Green (fire-and-forget). Les réponses de Green ne sont pas envoyées aux utilisateurs mais capturées.

3. Vérifier : Après un Delay de 10 minutes, le workflow récupère via HTTP un échantillon des réponses capturées de Green et des réponses correspondantes de Blue (en production), et utilise JSONata pour les comparer.

4. Point de décision : Des arêtes conditionnelles routent selon le résultat de la comparaison :

5. Basculer : Le workflow met à jour le load balancer pour basculer le trafic réel des utilisateurs vers Green.

6. Nettoyer : Il attend encore une heure (pour faciliter un rollback), puis détruit Blue.

Le résultat

Ce type de workflow pourrait réduire sensiblement le risque de déploiement. Une équipe SRE pourrait lancer un déploiement et passer à autre chose, en sachant que le workflow exécuterait la vérification et le chemin de nettoyage explicite qu'elle a conçus — transformant des releases risquées et peu fréquentes en releases plus sûres et routinières.

Gestion des coûts : le « workflow » du FinOps

L'optimisation des coûts cloud (FinOps) est souvent un processus manuel qui consiste à relancer les développeurs pour qu'ils éteignent leurs ressources. SchemaBridge vous permet d'automatiser cette gouvernance.

Le pattern Night Watchman

Vous pouvez déployer un workflow « Night Watchman » qui s'exécute chaque soir à 20 h.

1. Scanner : Interrogez votre API d'exploitation (par exemple une petite Lambda ou un service interne qui encapsule le SDK de votre cloud) pour obtenir toutes les ressources étiquetées hors production. SchemaBridge lui parle en HTTP ; il n'a pas de connecteur AWS natif.

2. Vérifier l'activité : Faites remonter par le même endpoint l'utilisation CPU de la dernière heure, et ne conservez que les ressources sous 5 %.

3. Arrêter : Si elles sont inactives, appelez l'endpoint pour arrêter l'instance (sans la résilier).

4. Notifier : Envoyez un message Slack au propriétaire : « Nous avons mis votre machine de dev en pause pour faire des économies. »

5. Reprendre : Un workflow « start my box » distinct, déclenché depuis vos outils d'exploitation via son URL de webhook, redémarre l'instance le matin.

Ce type de workflow simple peut réduire sensiblement les dépenses liées aux environnements de dev inactifs, en limitant le coût récurrent des ressources hors production oubliées et allumées en permanence.

Comparaison : Jenkins/GitLab CI vs opérations SchemaBridge

| Fonctionnalité | Pipelines CI/CD (Jenkins) | Opérations SchemaBridge |

| :--- | :--- | :--- |

| État | Lié à un executor ; les longues attentes mobilisent des ressources | Durable (persisté dans PostgreSQL ; survit aux redémarrages) |

| Durée | Minutes/heures | Heures/jours (minuteurs durables) |

| Logique | Scriptée (Bash/Groovy) | Visuelle (graphe) |

| Approbation | Étape input dans le pipeline | Étape Approval (UI ou API), avec timeout |

| Reprise | Redémarrage depuis un stage | Relance depuis l'étape en échec |

| Parallélisme | Limité par les executors | Fan-out (Spawner) avec workers à mise à l'échelle automatique |

Checklist d'expert pour l'automatisation des opérations

Pour moderniser votre stack opérationnelle, suivez ces heuristiques :

1. Ne scriptez pas les attentes : Si vous écrivez sleep 60 en bash pour attendre un ALB, vous vous y prenez mal. Utilisez une étape Delay durable suivie d'une vérification de statut.

2. Automatisez d'abord la suppression : Écrivez la logique de nettoyage avant la logique de création. Assurez-vous que chaque événement de création a un chemin de destruction correspondant.

3. Utilisez des points d'approbation : N'hésitez pas à mettre un humain dans la boucle pour les actions à haut risque. Un « Pause for Approval » est une fonctionnalité, pas un bug.

4. Auditez l'opérateur : Journalisez qui a déclenché l'environnement et pourquoi. Faites transmettre l'identifiant du demandeur dans le payload par le déclencheur, et apposez-le sur chaque ressource créée.

5. Traitez l'exploitation comme du code : Versionnez vos workflows opérationnels comme votre code applicatif. Exportez-les sous forme de bundles, conservez-les dans votre dépôt pour revue, et déployez-les via la page Deployments (planifier, relire, appliquer) ou un import de configuration.

Conclusion : le cloud est une machine à états

Votre infrastructure n'est pas un tas statique de serveurs ; c'est une composante vivante de votre activité. En la traitant comme une machine à états, vous pouvez automatiser les chorégraphies opérationnelles complexes et multi-étapes qui dévorent aujourd'hui le temps de votre équipe SRE. Vous pouvez passer d'une « exploitation par tickets » à une « exploitation en self-service », avec la sécurité et la durabilité intégrées.

Voir aussi : Le mythe du cold start : optimiser la JVM pour les événements — pourquoi des workers de longue durée l'emportent sur des démarrages à froid par événement.

Explorer