# 🚀 Automated Web Infrastructure Deployment (DevOps Multi-Site Architecture)
Ce dépôt contient l’intégralité du code source permettant de provisionner, configurer, déployer et superviser une infrastructure web haute disponibilité hébergeant des sites WordPress dans le Cloud AWS.
L’ensemble de l’écosystème est piloté selon les principes de l’Infrastructure as Code (IaC) et de la culture GitOps : chaque modification poussée sur la branche master déclenche automatiquement la mise à jour de la plateforme.
🏗️ Architecture Générale
L’infrastructure s’articule autour de 5 piliers technologiques majeurs :
Provisionnement (IaC) : Terraform (fichiers HCL) orchestre les ressources réseau, calcul et DNS sur AWS avec un backend distant sécurisé (S3 + DynamoDB pour le state-lock).
Configuration & Déploiement : Ansible automatise la préparation des nœuds OS, consomme dynamiquement les secrets et pilote le cluster.
Orchestration Applicative : Kubernetes (K3s) isole, scalabilise et assure la résilience (Self-Healing) des applications WordPress via des Pods.
Intégration & Livraison Continues : GitLab CI/CD fait office de chef d’orchestre global via des pipelines automatisés exécutés par un Runner dédié.
Supervision : Une stack locale Prometheus & Grafana pour monitorer l’infrastructure.
—
🛠️ Prérequis & Environnement de Gestion
Pour initialiser, exécuter et interagir avec cette infrastructure, l’environnement local (machine de gestion) et le compte distant doivent valider les prérequis suivants :
1. Configuration Locale (Machine Virtuelle / PC)
Système d’exploitation : Machine virtuelle Linux (Ubuntu/Debian) interconnectée à une machine hôte Windows. Elle est configurée derrière un réseau NAT pour conserver une IP fixe locale (indispensable lors des bascules de connexions Wi-Fi / partages de connexion mobile).
Docker & Docker Compose : Nécessaires localement pour exécuter la stack de monitoring déportée (Prometheus & Grafana).
Le monitoring repose sur un pipeline sécurisé traversant un tunnel réseau sans exposition de ports sur l’Internet public grâce à l’utilisation de EICE (Endpoint connexion instance)
2. Architecture CI/CD & Exécution des Pipelines
Ce projet utilise les **Runners partagés (Shared Runners)** mis à disposition gratuitement par GitLab.com SaaS. Il n’y a donc aucun « Project Runner » dédié ou privé à installer ou à configurer dans les paramètres du projet.
### Flux d’exécution et Déploiement (GitLab ➔ AWS)
Le déploiement automatisé repose sur une architecture en deux temps :
1. **Phase Terraform (Infrastructure as Code) :**
Les Runners partagés de GitLab exécutent directement les commandes Terraform (`init`, `plan`, `apply`). Pour interagir avec AWS, le Runner utilise les variables d’environnement sécurisées du projet (`AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY`) afin de provisionner le VPC, le NLB, la base RDS et les instances EC2 (Ansible et K3s).
2. **Phase Ansible (Configuration & Déploiement applicatif) :**
Une fois l’infrastructure prête, le Runner GitLab doit configurer le cluster K3s et déployer WordPress.
* **Le point d’entrée :** N’ayant pas de Runner privé dans le VPC, le Runner GitLab initie une connexion SSH sécurisée directement vers l’**IP publique de l’instance de rebond Ansible**.
* **Sécurisation :** La clé privée SSH permettant cette connexion est stockée de manière éphémère et sécurisée dans les variables CI/CD de GitLab.
* **Le déploiement final :** L’instance Ansible, ainsi connectée, prend le relais localement pour exécuter les Playbooks et configurer le cluster K3s (via son IP privée dans le VPC).
3. **Variables & Secrets (Configuration GitLab CI/CD)
Le pipeline requiert l’injection préalable de variables d’environnement sécurisées (masquées et protégées) dans l’interface de GitLab (Settings > CI/CD > Variables) :
AWS_ACCESS_KEY_ID : L’identifiant de la clé d’accès IAM AWS dotée des droits d’administration.
AWS_SECRET_ACCESS_KEY : La clé d’accès secrète IAM correspondante.
AWS_DEFAULT_REGION : La région de déploiement cible : eu-central-1 (Francfort).
* **TF_BACKEND_OPTS** : Chaîne d’arguments d’initialisation pour le backend S3 distant de Terraform. Elle permet d’injecter dynamiquement le bucket de stockage d’état (`.tfstate`) lors de la phase de `init` du pipeline GitLab, évitant ainsi un stockage local éphémère.
*Exemple de valeur :* `-backend-config= »bucket=exam-2026-terraform-backend-jhennebo » -backend-config= »key=terraform.tfstate » -backend-config= »region=eu-central-1″`
4. Ressources Cloud Préexistantes
Nom de Domaine & Zone Hébergée : Une Zone Hébergée publique Amazon Route 53 préexistante pour votre nom de domaine (ex: jhennebo.fr). Les sous-domaines applicatifs (blog.jhennebo.fr, devop-project.jhennebo.fr) n’ont pas besoin d’être créés manuellement : ils sont injectés et créés dynamiquement par Terraform lors de l’application du pipeline.
🚀 Guide d’Installation et de Déploiement
Suivez ces étapes pour cloner le projet, configurer l’environnement et lancer le déploiement automatisé.
Étape 1 : Clonage du Projet
Connectez-vous à votre machine de gestion et clonez le dépôt officiel (l’arborescence des dossiers et les images associées seront récupérées automatiquement) :
« `bash
git clone https://gitlab.com/jhennebo/exam-2026-devops.git
cd exam-2026-devops
Étape 2 : Configuration des Variables sur GitLab
Rendez-vous sur votre projet GitLab ➔ Settings ➔ CI/CD.
Développez la section Variables.
Ajoutez vos clés AWS (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_DEFAULT_REGION fixée sur eu-central-1) en veillant à cocher l’option Mask variable pour des raisons de sécurité.
### 🚀 Alternative : Évolution vers un Runner Privé (Specific Runner)
Si les politiques de sécurité de l’entreprise imposent de fermer totalement l’accès SSH public de l’instance Ansible, l’architecture peut évoluer vers un **Runner GitLab dédié** interne au VPC.
Pour implémenter cette solution :
1. **Provisioning :** Déployer une instance EC2 (ex: `t3.medium`) dans un subnet privé du VPC.
2. **Installation :** Installer le paquet `gitlab-runner` et le moteur Docker sur cette instance via un script d’User Data ou un rôle Ansible.
3. **Enregistrement :** Récupérer le *Registration Token* dans les paramètres CI/CD du projet GitLab et enregistrer le runner via la commande :
« `bash
sudo gitlab-runner register \
–url « [https://gitlab.com/](https://gitlab.com/) » \
–registration-token « VOTRE_TOKEN » \
–executor « docker » \
–docker-image « alpine:latest »
Sécurité Réseau : Modifier le Security Group d’Ansible pour n’autoriser le port 22 (SSH) qu’en provenance de l’IP privée de ce nouveau Runner. Les flux CI/CD deviennent alors 100 % internes au réseau AWS.
🛡️ Sécurité & Flux Réseau
La sécurité des données et des accès a été placée au centre de l’architecture :
Accès d’Administration Privatisés : Aucun port SSH (22) n’est exposé sur l’Internet public pour l’administration directe. L’accès aux instances s’effectue de manière isolée via un point de terminaison AWS EICE (EC2 Instance Connect Endpoint) authentifié par rôles IAM.
Base de Données Managée (PaaS) : Les données sont externalisées sur une instance Amazon RDS MySQL. Isolé architecturalement du cluster Kubernetes, ce service managé prend en charge le chiffrement natif des volumes (storage_encrypted = true), les correctifs de sécurité de l’OS (Amazon Linux), et les snapshots de sauvegarde automatisés.
Gestion Flux des Secrets : Aucun mot de passe ou clé privée n’est stocké en dur dans le dépôt. Le pipeline extrait à la volée les clés générées de manière logicielle (via tls_private_key) depuis AWS Secrets Manager pour les injecter en mémoire durant l’exécution.
🚀 Le Pipeline CI/CD (Workflow de Déploiement)
Le pipeline GitLab CI/CD s’appuie sur votre infrastructure de Runners et se découpe en deux étapes automatisées :
1. Job apply (Terraform)
Génération des paires de clés SSH (tls_private_key.ansible_key) et des mots de passe aléatoires forts.
Poussée automatique des secrets vers AWS Secrets Manager.
Instanciation de l’infrastructure réseau (VPC, Security Groups), des instances EC2 (t3.small pour Ansible, t3.medium pour K3s).
Gestion Dynamique du DNS : Dès que le Network Load Balancer (aws_lb.k8s_nlb) est prêt, Terraform applique le fichier dns.tf et crée les enregistrements de type Alias A dans Route 53 pour lier blog.jhennebo.fr et devop-project.jhennebo.fr au Load Balancer en moins de 31 secondes.
Extraction de l’IP publique d’Ansible transmise via un artefact de build (administration.env).
2. Job deploy (Ansible)
Démarrage d’un conteneur éphémère équipé de openssh-client et aws-cli.
Récupération sécurisée de la clé privée depuis AWS Secrets Manager.
Connexion et transfert automatisé (via scp) du dossier Ansible depuis le Runner GitLab vers l’IP publique de l’Ansible Control Node.
Ouverture d’un canal SSH chiffré vers cette même IP publique pour installer à la volée le moteur Ansible et lancer l’exécution des playbooks.
Exécution locale des playbooks par l’Ansible Control Node, qui utilise l’inventaire dynamique pour cibler et configurer les instances (K3s / WordPress) via leurs IP privées au sein du VPC AWS.
Génération dynamique des manifestes Kubernetes (Deployment, Service ClusterIP, IngressRoute Traefik) via des templates Jinja2 (.j2) et déploiement applicatif multi-site.
📊 Supervision & Monitoring (Stack Locale)
Afin d’optimiser les coûts et de ne pas surcharger les ressources de production d’AWS, l’observabilité est déportée localement sur la machine de gestion via Docker Compose :
Collecte (Prometheus) : Écoute les métriques à travers un tunnel de communication sécurisé persistant initié via l’EICE vers les agents distants :
Node Exporter : Indicateurs système de l’instance EC2 (CPU, RAM, Disque).
cAdvisor : Indicateurs de performance des conteneurs au sein du moteur K3s.
Visualisation (Grafana) : Restitue l’état de santé global de l’infrastructure en temps réel à l’adresse http://localhost:3000 via des tableaux de bord dynamiques.
💰 Approche FinOps (Optimisation des Coûts)
Le budget mensuel estimé en production s’élève à environ 55,00 $, principalement alloué aux composants garantissant la haute disponibilité (NLB, adresses IPv4 publiques du VPC, et stockage sécurisé RDS).
Afin de respecter les principes FinOps, l’intégralité de cette infrastructure de serveurs peut être instantanément détruite en fin de session de travail (terraform destroy) ou mise en pause. Grâce au pipeline CI/CD, l’environnement complet se reconstruit à l’identique en moins de 15 minutes.
🛠️ Utilisation au Quotidien & Accès aux Services
Une fois le déploiement terminé avec succès, l’infrastructure expose plusieurs points d’entrée pour la production et l’administration.
1. Accès aux Applications Web (WordPress)
Le trafic est routé dynamiquement par l’Ingress Controller Traefik vers les pods Kubernetes correspondants. Les sites sont accessibles en HTTPS (certificats SSL automatisés) aux URL configurées dans votre zone Route 53 :
Site Principal : https://blog.jhennebo.fr
Site Projet/DevOps : https://devop-project.jhennebo.fr
2. Accès à l’Administration et à la Supervision Locale
La stack d’observabilité tourne sur votre machine locale et centralise les données de production :
Interface Grafana : http://localhost:3000 (Permet de visualiser les dashboards système de l’EC2 et les métriques de K3s/cAdvisor).
Serveur Prometheus : http://localhost:9090 (Pour requêter directement les métriques brutes collectées via les tunnels autossh).
Une fois le pipeline GitLab complété avec succès et les instances démarrées sur AWS, initialisez la stack d’observabilité locale depuis votre machine de gestion :
« `bash
# Se positionner dans le répertoire du monitoring
cd monitoring/
# Ouvrir le tunnel et Lancer la stack Prometheus / Grafana en arrière-plan
./tunnel.sh
docker-compose up -d
# Nettoyage en fin de session :Fermeture sécurisée.
docker compose down
pkill -f « aws ec2-instance-connect open-tunnel »
3. Commandes Utiles pour l’Exploitation (DevOps)
`Si vous devez interagir avec l’infrastructure ou auditer le cluster depuis le nœud de contrôle Ansible (via le tunnel sécurisé EICE) :
« `bash
# Vérifier l’état des pods et des services Kubernetes (K3s)
kubectl get pods -A
kubectl get svc,ingressroute -A
# Consulter les logs en temps réel d’un pod WordPress spécifique
kubectl logs -f deployment/wordpress-deployment
# Tester l’inventaire dynamique pour lister vos instances démarrées à Francfort (eu-central-1)
ansible-inventory -i aws_ec2.yml –graph
« `
# accéder au git lab
—
## ✍️ Auteur & Licence
### 👤 Développeur
* **Auteur :** Julien Hennebo
* **Rôle :** Ingénieur DevOps / Développeur Fullstack
* **Contact :** Vous pouvez consulter mon profil et me contacter directement sur [LinkedIn](https://www.linkedin.com/in/julien-hennebo-symfony-devops).
### 📄 Licence
Ce projet est distribué sous la licence **MIT**. Vous êtes libre de l’utiliser, de le modifier et de le distribuer, tant que vous incluez la mention de l’auteur original.