Évolution du projet

Vers une Résilience Multi-AZ Globale

Étape A : Remplacer le bloc resource "aws_instance" "wordpress_server" par un Launch Template + un Auto Scaling Group

(pour avoir nos 2 instances WordPress réparties sur private_subnets[0] et private_subnets[1]).

1. Le Launch Template (Le moule de mon WordPress)

On crée d’abord le gabarit qui définit à quoi ressemble chaque serveur WordPress. 

resource "aws_launch_template" "wordpress_template" {
  name_prefix   = "wordpress-template-"
  image_id      = data.aws_ami.ubuntu.id
  instance_type = var.wordpress_instance_type
  key_name      = aws_key_pair.ansible_keypair.key_name

  # On associe le Security Group du WordPress
  vpc_security_group_ids = [aws_security_group.wordpress_sg.id]

  # Configuration du disque dur (22 Go gp3 comme tu avais configuré)
  block_device_mappings {
    device_name = "/dev/sda1"
    ebs {
      volume_size           = 22
      volume_type           = "gp3"
      delete_on_termination = true
    }
  }

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "wordpress-asg"
    }
  }

  lifecycle {
    ignore_changes = [image_id]
  }
}

2. L’Auto Scaling Group (Le gestionnaire Multi-AZ)

C’est ici qu’on active la magie du Multi-AZ. On crée le groupe qui va utiliser le modèle ci-dessus et on lui demande explicitement de se déployer sur tous mes sous-réseaux privés (Zone A et Zone B) :

resource "aws_autoscaling_group" "wordpress_asg" {
  name_prefix         = "wordpress-asg-"
  desired_capacity    = 2  # 🚀 AWS va maintenir TOUJOURS 2 serveurs allumés
  max_size            = 4  # Il pourra monter à 4 si besoin
  min_size            = 1  # Au minimum 1 serveur

  # 🌟 LA CLÉ DU MULTI-AZ : On donne la LISTE de tes sous-réseaux privés
  vpc_zone_identifier = module.vpc.private_subnets

  launch_template {
    id      = aws_launch_template.wordpress_template.id
    version = "$Latest"
  }

  # Optionnel mais propre : AWS attendra que l'instance soit saine
  health_check_type         = "EC2"
  health_check_grace_period = 300
}

Ce que ça change concrètement :

Au lieu d’avoir un seul serveur figé dans private_subnets[0], AWS va lire module.vpc.private_subnets (qui contient la liste de tes zones). Comme on a demandé une capacité de 2, l’ASG va automatiquement démarrer une instance dans la zone A et une instance dans la zone B.

Étape B : Administration et CI/CD (Approche Serverless / No-Bastion)

: Plutôt que de maintenir un serveur Ansible permanent dans un ASG — ce qui imposerait de gérer la persistance des playbooks ou l’usage de coffres-forts de clés (Secrets Manager) —, l’architecture cible supprime complètement la VM Ansible. C’est le GitLab Runner qui exécute directement les commandes terraform apply puis ansible-playbook de manière éphémère et stateless. Cela réduit à zéro la surface d’attaque externe d’administration, élimine le coût d’une VM inutile et supprime le besoin d’une Elastic IP dédiée.

Etape C: Stockage et Persistance Stateful :

> * Données structurées : La base de données Amazon RDS passe en multi_az = true pour une réplication synchrone entre les zones.

  • Données non structurées (Médias/Plugins) : Afin d’éviter les désynchronisations entre les deux instances WordPress, le répertoire wp-content est déporté sur un système de fichiers partagé Amazon EFS, garantissant que les deux nœuds lisent et écrivent sur la même source de vérité.

Étape D : Déploiement d’un GitLab Runner Privé et Managé

Pour permettre à GitLab CI d’exécuter nos playbooks Ansible et nos commandes Terraform sans aucune exposition sur Internet, nous créons un exécuteur privé.

Retour en haut