Fraîche Flow
MILOUD NECILI
INTÉGRATION DE SYSTÈMES INFORMATIQUES
Situation initiale
Fraîche Flow est un scénario de projet de la ville de Carhaix-Plouguer. Avec Klemmbausteine GmbH et l’Université de Bretagne Occidentale, il prévoit de mettre en réseau des systèmes de distribution d’eau, des capteurs et des actionneurs de brumisation.
Problème
Les systèmes étaient décentralisés. Les données d’exploitation et les données à caractère personnel devaient rester dans l’environnement municipal. Certains services devaient néanmoins être accessibles aux partenaires du projet.
Mission
Ma mission consistait à mettre en place l’environnement serveur nécessaire dans le laboratoire : installation des systèmes, configuration des services, tests fonctionnels, dépannage et documentation.
Profil du projet
Dans le cadre de ma reconversion professionnelle, j’ai construit et documenté un laboratoire virtuel regroupant Linux, des services de base, le stockage, des applications web, des conteneurs, la sauvegarde et la supervision.
| Contexte du projet | Laboratoire de formation et d’apprentissage, sans prétendre à une exploitation en production |
|---|---|
| Mon rôle | Mise en place pratique, configuration, tests, dépannage et documentation |
| Achèvement | Toutes les tâches documentées traitées dans le cadre de l’exercice de laboratoire |
| Éléments probants | Sorties de terminal, vérifications de configuration et captures techniques |
| Documentation | 20 rapports thématiques et cette présentation du projet |
Axes techniques
- Linux et virtualisation : Debian, Hyper-V, Proxmox, poste d’administration et contexte LXC.
- Services de base et stockage : BIND9, Kea, SSH, TrueNAS, Windows Storage Spaces et iSCSI.
- Applications : Apache, PHP, MariaDB, Nextcloud natif et conteneurisé, Redis, Portainer et serveur de messagerie.
- Exploitation : rsync, Cron, test de restauration, Chrony, Uptime Kuma et AutoKuma.
Résultats en bref
Le tableau de bord final d’Uptime Kuma indique 15 points de terminaison supervisés en ligne et aucun hors ligne. Certains taux de disponibilité historiques sont inférieurs à 100 %. La documentation distingue l’accessibilité actuelle, l’historique et les tests fonctionnels.
Architecture et rôles des services
| Système | Rôle |
|---|---|
| ff-edge-01 · .1 | Passerelle et point d’entrée SSH du laboratoire |
| ff-pve-01 · .10 | Hyperviseur Proxmox |
| ff-core-01 · .11 | DNS et services de base |
| ff-store-01 · .12 | TrueNAS et cible de sauvegarde iSCSI |
| ff-app-01 · .13 | Apache, services natifs et charges de travail Docker |
| ff-mail-01 | Serveur de messagerie distinct dans le contexte Proxmox/LXC |
| ff-mgmt-01 | Poste d’administration dont l’adresse a changé au cours du projet |
Préfixe réseau : 192.168.10.0/24. Zone DNS interne : fraicheflow.test. Ce tableau décrit le laboratoire, et non une infrastructure publique.
Éléments techniques sélectionnés
- DNS : syntaxe de zone valide ; ff-app-01, portal et nextcloud résolus vers 192.168.10.13.
- Web : syntaxe Apache valide ; HTTP 200 et redirection HTTPS vers la connexion Nextcloud.
- Sauvegarde : sauvegarde rsync, configuration Cron, journalisation et test de restauration de fichiers traités au cours du projet.
- Conteneurs : Nextcloud, Redis, MariaDB, Portainer, Chrony et le serveur web indiqués en cours d’exécution par
docker ps. - Supervision : moniteurs créés par AutoKuma ; réponse Socket.IO ; signaux de contrôle de MariaDB système avec
status=1.
Périmètre et transparence
Le responsable du projet a confirmé le traitement de toutes les tâches. Aucune valeur de test n’est inventée lorsqu’une sortie d’origine n’est pas disponible. Les rapports distinguent cette confirmation des résultats directement visibles. Le regroupement est thématique ; il ne constitue pas une réception officielle ni une validation certifiée par l’organisme de formation.
Ne sont pas présentés comme des réalisations vérifiées : certificat DuckDNS/Let’s Encrypt publiquement reconnu, Nginx Proxy Manager, test complet de reprise après sinistre, SLA de production ou chaîne complète de notification externe.
Vue d’ensemble de la documentation
- 01 Administration Linux et shell
- 02 Git et documentation versionnée
- 03 Poste d’administration Linux et IAM local
- 04 Architecture et virtualisation
- 05 Accès via la passerelle et redirection de ports SSH
- 06 DNS avec BIND9
- 07 DHCP avec Kea
- 08 Administration SSH et sécurisation des accès
- 09 TrueNAS et Windows Storage Spaces
- 10 iSCSI et stockage bloc
- 11 Sauvegarde et restauration automatisées
- 12 Nextcloud sur Apache, PHP et MariaDB
- 13 Certificats TLS et HTTPS
- 14 Docker Engine et image de serveur web personnalisée
- 15 Stack Nextcloud avec MariaDB et Redis
- 16 Gestion des conteneurs avec Portainer
- 17 Service de temps Chrony en conteneur
- 18 Serveur de messagerie, DNS et connexion des clients
- 19 Supervision centralisée avec Uptime Kuma
- 20 Réception, reprise et transfert à l’exploitation
Pour un entretien technique
Je peux expliquer les dépendances entre services, suivre le chemin d’accès du client au conteneur et circonscrire les pannes grâce au DNS, aux ports, aux journaux et aux signaux de contrôle. Des exemples parlants sont une mauvaise adresse de serveur DNS, la sélection par en-tête Host dans Apache et la distinction entre un historique rouge et un état actuellement en ligne.