From 9899748e204ab54b6e63e20f20446749f59ff038 Mon Sep 17 00:00:00 2001
From: Hugo Debuyser <hugo.debuyser.etu@univ-lille.fr>
Date: Thu, 16 Jan 2025 19:39:15 +0100
Subject: [PATCH] Avancement Partie 5

---
 procedures/5-final-architecture/README.md     | 13 ++++
 .../5-final-architecture/current-issue.md     | 65 +++++++++++++++++++
 .../final-architecture.md                     |  9 +++
 3 files changed, 87 insertions(+)
 create mode 100644 procedures/5-final-architecture/README.md
 create mode 100644 procedures/5-final-architecture/current-issue.md
 create mode 100644 procedures/5-final-architecture/final-architecture.md

diff --git a/procedures/5-final-architecture/README.md b/procedures/5-final-architecture/README.md
new file mode 100644
index 0000000..353dc08
--- /dev/null
+++ b/procedures/5-final-architecture/README.md
@@ -0,0 +1,13 @@
+<div style="text-align: center;">
+<h1 style="border: none; margin: 0">🚀 PARTIE 5 : Migration et configuration de l'architecture finale</h1>
+</div>
+
+# Sommaire
+
+- [5.1 Problème de notre architecture actuelle et explication de l'architecture finale](./current-issue.md)
+- [5.2 Configuration de l'architecture finale](./final-architecture.md)
+
+<hr>
+
+- Page précédente: [a ajouter]()
+- Page suivante: [a ajouter]()
\ No newline at end of file
diff --git a/procedures/5-final-architecture/current-issue.md b/procedures/5-final-architecture/current-issue.md
new file mode 100644
index 0000000..2cb9908
--- /dev/null
+++ b/procedures/5-final-architecture/current-issue.md
@@ -0,0 +1,65 @@
+# 5.1 : Problèmes de notre architecture actuelle et présentation de l’architecture finale
+
+À ce stade, notre déploiement regroupe tous les services sur une seule machine virtuelle, à l’exception du reverse proxy. Bien que fonctionnelle, cette configuration présente des limitations majeures qui justifient une refonte de l’architecture.
+
+---
+
+## ⚠️ **Problèmes de l’architecture actuelle**
+
+1. **Compatibilité des dépendances**  
+   - Des conflits peuvent survenir si différents services nécessitent des versions incompatibles des mêmes dépendances.  
+   - Bien que cela ne soit pas encore survenu, cette situation reste un risque majeur dans les environnements complexes.  
+
+2. **Point unique de défaillance**  
+   - Si la machine virtuelle hébergeant tous les services tombe en panne (panne matérielle, erreur logicielle…), l’intégralité des services devient indisponible.  
+   - La restauration complète prend du temps et risque d’entraîner des interruptions prolongées.  
+
+3. **Sécurité**  
+   - Une faille exploitée dans un service peut exposer l’ensemble des autres services hébergés sur la même machine.  
+   - Cette configuration augmente les risques d’une compromission globale.  
+
+**Parmi ces problèmes, la sécurité est la préoccupation principale.** Elle motive la migration vers une architecture mieux isolée et plus résiliente.
+
+---
+
+## 🖥️ **Présentation de l’architecture finale**
+
+Pour pallier ces problèmes, nous migrons vers une architecture distribuée, où chaque service est hébergé sur une machine virtuelle distincte. Cette organisation améliore :  
+
+- **Sécurité** : Les services sont isolés, ce qui limite l’impact d’une éventuelle faille de sécurité.  
+- **Fiabilité** : Une panne sur une machine n’affecte que le service qu’elle héberge.  
+- **Évolutivité** : Les services peuvent être mis à jour ou modifiés indépendamment.  
+
+---
+
+### **Structure de l’architecture finale**  
+
+L’architecture se compose de trois machines virtuelles principales :  
+
+1. **La machine Synapse (matrix)** qui est hébergé sur une machine virtuelle dédiée. Elle est connecté à une base de données distante pour gérer les données utilisateur et les messages.  
+
+2. **La machine Element** qui est hébergé sur une autre machine virtuelle. Elle est fournit l’interface utilisateur pour accéder au service Matrix via un navigateur.  
+
+3. **Reverse Proxy (rproxy)** qui reste isolé sur sa propre machine virtuelle. Elle agit comme un point d’entrée unique pour les services accessibles depuis le réseau de l’université.  
+
+---
+
+### **Accès aux services dans l’architecture finale**  
+
+Chaque service sera accessible via une URL dédiée :  
+
+- **Synapse** : `http://matrix.phys.iutinfo.fr:9090`
+
+- **Element Web** : `http://element.phys.iutinfo.fr:9090`
+
+Ces URLs permettent aux utilisateurs d’accéder aux services via le reverse proxy, qui redirige les requêtes vers les machines virtuelles correspondantes.
+
+---
+
+**Illustration de l’architecture finale :**  
+**INSÉREZ SCHÉMA**
+
+---
+
+- **Page précédente** : [Sommaire (partie 5)](./README.md)  
+- **Page suivante** : [Configuration de l'architecture finale](./final-architecture.md)  
\ No newline at end of file
diff --git a/procedures/5-final-architecture/final-architecture.md b/procedures/5-final-architecture/final-architecture.md
new file mode 100644
index 0000000..e2979e6
--- /dev/null
+++ b/procedures/5-final-architecture/final-architecture.md
@@ -0,0 +1,9 @@
+# 5.2 : Configuration de l’architecture finale
+
+Cette section détaille les étapes nécessaires pour configurer l’architecture distribuée, en répartissant les services (Synapse, Element, Reverse Proxy) sur des machines virtuelles distinctes.
+
+___
+
+## 🖥️ Configuration minimale des machines virtuelles
+
+Pour chaque machine virutelle, Pour une administration sécurisée et efficace, déployez vos clés SSH publiques sur chaque machine virtuelle.
\ No newline at end of file
-- 
GitLab