Points clés à retenir
- Terraform gère l’état souhaité : il met en place et configure l’infrastructure à partir du code.
- Cloud Rewind permet de capturer l’état réel du déploiement ; cela facilite la restauration des environnements à un moment où leur bon fonctionnement est avéré.
- Les fichiers d’état Terraform et l’historique Git ne sont pas des outils de restauration ; ils ne reflètent pas ce qui était réellement en cours d’exécution.
- Cloud Rewind permet de restaurer l’infrastructure, que les modifications aient été effectuées via l’IaC, la console ou une intervention manuelle.
- Ensemble, Terraform et Cloud Rewind permettent aux équipes de mettre en place une stratégie complète d’opérations cloud : développer rapidement, se remettre encore plus vite.
Si votre équipe utilise Terraform, vous savez déjà à quel point l’IaC peut être puissant. Vous définissez ce que vous voulez, vous l’appliquez, et votre environnement cloud se matérialise. La gestion des changements devient reproductible. Le provisionnement devient prévisible. Mais il existe un écart entre la mise en place d’une infrastructure et sa remise en état – et c’est surtout à 2 heures du matin, lorsqu’un problème survient, que cela prend toute son importance.
Terraform et Cloud Rewind interviennent à différentes étapes du cycle de vie du cloud. Comprendre cette différence vous aide à éviter une hypothèse dangereuse : celle selon laquelle vos outils d’IaC serviraient également de plan de reprise.
En quoi Terraform et Cloud Rewind diffèrent-ils ?
Terraform est un outil de provisionnement. Il définit et gère l’état souhaité. Lorsque vous annulez une modification effectuée avec Terraform, vous réappliquez une configuration souhaitée antérieure ; vous ne restaurez pas l’environnement déployé qui était en service avant l’incident. Cette distinction est importante. L’état Terraform n’est pas un instantané historique permettant une restauration.
Cloud Rewind capture l’état réel de la configuration cloud et stocke des instantanés à un moment donné. En cas de panne, vous ne reconstruisez pas à partir du code en espérant que l’environnement revienne intact. Vous restaurez un environnement dont vous savez qu’il fonctionne correctement – celui qui était effectivement en service –, quelle que soit la manière dont la modification à l’origine du problème a été introduite.
| Conception de Terraform | Conception de Cloud Rewind |
| Gestion de l’état souhaité | Restauration de l’état réel |
| Provisionnement de l’infrastructure | Recovery de l’infrastructure |
| Application des modifications | Annulation des modifications |
| Source de vérité = code | Source de vérité = environnement déployé |
| Orienté vers l’avenir | Rétrospective |
| Créer et mettre à jour | Récupérer et reconstruire |
| Permet de restaurer la configuration souhaitée | Permet de rétablir l’état de déploiement à un moment donné |
Les limites de Terraform
Même les environnements IaC les plus aboutis sont confrontés à des situations de reprise où la reconstruction à partir du code ne suffit pas. Prenons l’exemple suivant :
- Une modification de l’infrastructure qui a échoué et qui a déjà été déployée en production.
- Suppression accidentelle de ressources cloud.
- Dérive de l’infrastructure due à des modifications manuelles ou hors bande.
- Des modifications apportées en dehors de Terraform et qui ne se reflètent ni dans le code ni dans l’état.
- La nécessité de rétablir l’infrastructure exactement telle qu’elle était à un moment précis.
Terraform ne conserve pas l’historique de l’état du cloud. Il réapplique la configuration souhaitée ; il ne restaure pas ce qui était effectivement déployé et en cours d’exécution. « Revenir à 14 h 15 hier » n’est pas une fonctionnalité de Terraform. Il s’agit d’une fonctionnalité de Cloud Rewind.
Une restauration qui repose sur la disponibilité, l’exactitude et l’exhaustivité du code Terraform, des fichiers d’état et de l’historique des versions comporte un risque réel. En cas d’incident réel, ces conditions ne sont pas garanties.
Deux outils, une stratégie complète
Terraform vous aide à automatiser la création d’infrastructures et la gestion des changements. Cloud Rewind vous aide à restaurer votre infrastructure rapidement et de manière cohérente en cas d’échec des déploiements, de suppression de ressources, de dérive de l’infrastructure ou lorsque votre équipe a besoin de rétablir un environnement dont le bon fonctionnement a été vérifié. Ils se complètent. Terraform est conçu pour garantir la reproductibilité de votre environnement cloud. Cloud Rewind est conçu pour garantir sa récupérabilité.
Déployez avec Terraform. Récupérez vos données avec Cloud Rewind.
FAQ
Q : Terraform permet-il une restauration à un instant donné ?
R : Non. Terraform réapplique la configuration souhaitée à partir du code. Il ne conserve pas d’instantanés historiques de votre environnement cloud déployé. Si la modification à l’origine d’un incident n’est pas enregistrée dans l’état Terraform ou dans l’historique Git (par exemple, une modification effectuée via la console ou une dérive de l’état), Terraform ne peut pas vous aider à restaurer l’état initial.
Q : Que se passe-t-il lorsque des modifications sont apportées en dehors de Terraform ?
R : Les modifications via la console, les interventions manuelles et les configurations hors bande sont courantes dans les environnements de production. Terraform ne les suit pas. Cloud Rewind capture l’état réel du déploiement – quelle que soit la manière dont une modification a été introduite – afin que vous puissiez restaurer un environnement dont le bon fonctionnement est avéré, même lorsque votre infrastructure en tant que code (IaC) ne reflète pas ce qui était en cours d’exécution.
Q : Le site Cloud Rewind peut-il remplacer Terraform ?
R : Non. Ces outils répondent à des besoins différents. Terraform est votre outil de provisionnement et de gestion des changements. Cloud Rewind est votre outil de Recovery. La plupart des équipes qui utilisent l’un de ces outils peuvent tirer parti des deux : ils couvrent différentes étapes du cycle de vie des opérations cloud.
Q : Quels types d’incidents sont traités sur le site Cloud Rewind ?
R : Cloud Rewind est conçu pour les situations où la reconstruction à partir du code ne suffit pas : échecs de déploiement en production, suppression accidentelle de ressources, dérive de l’infrastructure, ainsi que les cas où les équipes doivent restaurer un environnement à un moment précis du passé.
Q : Le service Cloud Rewind oblige-t-il les équipes à cesser d’utiliser Terraform ?
R : Non. Cloud Rewind s’intègre à vos workflows IaC existants. Les équipes continuent d’utiliser Terraform pour le provisionnement et la gestion des changements, et ont recours à Cloud Rewind lorsqu’elles doivent remédier à un incident réel.
Cailin Pitcher occupe le poste de responsable senior du marketing de portefeuille chez Commvault.
