📅 Date de réalisation : 30 September 2025
🎯 Problématique & Contexte métier
Comment concevoir une infrastructure cloud sécurisée, reproductible, et maintenable par plusieurs équipes métiers, tout en respectant les bonnes pratiques DevOps et les standards de production ?
Le défi
En entreprise, les infrastructures cloud ne sont pas gérées par une seule personne. Elles impliquent :
- Une équipe réseau (VNet, NSG, NAT, IPs)
- Une équipe compute (VMs, disques, scripts d’initialisation)
- Une équipe SRE/Infra (Load Balancers, monitoring, scalabilité)
- Une équipe support/sécurité (accès bastion, audit)
Souvent, ces équipes doivent :
- Travailler indépendamment
- Partager des outputs sans se bloquer
- Garantir la sécurité des états et secrets
- Pouvoir ajouter/supprimer des ressources dynamiquement
👉 Ce projet simule exactement ce scénario avec Terraform, en créant 4 modules indépendants, chacun avec son propre remote state file, comme dans un vrai environnement de production.
📸 Galerie de captures d’écran
Public Terraform Module
Private Terraform Module
GitHub Repos
Networking
Compute
Load Balancing
Bastion
Backend GitHub
Network Apply
4 Containers
Remote State
Web 1 (External)
Web 2 (Internal)
💡 Objectifs techniques
✅ Concevoir une architecture modulaire avec Terraform
✅ Utiliser des state files séparés stockés dans Azure Blob Storage
✅ Appliquer le principe de responsabilité unique par module
✅ Automatiser le déploiement de VMs avec cloud-init (Apache2)
✅ Mettre en place 2 load balancers (externe + interne)
✅ Gérer les accès via NSG + Bastion + NAT Gateway
✅ Standardiser les noms, tags, et plages IP
✅ Valider le code avec TF Lint
✅ Générer automatiquement la documentation (README.md) avec terraform-docs
✅ Publier les modules sur Terraform Registry + GitHub
✅ Éviter count, privilégier les map objects dynamiques
✅ Rendre l’infrastructure extensible (n VMs, n subnets, etc.)
🏗️ Architecture globale
Schéma d’architecture
Cliquez pour agrandir
🧩 Modules détaillés
Chaque module représente une équipe métier, avec son propre cycle de vie, ses permissions, et son state file.
1. Module networking-project1 → Équipe Réseau
🔗 GitHub
Responsabilités :
- Création du Resource Group
- Déploiement du VNet + 4 subnets (auto-calculés via
cidrsubnet) - Attribution d’un NSG par subnet (règles standardisées via map)
- Création de Public IPs (pour LB externe + NAT Gateway)
- Mise en place de la NAT Gateway (accès sortant pour VMs internes)
- Application de tags sur toutes les ressources
Inputs requis:
- location
- nat_name
- nsg_rules_simple
- nsg_rules_simple
- rg_name
- subnets
- vnet_address_space
- vnet_name
Outputs exposés :
resource_group, vnet_details, subnets_details, public_ip_details, nsg_details, nat_details
2. Module compute-web-tier-project1 → Équipe Infrastructure / VMs
🔗 GitHub
Responsabilités :
- Création de VMs Linux (Ubuntu 22.04 LTS) via map dynamique
- Association à un subnet spécifique
- Ajout de disques de données persistants
- Installation d’Apache2 via cloud-init
- Génération de NICs avec NSG attaché
- Tags + noms standardisés
Inputs requis:
- instances
- location
- rg_name
- tags
Outputs exposés :
disk_details, nic_details, vm_details
3. Module load-balancing-project1 → Équipe SRE / Infra
🔗 GitHub
Responsabilités :
- Création d’un Load Balancer externe (accès public sur port 80 → VM1)
- Création d’un Load Balancer interne (accès interne → VM2)
- Configuration des rules, probes, backend pools
- Sécurisation via NSG implicite (seulement port 80 autorisé)
Inputs requis:
- internal_lb_name
- internal_subnet_id
- internal_vm_nics
- location
- name_external_lb
- public_ip_id
- public_vm_nics
- rg_name
- tags
Outputs exposés :
external_lb_details, internal_lb_details
4. Module bastion-project1 → Équipe Support / Sécurité
🔗 GitHub
Responsabilités :
- Création d’un subnet dédié Bastion
- Déploiement du service Azure Bastion
- Attribution d’une IP publique dédiée
- Accès sécurisé aux VMs sans exposer de ports RDP/SSH
Inputs requis:
- bastion_ip_name
- bastion_name
- bastion_subnet_cidr
- location
- rg_name
- vnet_name
- tags
Outputs exposés :
bastion_details
🔄 Workflow de déploiement (Remote State Files)
Chaque module lit uniquement les states dont il a besoin → dépendances explicites et contrôlées.
4 containers Azure distincts :
network-terraform-statevm-terraform-stateloadbalancing-terraform-statebastion-terraform-state
Sécurité :
Les tokens et secrets ne sont jamais commités (.tfvars local, .gitignore strict).
🛠️ Technologies & Outils utilisés
| Catégorie | Outils & Technologies |
|---|---|
| Cloud | Microsoft Azure |
| IaC | Terraform v1.3+, Modules, Remote State |
| Langage | HCL (HashiCorp Language) |
| Validation | TF Lint, terraform validate |
| Documentation | terraform-docs, README.md auto-généré |
| Versioning | Git, GitHub, Tags SemVer |
| Publication | Terraform Registry (Public & Private) |
| OS | Ubuntu 22.04 LTS (remplacement de 18.04 EOL) |
| Init Scripts | Cloud-init (Apache2 install) |
| Réseau | VNet, Subnets, NSG, NAT Gateway, Public IPs, Load Balancers |
| Sécurité | Bastion Host, Tags, RBAC implicite via modules |
✅ Résultat fonctionnel
- ✅ Accès public via Load Balancer externe → VM1 (site web Apache)
- ✅ Accès interne via Load Balancer interne → VM2 (site web privé)
- ✅ VM2 peut faire apt update grâce à la NAT Gateway
- ✅ Accès sécurisé aux VMs via Azure Bastion (pas de ports ouverts)
- ✅ Toutes les ressources taggées → traçabilité et coûts
- ✅ Ajout/suppression de VMs ou subnets → modification simple de la map d’entrée
Démonstration vidéo (3 min)
Dans la vidéo :
- Je montre le workflow de déploiement module par module
- La connexion au site web public via LB externe
- L’accès interne au site privé via LB interne
- La connexion sécurisée via Bastion
- Le contenu des state files dans Azure Storage Explorer
➡️ Preuve que l’architecture est opérationnelle, modulaire, et sécurisée.
📈 Bonnes pratiques mises en œuvre
| Pratique | Implémentation dans le projet |
|---|---|
| Infrastructure as Code | ✅ 100% Terraform |
| Modularité | ✅ 4 modules indépendants |
| Remote State | ✅ Backend Azure, 4 state files |
| Sécurité des secrets | ✅ .tfvars non versionné, sensitive outputs |
| Extensibilité | ✅ Maps dynamiques (n VMs, n subnets) |
| Documentation automatique | ✅ terraform-docs → README.md |
| Validation syntaxique | ✅ TF Lint + terraform validate |
| Naming convention | ✅ Standard RG-VNET-VM-LB-BASTION |
| Tagging | ✅ Environnement, Owner, Project sur toutes ressources |
| Évitement de count | ✅ Utilisation exclusive de for_each + maps |
| Versioning des modules | ✅ Tags SemVer sur GitHub + Registry |
| Collaboration multi-équipes | ✅ Simulée via découpage modules/state |
🚧 Limites & Axes d’amélioration
| Ce que j’ai fait | Ce qu’on ferait en production |
|---|---|
| Mot de passe en clair dans tfvars | ➤ Azure Key Vault + azurerm_key_vault_secret |
| Cloud-init basique | ➤ Ansible / Packer pour images custom |
| Pas de CI/CD | ➤ Azure DevOps / GitHub Actions pour terraform apply auto |
| Monitoring absent | ➤ Azure Monitor + Alertes sur métriques VM/LB |
| Pas de tests automatisés | ➤ Terratest pour valider connectivité / règles NSG |
| Modules publiés manuellement | ➤ Release automatisée via GitHub Actions |
📚 Sources & Inspirations
🧑💻 Pourquoi ce projet compte pour mon profil d’ingénieur cloud
“Ce projet n’est pas juste un lab.
C’est une simulation de production réelle qui démontre :”
- Ma maîtrise de Terraform avancé (modules, remote state, variables dynamiques)
- Ma capacité à structurer une infrastructure complexe pour des équipes multiples
- Mon attention aux bonnes pratiques DevOps (sécurité, validation, documentation)
- Ma rigueur dans la gestion des dépendances et des états
- Mon autonomie pour résoudre des erreurs complexes (ex: image Ubuntu EOL, outputs sensibles, etc.)
- Mon souci de qualité et professionnalisme (lint, docs auto, tags, naming)
📎 Annexes
- 📁 Code source complet du projet
- 📁 Code source Module Networking
- 📁 Code source Module Compute
- 📁 Code source Module Load Balancing
- 📁 Code source Module Bastion
- 📁 Code Source Préparation pour ce projet
- 📦 Modules Terraform
🚀 Prochaines étapes
- Intégrer Azure Key Vault pour les secrets
- Ajouter du CI/CD avec GitHub Actions
- Écrire des tests d’intégration avec Terratest
- Containeriser les apps avec Docker + Azure Container Instances
- Ajouter du monitoring avec Azure Monitor + Grafana
🧠 Ce que j’ai appris grâce à ce projet
“Les erreurs ont été mes meilleurs professeurs.”
- ✅ Gérer les dépendances entre modules sans créer de spaghetti
- ✅ Comprendre pourquoi Ubuntu 18.04 disparaît soudainement 😅 → gestion du cycle de vie des images
- ✅ Maîtriser
sensitive = trueet ne jamais exposer un mot de passe par accident - ✅ Automatiser la doc avec
terraform-docs→ gagner 2h/semaine en maintenance - ✅ Travailler avec des state files séparés → éviter les conflits en équipe
- ✅ Simuler un workflow multi-équipes → penser comme un architecte, pas juste un dev
➡️ Ce projet m’a transformé d’un utilisateur de Terraform à un concepteur d’infrastructures modulaires.