Les infrastructures cloud modernes doivent faire face à des imprévus, notamment des pannes régionales. Bien que rares, ces interruptions peuvent mettre hors service des applications critiques si elles ne sont pas anticipées. Dans cet article, nous allons explorer une stratégie simple mais puissante pour rendre votre Infrastructure as Code (IaC) sur Google Cloud Platform (GCP) résiliente à une telle panne en utilisant Terraform/Terragrunt.
Nous allons nous concentrer sur une astuce majeure : structurer vos modules Terragrunt par région afin de pouvoir désactiver rapidement et proprement une région via une simple configuration. Cette approche permet de garder le contrôle sur l’état de votre infrastructure sans modifications lourdes.
La problématique : Et si une région devenait indisponible ?
Imaginez que votre application dépend d’une seule région sur GCP, disons europe-west9. Si cette région devient indisponible, toutes vos ressources associées — instances, bases de données, load balancers — cessent de fonctionner. Les conséquences ? Interruption de service, pertes financières, impact sur la réputation.
Pour répondre à ces enjeux, la majorité des plans de continuité/reprise de l'activité proposent de créer une infrastructure multi-régionale et hautement disponible qui vous permet de basculer sur une nouvelle région en cas de panne sur toute une région (incendie, guerre, coupure électrique par exemple).
Dans la plupart des infrastructures modernes, des technologies comme Terraform sont utilisées pour automatiser via du code le déploiement des infrastructure. Ceci permet d'éviter des procédures manuelles et de devoir intervenir directement sur des centaines de machines.
Mais que se passe-t-il lorsqu'une région tombe ? On continue à utiliser le Terraform nominal ? Et bien ce n'est pas si simple, puisque lors du refresh des ressources, l'API de votre cloud provider préféré risque de répondre avec difficulté, ou bien de donner une réponse erronée : ressource existante ou ressource non trouvée. Bref, on peut vite se retrouver à supprimer manuellement du state une myriade de ressources inacessibles et d'en importer d'autres.
Vous l'aurez compris au-delà de séparer le state en plusieurs state de périmètre restreint, nous allons aussi le segmenter par région pour les rendre indépendantes.
L’astuce : Structurer vos modules Terragrunt par région
Terragrunt est un outil qui complète Terraform en simplifiant la gestion des configurations complexes. Avec lui, vous pouvez organiser vos fichiers Terraform en modules distincts par région. Cela permet de :
- Activer ou désactiver facilement une région.
- Gérer les états Terraform (également appelés state files) de manière isolée pour chaque région.
- Réduire les risques d’erreurs en maintenant une structure claire.
Organisation des modules
Voici à quoi pourrait ressembler une organisation de fichiers Terragrunt :
infra/
terragrunt.hcl # Configuration globale
regions/
europe-west1/
terragrunt.hcl
europe-west9/
terragrunt.hcl
global/
terragrunt.hcl
modules/
gce/
main.tf
load_balancing/
main.tf
config.yaml
Contenu d'un fichier Terragrunt pour une région
Dans chaque dossier de région (par exemple, regions/europe-west9/terragrunt.hcl), vous pouvez inclure :
skip = ! local.config[local.region].enabled
terraform {
source = "../../../modules/region"
}
locals {
config = yamldecode(file(find_in_parent_folders("config.yaml")))
region = basename(get_terragrunt_dir())
}
inputs = {
region = local.region
}
Avec ce fichier, vous pouvez contrôler l’activation d’une région en modifiant simplement <region>.enabled. Si vous le passez à false, toutes les ressources associées à cette région seront ignorées. Voici un exemple de fichier config.yaml :
europe-west9:
enabled: true
europe-west1:
enabled: false
Dans cet exemple, la région de Paris (europe-west9) est activée et celle de Bruxelles (europe-west1) est désactivée. Lors d'un désastre, il suffit d'inverser les booléens et grâce à l'attribut skip, seul le code Terraform des régions opérationnelles sera exécuté.
Mise en œuvre : Exemple pratique
1. Créer les modules Terraform
Commencez par créer un module Terraform réutilisable pour chaque région. Par exemple, dans modules/gce/main.tf :
variable "config" {
type = string
}
variable "region" {
type = string
}
resource "google_compute_instance" "example" {
name = "example-instance"
machine_type = "e2-medium"
zone = "${var.region}-b"
boot_disk {
initialize_params {
image = "debian-cloud/debian-11"
}
}
network_interface {
network = "default"
}
}
Ici, le module est agnostique de l'activation ou non de la région : le code est plus simple et plus sûr car l'activation est gérer au niveau de Terragrunt.
2. Configurer Terragrunt
Dans le fichier racine infra/terragrunt.hcl :
include "root" {
path = find_in_parent_folders()
}
remote_state {
backend = "gcs"
config = {
bucket = "tfstates"
prefix = path_relative_to_include()
location = "EU"
}
}
Chaque région peut alors avoir son propre backend dans l'arborescence du bucket.
3. Tester la désactivation d’une région
Pour désactiver une région, il suffit de modifier la variable dans le fichier config.yaml :
europe-west9:
enabled: false
europe-west1:
enabled: true
Ensuite, exécutez :
terragrunt run-all --terragrunt-non-interactive init -reconfigure -upgrade
terragrunt run-all --terragrunt-non-interactive apply
Terragrunt ignorera automatiquement tous les modules associés à cette région.
Conclusion : Une IaC prête à affronter les imprévus
Cette stratégie permet de gérer efficacement les pannes régionales sur GCP en simplifiant la gestion des régions via Terragrunt. En organisant vos modules par région et en utilisant des variables de configuration claires, vous pouvez adapter rapidement votre infrastructure sans risques majeurs.
La résilience commence par une bonne planification. Prenez le temps de structurer vos configurations et testez régulièrement vos stratégies pour garantir que votre infrastructure reste robuste face à l’imprévisible.
Top comments (0)