Je vais vous présenter une solution de déploiement de sites web de façon automatisée dans le cloud. En tant qu’opérateur Devops, l’idée est de faire en sorte que le système s’installe de façon automatisée, le code comme une infrastructure.
La question est de savoir comment réaliser cela en ayant au final un système disponible, scalable, reproductible et automatisée en préservant la sécurité.
Les outils principaux sont Terraform pour le provisionnement, Ansible pour la mise en place des environnements, Kubernetes pour l’isolation des applications et GitLab pour le déploiement et la gestion des versions via un pipeline CI/CD.
Le dépôt visible en ligne
https://gitlab.com/jhennebo/exam-2026-devops
1 Architecture générale
L’infrastructure du projet est gérée par Terraform qui est installé sur une machine virtuelle Linux depuis mon Pc Windows. Une instance Ec2 sur le cloud gère la configuration de la solution avec Ansible. Les sites WordPress sont déployés via des conteneurs.
Les besoins fonctionnels sont la haute disponibilité, la scalabilité, l’automatisation et la sécurité.
Gitlab est le pilote de la solution. La plateforme web va me permettre de stocker le code, de le versionner et d’automatiser le déploiement de la solution. Dès qu’une modification du code est effectuée, elle peut ensuite être poussée sur le dépôt. Ce nouveau code est ensuite appliqué et testé.
Gitlab détient les variables secrètes d’accès à AWS (bastion.env). l récupère de manière dynamique les sorties de Terraform (comme l’ID de l’instance ou les variables réseau) via un rapport d’artefact (dotenv) pour les transmettre instantanément aux tâches Ansible de l’étape suivante.
Terraform
Terraform utilise le langage HCL ((hashicorp), des appels en https transmettent les instructions à l’API REST AWS. Celle-ci fonctionne grâce à un langage écrit en GO.
J’utilise un backend distant composé d’un bucket AWS S3 et d’une table DynamoDB pour stocker l’état de Terraform (state).
Ansible
L’instance Ansible utilise le langage python. Les fichiers sont écrits en yaml, ce sont des fichiers dits sérialisés, l’indentation permet de lister des caractéristiques et d’exécuter des actions. Des modules permettent le lancement de script. Les fichiers sont aussi appelés playbooks mais en réalité, il y a des fichiers dits de rôle et de taches. Ils vont permettre de créer un environnement, d’ajouter des outils et de les configurer.
Pour faciliter l’utilisation d’Ansible, j’ai créé un inventaire dynamique. Cela permet de récupérer de façon automatique les machines en cours d’exécution sur AWS et de leur appliquer ensuite la configuration souhaitée.
Kubernetes et gestion du trafic
Un Network Load Balancer sur AWS (couche 4 transport) fournit un point d’entrée stable pour l’infrastructure cloud via un nom DNS. Ce DNS redirige le trafic vers le nœud Kubernetes. Cette couche supplémentaire permet de rendre le système scalable, hautement disponible et résilient. Il permet de vraiment isoler mon instance k3s. Les requêtes des utilisateurs arrivent sur le NLB et elles sont transmises via des ports spécifiques à mon instance.
Traefik est un ingress controller, (couche 7 application) son rôle est de recevoir le trafic entrant (http/HTTPS), Un Ingress Controller est un composant Kubernetes qui gère l’accès aux applications depuis l’extérieur du cluster.Il est le routeur HTTP/HTTPS du cluster Kubernetes, il permet de diriger les requêtes vers les bons services/pods kubernetes, de gérer les noms de domaine, de gérer le certificat SSL/TLS. Il a le rôle de reverse proxy. Le service de Kubernetes associé à cette fonction est de type NodePort car il permet l’ouverture sur l’extérieur via des ports spécifiques.
J’utilise ensuite un service de type ClusterIP dans Kubernetes pour assurer une communication interne stable et transparente avec une IP fixe virtuelle. Un service de type ClusterIp pour le PodTraefic et un pour le pod WordPress. (ip en 10.0.x.y, 3 étant spécifique à k3s). Même si les pods sont détruits et recréés et que leurs adresses IP changent, l’adresse des ClusterIP, elle, reste fixe. C’est le ClusterIP de traefic qui distribue intelligemment les requêtes vers le ou les Pods WordPress actifs.
2 Réseau, Sécurité et Gestion des Secrets
Configuration Réseau et Accès :
Au niveau du réseau, j’ai attribué une adresse ip privée fixe à mon pc via un internal nat. Mon adresse privée est 192.168.100.10 est fixe. Je me connecte à internet via la 4G de mon téléphone mobile, cela a permis de faciliter mes connexions vers Aws.
Pour l’instances AWS nommée Ansible, j’utilise une Elastic IP. Cela permet de garantir la stabilité de l’accès, l’adresse IP publique reste identique même après un arrêt, un redémarrage ou un remplacement de l’instance. C’est cette élastic IP qui permet la connexion et l’utilisation de GitLab pour le déploiement de la solution.
Avec l’avancement du projet, j’ai dû sécuriser la connexion. J’ai alors mis en place un endpoint d’administration pour communiquer avec AWS depuis ma machine virtuelle locale. La connexion se fait grâce via EICE (EC2 Instance Connect Endpoint), un service géré par AWS.
EICE sert de passerelle sécurisée pour les accès à mes instances et pour le monitoring.
L’authentification pour la connexion SSH se fait par mon rôle/clé IAM et est sécurisé via un groupe de sécurité spécifique,aws_security_group.eic_sg.id .(Ingress et Egress rule)
Le certificat SSL/TLS est géré via Traefic, l’ingress controller de Kubernetes.
Sécurité et gestion des secrets ;
La clé SSH est créé par Terraform et elle est enregistrée dans sa mémoire interne. Elle est ensuite récupérée en ligne de commande AWS et elle est enfin stockée dans AWS Secret Manager.
Ansible s’authentifie à AWS via rôle/clé IAM), il appelle l’API AWS Secrets Manager
Il récupère le secret, Il utilise les mots de passe dans ses taches. Aucun des mots de passe ou clé privée n’est écrit dans le playbook de Ansible
3 Construction et évolution du projet ;
Le projet actuel est le résultat d’une démarche d’ingénierie itérative, découpée en 5 étapes clés d’apprentissage et d’industrialisation :
Etape 1 : Nginx
J’ai créé le site internet avec un serveur Nginx sur l’instance aws. J’ai configuré manuellement le fichier /etc/nginx/nginx.conf et /etc/nginx/sites-available/default.
J’ai utilisé ansible pour automatiser l’installation et le déploiement.
Etape 2 : Docker
J’ai commencé par un déploiement de sites WordPress avec docker.
Docker est un outil de conteneurisation, il permet à partir d’images d’installer et de configurer une application et ses dépendances dans des environnements isolés.
J’ai ensuite rattaché un sous-domaine en créant une route et un enregistrement DNS sur AWS et j’ai créé le certificat SSL avec cert-manager.
Une fois le déploiement réussi, j’ai utilisé Ansible pour automatiser l’installation.
Etape 3 : Kubernetes
Ensuite j’ai installé Kubernetes sur l’instance WordPress. J’ai ajouté des PVC pour la persistance des données (images, fichiers de code). Une fois le déploiement réussi, je me suis rendu compte que le certificat SSL/TLS généré par cert-manger n’était pas applicable tel quel et qu’il me fallait utiliser l’ingress controller, Traefik.
Etape 4 : Persistance des sites web
La création d’une base de données RDS sur Aws m’a permis de conserver mes données lors du passage à Kubernetes. Les pods peuvent être recréés sans que les données soient perdues (pages, articles). Je gagne aussi en sécurité, disponibilité. La base de données est indépendante des pods, elle est maintenue et mis à jour et bénéficie des sauvegardes automatiques dans AWS. La surface d’attaque est réduite.
Étape 5 : Automatisation du Déploiement
Toutes les briques du projet s’ajoutent et s’imbriquent dans une chaine de livraison continue. Pour cela, je m’appuie sur le fichier de variables ansible/roles/wordpress/vars/main.yml, qui centralise la liste des sites, leurs domaines et leurs bases de données. J’utilise notamment un template avec le fichier wordpress-deployment.yaml.j2 , c’est-à-dire que les fichiers pour Kubernetes sont créés de façon dynamique et sont ensuite appliqués sur le cluster. Ainsi Ansible génère tous les objets Kubernetes nécessaires (Deployment, Service, Certificate, IngressRoute) pour déployer WordPress avec routage et SSL automatisés. A chaque push vers Gitlab, ansible compile les variables, applique les objets sur le cluster.
4 Supervision, Monitoring et Industrialisation
Plus de détails sur la page Monitoring
Le monitoring repose sur un pipeline sécurisé traversant un tunnel réseau sans exposition de ports sur l’Internet public :
Node Exporter : Remonte les données matérielles de l’EC2 (CPU, RAM, Disque, Réseau).
cAdvisor : Collecte les indicateurs de performance au cœur même du moteur de conteneurs de K3s (ressources consommées par Pod/Conteneur).
La Restitution (Grafana) : Les tableaux de bord officiels (ID 1860 pour le système et ID 14282 pour K3s) synthétisent visuellement ces métriques sur le port local 3000.
5 Budget mensuel
1. Amazon Elastic Load Balancing (NLB) : 20,00 $
C’est le composant le plus cher de mon infrastructure. AWS facture les Load Balancers au prorata du temps où ils restent allumés (environ 0,025 $ de l’heure).
L’explication : C’est le prix de la haute disponibilité. Le NLB tourne 24h/24 pour guider le trafic vers le cluster Kubernetes via son point d’entrée DNS.
2. Amazon Virtual Private Cloud (VPC) : 18,60 $
Historiquement, le VPC était gratuit. Cependant, AWS facture désormais l’utilisation des adresses IPv4 publiques (environ 0,005 $ par heure et par IP).
L’explication : Ce montant correspond aux IPs publiques associées à mes passerelles NAT (NAT Gateways) ou à mon instance EC2/Elastic IP pour permettre les communications avec l’extérieur (comme le téléchargement des paquets ou la validation Let’s Encrypt).
3. Amazon Elastic Compute Cloud (EC2) : 7,45 $
Pourquoi ce coût ? C’est le prix de la « puissance de calcul » brute. J’utilise une instance de petite taille, t3.small pour l’instance où se trouve Ansible et t3.médium pour l’instance qui héberge k3s, l’Ingress Controller Traefik et les sites WordPress.
4. Amazon RDS : 6,00 $
C’est le coût de mon instance de base de données managée MySQL (db.t3.micro) et de ses 20 Go de stockage SSD associés.
AWS gère le moteur MySQL, les sauvegardes automatiques et la sécurité des données WordPress en arrière-plan.
5. Amazon Route 53 & Autres : 3,04 $(0,51$ + 2,53 $)
Route 53 facture 0,50 $ par mois pour l’hébergement d’une « Zone Hébergée » (mon domaine jhennebo.fr). Les « Autres » centimes correspondent généralement au stockage de tes volumes de disque dur (EBS) ou à la rétention de tes logs.
C’est le coût de la gestion des serveurs DNS et du stockage résiduel.
Optimisation FinOps : Afin d’éviter la consommation inutile de ces budgets hors des périodes de développement, l’intégralité de l’infrastructure a été pensée pour être éteinte (Stop/Start des instances EC2 et RDS) ou détruite (terraform destroy). Grâce à la robustesse du pipeline GitLab CI/CD, l’environnement complet de production et ses tunnels de monitoring locaux se reconstruisent à l’état de l’art en moins de 5 minutes.
Conclusion
Ce projet valide l’efficacité de l’approche DevOps face aux défis modernes de la livraison continue et de la résilience des infrastructures. La réussite de cet écosystème ne repose pas uniquement sur la performance individuelle de ses composants, mais sur leur interconnexion et leur automatisation complète :
GitLab CI/CD permet d’exécuter le déploiement, chaque modification de code (git push) déclenche automatiquement la reconstruction de la solution.
Terraform crée les instances et sécurise l’infrastructure réseau à travers un VPC (Virtual Private Cloud)
Ansible configure le système, il exécute les déploiements applicatifs multi-sites de façon automatisée sans exposer les mots de passe.
Kubernetes (K3s) garantit l’isolation, la haute disponibilité et la scalabilité des pods WordPress.
La base de données RDS isole et sécurise les données de l’application de manière managée.
Le point de terminaison EICE sécurise les accès SSH vers AWS pour les tests et pour le monitoring depuis ma machine locale avec Prometheus et Grafana.
L’infrastructure web n’est plus un ensemble de serveurs artisanaux configurés manuellement, mais une solution auditable, résiliente et hautement sécurisé. Ce projet démontre qu’une solution peut être mise en place de façon automatisée et contrôlée entièrement depuis un dépôt de code.