iac-infra : Infrastructure as Code et Supervision DevOps

Contexte et Problématique du Projet iac-infra

Le projet iac-infra s'inscrit dans le cadre du titre professionnel Administrateur Système DevOps (ASD) RNCP 36061 à l'École IT d'Orléans, présenté par Loïc NANZO TONLIEU en mai 2026. La problématique centrale consiste à automatiser intégralement le déploiement, la configuration et la supervision d'une infrastructure cloud-native. Le projet doit appliquer les principes DevOps tout en couvrant les $10$ compétences du Référentiel Emploi Activités et Compétences (REAC) du titre ASD.

Les contraintes techniques imposent un environnement de travail sous Windows 11 utilisant des machines virtuelles via VirtualBox au lieu de serveurs cloud. L'objectif est d'aboutir à une infrastructure $100\%$ automatisée, une chaîne DevOps complète, et une documentation opérationnelle exhaustive. Le formateur référent pour ce projet est Max Fauquemberg.

Démarche Méthodologique et Gestion de Projet

Le développement de l'infrastructure a suivi une approche itérative rigoureuse étalée sur $14$ sprints successifs avec des bilans hebdomadaires. La gestion de version est assurée par Git et GitHub, en utilisant les Conventional Commits (feat, fix, docs) et une gestion rigoureuse des branches et des Pull Requests.

La qualité du code est automatisée à chaque Git push grâce à des outils comme yamllint pour les fichiers YAML, terraform validate, et le scan de sécurité Trivy pour les conteneurs et les manifests. La documentation est continue, incluant un README détaillé, un dossier projet complet et un schéma d'architecture, le tout étant versionné sur GitHub.

Architecture Globale et Couches du Système

L'architecture globale de iac-infra est organisée en quatre couches interconnectées. La Couche 1 est dédiée à l'Infrastructure as Code (IaC) et à la configuration, utilisant un Vagrantfile pour le provisioning, Ansible avec $3$ rôles pour la configuration, et Terraform pour la gestion de l'infrastructure. La Couche 2 concerne la machine virtuelle sous Ubuntu $22.04$ LTS, possédant l'adresse IP $192.168.56.10$ , où sont appliqués des hardening UFW et SSH, et où tourne Docker pour le monitoring.

La Couche 3 est celle de l'orchestration avec Kubernetes, gérant le déploiement de WordPress, une base MariaDB avec stockage persistant (PVC) et Secrets, ainsi qu'un Horizontal Pod Autoscaler (HPA) configuré pour gérer de $2$ à $10$ réplicas. Enfin, la Couche 4 assure la supervision via Prometheus sur le port $9090$ , Grafana sur le port $3000$ , et Alertmanager dont les alertes sont routées vers Discord. Le pipeline CI/CD via GitHub Actions fait le lien entre le code source et le déploiement final en passant par DockerHub.

BC01 — Infrastructure as Code : Vagrant, Ansible et Terraform

Le premier bloc de compétences (BC01) repose sur trois outils majeurs. Vagrant, couplé à VirtualBox, permet de définir une infrastructure de manière déclarative et versionnée. Le réseau est configuré en mode host-only sur l'IP $192.168.56.10$ . Une simple commande vagrant up suffit à lancer la VM et à déclencher le provisioner Ansible intégré.

Ansible est structuré autour de quatre rôles spécifiques : 'common' pour les paquets de base, 'security' pour le renforcement UFW et SSH, 'monitoring' pour l'installation de Docker et de la stack de supervision, et 'webapp' pour le déploiement de WordPress et MariaDB. La persistance est assurée par une gestion via systemd pour l'auto-start au boot. Terraform intervient via un fichier main.tf écrit en HCL pour générer automatiquement l'inventaire Ansible hosts.ini et un fichier de diagnostic infra-info.txt en utilisant des providers locaux et null.

BC02 — Conteneurisation, Orchestration et Pipeline CI/CD

Le BC02 traite de l'environnement conteneurisé. Docker Compose est utilisé pour orchestrer six services : WordPress (image personnalisée), MariaDB $11$ , Prometheus pour les métriques sur le port $9090$ , Grafana pour les dashboards sur le port $3000$ , node-exporter pour les métriques système sur le port $9100$ , et alertmanager sur le port $9093$ .

Sur Kubernetes, les manifests YAML définissent des objets précis : des Deployments WordPress (avec $2$ réplicas initiaux), un Service NodePort exposé sur le port $30080$ , et un Deployment MariaDB avec un PVC de $1\,Gi$ et des Secrets encodés en base64. Le HPA est configuré pour WordPress avec un seuil de déclenchement à $50\%$ de CPU. Le pipeline CI/CD sur GitHub Actions se découpe en quatre étapes : LINT (yamllint), BUILD (docker buildx), PUSH (vers le dépôt Docker Hub lnanzotonlieu/iac-wordpress) et VALIDATE (yamllint sur les manifests K8s).

BC03 — Supervision, Alerting et Gestion de MariaDB

Le BC03 couvre la supervision et l'alerting. Prometheus surveille quatre cibles (targets) : lui-même, node-exporter, mysqld-exporter et alertmanager. Trois règles d'alertes principales ont été définies : HighCPUUsage, HighMemoryUsage et InstanceDown. La formule de calcul PromQL pour le CPU est la suivante :

100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[2m])) \times 100) > 80

Grafana est auto-provisionné avec sa source de données et ses dashboards JSON (CPU, RAM, Uptime). En cas d'alerte, Alertmanager route l'information vers Discord via un webhook. MariaDB $11$ sert de base de données à WordPress, avec des identifiants injectés via des secrets Kubernetes. WordPress génère automatiquement son schéma (wp_users, wp_posts, etc.) lors de l'installation initiale.

Sécurité et Défense en Profondeur

La sécurité est appliquée à chaque couche du projet. Au niveau réseau, UFW impose une politique "deny" par défaut, n'ouvrant que les ports $22$ , $80$ et $443$ . Le durcissement SSH interdit les connexions root (PermitRootLogin no) et désactive l'authentification par mot de passe (PasswordAuth no).

La gestion des secrets repose sur l'utilisation de fichiers .env ignorés par Git, d'Ansible Vault et de Secrets Kubernetes injectés hors des dépôts publics. L'image WordPress est durcie avec l'utilisateur non-root et le paramètre DISALLOW_FILE_EDIT activé. Enfin, la CI inclut des scans Trivy pour détecter les vulnérabilités dans le Dockerfile et les manifests.

Résolution des Problématiques du Sprint 13 et Améliorations

Le sprint $13$ a permis de corriger trois points critiques identifiés par le formateur Max Fauquemberg. Premièrement, le monitoring, autrefois absent des rôles Ansible, a été intégré avec un service systemd dédié et un auto-provisioning Grafana. Deuxièmement, la connexion entre Alertmanager et Discord a été rétablie après avoir identifié une erreur $HTTP\,403$ liée à l'User-Agent par défaut. Un relais en Python (discord_relay.py) sur le port $9094$ a été mis en œuvre pour assurer un code de retour $HTTP\,204$ .

Troisièmement, le projet n'est plus une "boîte vide" (simple page Nginx) mais déploie désormais une application WordPress réelle et durcie, fonctionnant en haute disponibilité avec $2$ réplicas, un HPA et une base MariaDB persistante. Ces corrections ont permis de valider des déploiements réels en remplacement des tests de base.

Validation du Référentiel Emploi Activités et Compétences (REAC)

Le projet valide $100\%$ des compétences REAC ASD, soit $10$ sur $10$ .

BC01-CP1 : Provisionnement de VM avec Vagrant et Ansible.
BC01-CP2 : Utilisation de multi-rôles Ansible.
BC01-CP3 : Terraform pour la génération d'inventaire.
BC01-CP4 : Git et Conventional Commits.
BC02-CP1 : Dockerfile et docker-compose multi-services.
BC02-CP2 : Kubernetes (Deployment, PVC, Secret, HPA).
BC02-CP3 : Pipeline CI/CD GitHub Actions.
BC03-CP1 : Prometheus et Grafana (métriques et dashboards).
BC03-CP2 : Alertmanager et intégration Discord.
BC03-CP3 : MariaDB avec stockage persistant.

Des compétences transverses telles que l'anglais technique (documentation officielle, commits en anglais), la veille technologique continue et la posture professionnelle (autonomie et prise en compte des retours) ont également été démontrées.

Démonstration Live et Procédures Opérationnelles

La démonstration live suit une séquence de commandes précise pour prouver la reproductibilité :

Initialisation de l'infrastructure : vagrant up suivi de ansible-playbook ansible/playbook.yml.
Validation Docker : docker compose up -d et vérification de l'URL http://localhost:8080.
Déploiement Kubernetes : kubectl apply -f kubernetes/ avec vérification des HPA et PVC.
Test de supervision : En arrêtant le service node-exporter, une alerte est déclenchée et reçue sur Discord (confirmée par un log $HTTP\,204$ ). On peut également vérifier la structure des tables SQL de WordPress via SHOW TABLES dans le conteneur db.