Phase 1 : Préparation de l’environnement
Le runner GitLab démarre et récupère une image Docker officielle de Terraform (hashicorp/terraform:1.5.0).
Il télécharge le code source du dépôt gitlab.
Il télécharge le fichier nommé tfplan généré lors de l’étape précédente (terraform plan). Ce fichier contient la liste exacte des changements à effectuer sur AWS.
Phase 2 : Initialisation de Terraform (terraform init)
Les fichiers de configurations vont être appliqués :
Terraform se connecte à un espace de stockage distant (S3) pour synchroniser l’état de l’infrastructure (le fichier .tfstate).
Les Plugins/Providers : Il télécharge les modules nécessaires pour interagir avec les API d’AWS, de TLS et de génération de texte :
- hashicorp/aws : C’est le plugin qui traduit le code Terraform en vrai appels d’API AWS pour créer les instances EC2, ta base de données RDS ou tes règles Route53.
- hashicorp/random : C’est le petit module utilitaire qui permet de générer des chaînes de caractères aléatoires.
- hashicorp/tls : C’est le module qui permet à Terraform de générer lui-même une clé privée de chiffrement (le fichier id_rsa que le job Ansible récupèrera ensuite)
Phase 3 : Déploiement de l’infrastructure (terraform apply)
Le runner exécute la commande terraform apply -auto-approve tfplan et lance immédiatement la création :
Étape 1 : Initialisation :
- Génération de la clé privée SSH (tls_private_key) et du mot de passe de la base de données (random_password).
- Création des Security Groups (règles de pare-feu réseau) et des politiques d’accès IAM.
Étape 2 : Les serveurs :
- Lancement des deux instances EC2 : le nœud de contrôle ansible_control_node et le serveur applicatif wordpress_server.
- Attribution des adresses IP publiques (Elastic IPs).
Étape 3 : Routage et Réseau complexe (~2m45s)
- Déploiement du Network Load Balancer (NLB) et de ses écouteurs HTTP/HTTPS.
- Création des enregistrements DNS dans Route53 pour blog.jhennebo.fr et devop-project.jhennebo.fr
Phase 4 : Les « gros » composants AWS (9 minutes)
Le Load Balancer (aws_lb.k8s_nlb) – 2 min :
AWS doit instancier des répartiteurs de charge de haute disponibilité sur plusieurs zones. Dès qu’il est prêt, Terraform crée les écoutes (ports 80 et 443)
Étape 4 : Déploiement de la base de données (~6m40s) :
- Le point d’accès EICE (bastion_eic) – 1 min : C’est le tunnel sécurisé AWS pour le SSH sans IP publique.
- Création et configuration de l’instance managée RDS MySQL (aws_db_instance.mysql).
La base de donnée RDS, aws_db_instance.mysql – 6 min :
AWS ne crée pas juste un conteneur MySQL, il déploie une machine virtuelle dédiée, installe l’OS, configure le moteur MySQL de manière managée, applique le chiffrement des volumes de stockage demandés, et prépare les sauvegardes automatiques.
AWS applique tout un protocole automatisé :
AWS démarre une instance EC2 invisible basée sur une AMI Amazon Linux optimisée pour les bases de données.
L’OS est configuré selon des normes de sécurité ultra-strictes. Les accès SSH directs à cet OS sont totalement désactivés (même moi, je ne peux pas m’y connecter en SSH, je n’ai accès qu’au port MySQL 3306).
L’installation du moteur : AWS installe et configure les binaires officiels de MySQL 8.0.
Le raccordement des volumes de stockage (EBS) : Terraform demande un stockage chiffré (storage_encrypted = true).
La configuration de la maintenance : L’OS configure des agents internes pour gérer les sauvegardes automatiques quotidiennes (les snapshots) et surveiller la santé de la machine (RAM, CPU, I/O).
C’est le principe du PaaS (Platform as a Service) : je gère moi-même les tables SQL, les utilisateurs MySQL, les index et requêtes et AWS gère sur son Amazon Linux les mises à jour de sécurité, les correctifs (patches) du moteur MySQL et les pannes matérielles sous-jacentes.
Phase 5 : Le bilan final (Outputs)
Terraform affiche fièrement le résultat : 47 ressources ajoutées.
ansible_public_ip = « 3.125.227.177 » : C’est l’IP publique de l’instance Ansible.
rds_endpoint : L’adresse privée de la base MySQL.
wordpress_private_ip = 172.31.38.193
A la fin du script, le conteneur Terraform écrit l’IP de la machine Ansible dans un fichier d’environnement (bastion.env) et le sauvegarde en tant qu’artifact GitLab.
Grâce à cela, le prochain job (ansible-deploy) saura exactement sur quelle IP se connecter pour lancer les Playbooks, je n’ai pas besoin d’écrire l’IP à la main dans mon code.
$ echo « ANSIBLE_BASTION_IP=$(terraform output -raw ansible_public_ip) » > ../bastion.env