PR : Configuration Management Tools and Infrastructure as Code

[Zestblvck]

Rapport de Pull Request : Configuration Management Tools and Infrastructure as Code

Auteurs : MEZIANE Zakariae, ALIOUA Nordine et NOUMDEM Karl

---

🔗 Liens du Projet

• Dépôt original (Doodle Student) : https://github.com/selabs-ur1/doodle

---

Sommaire

1. Introduction
2. Objectifs DevOps
3. Justification des choix technologiques
4. Démarrage rapide
5. Accès aux Interfaces
6. Cœur du Sujet : Configuration Management (Jinja2 & Nginx)
7. Infrastructure as Code : Déploiement avec Ansible
8. Extensions DevOps (CI/CD, Chaos, Monitoring)
9. Conclusion

---

1. Introduction

Ce projet consiste en la modernisation de l'application DoodleStudent par la mise en œuvre de solutions professionnelles de Configuration Management et d'Infrastructure as Code (IaC). Nous avons transformé une application manuelle en une plateforme automatisée, sécurisée et résiliente.

---

2. Objectifs DevOps

Nos interventions visaient à remplir quatre objectifs fondamentaux :

• Automatiser le cycle de déploiement pour réduire les interventions manuelles.
• Standardiser les environnements pour garantir la reproductibilité totale.
• Sécuriser la configuration en isolant les secrets et les paramètres.
• Améliorer la maintenabilité par une documentation et un code d'infrastructure clairs.

---

3. Justification des choix technologiques

Pourquoi ces outils plutôt que d'autres ? Voici notre réflexion technique :

Outil	Choix	Justification Technique
IaC	Ansible	Contrairement à des scripts Bash, Ansible est idempotent. Son approche agentless le rend extrêmement léger pour notre infrastructure.
Config	Jinja2	Le moteur de template Jinja2 permet de transformer une configuration statique en une infrastructure dynamique.
Conteneurs	Docker	Docker est le standard industriel pour isoler les services et garantir la portabilité.
Chaos	Pumba	Outil natif Docker pour manipuler les conteneurs individuellement et tester la résilience.
Monitoring	Uptime Kuma	Dashboard intuitif pour une observation immédiate de l'uptime.

---

4. Démarrage rapide

Option A : Déploiement automatisé (Ansible)

Ansible pilote l'infrastructure et effectue les étapes suivantes :

1. Vérification : S'assure que Docker est installé.
2. Provisioning : Crée les répertoires nécessaires.
3. Configuration : Génère dynamiquement le fichier .env via Jinja2.
4. Orchestration : Lance la stack via Docker Compose.

# Se placer dans le dossier infra/ansible
ansible-playbook -i inventory.ini playbook.yml

Option B : Déploiement direct (Docker Compose)

docker compose up -d --build

---

5. Accès aux Interfaces

Interface	URL Locale	Rôle
Frontend Doodle	http://localhost:4200	Interface utilisateur
API Backend	http://localhost:8080	API REST Quarkus
Monitoring (Uptime Kuma)	http://localhost:3001	Surveillance de la disponibilité

---

6. Cœur du Sujet : Configuration Management (Jinja2 & Nginx)

Nous avons implémenté une gestion de configuration dynamique pour éliminer toute dépendance fixe.

A. Découplage du Frontend (Nginx Template)

Nous utilisons un template Nginx (front/nginx.conf.template) qui injecte l'URL du backend au démarrage du conteneur via envsubst.

Exemple de Template Nginx :

location /api/ {
    proxy_pass ${BACKEND_URL}; # Injecté dynamiquement
}

B. Synthèse de la Gestion de Configuration

Élément	Implémentation	Intérêt Technique
Fichier .env	Généré via Ansible	Évite le stockage de secrets en clair dans le code.
Nginx Config	Template dynamique	Permet un routage flexible vers l'API sans re-compiler.

---

7. Infrastructure as Code : Déploiement avec Ansible

Ansible garantit que l'infrastructure est déployée de manière identique sur n'importe quelle machine.

A. Détail des fichiers IaC

• inventory.ini : Définit les machines cibles. Permet de séparer la configuration réseau du code.
• group_vars/all.yml : Centralise toutes les variables. C'est notre source unique de vérité.
• templates/.env.j2 : Template dynamique fusionnant les variables dans le .env de l'application.
• playbook.yml : Le script maître qui orchestre le déploiement complet.

B. Extraits de code techniques

La Source de Vérité (group_vars/all.yml) :

db_password: "tlc"
backend_url: "http://backend:8080"
latency_time: "3000ms"

Le Playbook (playbook.yml) :

- name: Deploiement de DoodleStudent
  tasks:
    - name: Generation du .env depuis template
      template:
        src: templates/.env.j2
        dest: "../../.env"

    - name: Lancement de la stack Docker Compose
      command: docker compose up -d
      args:
        chdir: "../../" # Synchronise le contexte d'exécution

---

8. Extensions DevOps

CI/CD & Smoke Test

Notre pipeline GitHub Actions automatise les tests. Nous avons ajouté un Smoke Test qui valide la disponibilité réelle de l'API :

- name: Smoke Test
  run: |
    curl -f http://localhost:8080/api/polls || exit 1

Chaos Engineering (Pumba)

Nous avons testé la résilience du système face à des pannes. Le service Pumba est commenté par défaut dans le docker-compose.yaml pour préserver la stabilité, mais peut être activé pour valider l'auto-guérison.

Extrait du service Chaos :

  # pumba:
  #   image: ghcr.io/alexei-led/pumba:latest
  #   container_name: pumba
  #   volumes:
  #     - /var/run/docker.sock:/var/run/docker.sock
  #   command: netem --duration 1h delay --time ${LATENCY_TIME} "re2:^doodlestudent-backend"

Monitoring (Uptime Kuma)

Uptime Kuma (port 3001) offre une visualisation immédiate de la santé des services, cruciale pour observer les effets du Chaos Engineering.

---

9. Conclusion

Ce projet démontre qu'une infrastructure bien gérée par le code (IaC) et surveillée est la clé d'une application moderne. Nous avons réussi à transformer un projet complexe en une solution simple, automatisée et robuste, prête pour une exploitation réelle.