Fraîche Flow
MILOUD NECILI
FACHINFORMATIK SYSTEMINTEGRATION
Ausgangssituation
Fraîche Flow ist ein Projektszenario der Stadt Carhaix-Plouguer. Gemeinsam mit der Klemmbausteine GmbH und der Université de Bretagne Occidentale sollen Systeme für Wasserverteilung, Sensorik und Sprühnebel-Aktoren vernetzt werden.
Problem
Die Systeme waren dezentral aufgebaut. Betriebsrelevante und personenbezogene Daten sollten innerhalb der kommunalen Umgebung bleiben. Gleichzeitig mussten ausgewählte Dienste für beteiligte Partner erreichbar sein.
Aufgabe
Meine Aufgabe war es, die benötigte Serverumgebung im Labor aufzubauen. Dazu gehörten die Einrichtung der Systeme, die Konfiguration der Dienste, Funktionstests, Fehlersuche und Dokumentation.
Projektprofil
Im Rahmen meiner Umschulung habe ich eine virtuelle Laborumgebung mit Linux, Basisdiensten, Storage, Webanwendungen, Containern, Backup und Monitoring aufgebaut und dokumentiert.
| Projektkontext | Ausbildungs- und Schulungslabor, kein behaupteter Produktivbetrieb |
|---|---|
| Meine Rolle | Praktische Einrichtung, Konfiguration, Tests, Fehlersuche und Dokumentation |
| Abschluss | Alle dokumentierten Aufgaben im Rahmen der Laborübung bearbeitet |
| Nachweise | Terminalausgaben, Konfigurationsprüfungen und technische Screenshots |
| Dokumentumfang | 20 thematische Einzelberichte plus diese Projektübersicht |
Technischer Schwerpunkt
- Linux und Virtualisierung: Debian, Hyper-V, Proxmox, Management-Client und LXC-Kontext.
- Basisdienste und Storage: BIND9, Kea, SSH, TrueNAS, Windows Storage Spaces und iSCSI.
- Anwendungen: Apache, PHP, MariaDB, Nextcloud nativ und als Container-Stack, Redis, Portainer und Mailserver.
- Betrieb: rsync, Cron, Restore-Test, Chrony, Uptime Kuma und AutoKuma.
Ergebnis in einer Momentaufnahme
Das abschließende Uptime-Kuma-Dashboard zeigt 15 überwachte Endpunkte Online und keinen Offline-Endpunkt. Einzelne historische Verfügbarkeitswerte liegen unter 100 %. Die Dokumentation unterscheidet aktuelle Erreichbarkeit, historischen Verlauf und fachlichen Funktionstest.
Architektur und Dienstrollen
| System | Dienstrolle |
|---|---|
| ff-edge-01 · .1 | Gateway und SSH-Einstieg in das Lab |
| ff-pve-01 · .10 | Proxmox-Hypervisor |
| ff-core-01 · .11 | DNS und Basisdienste |
| ff-store-01 · .12 | TrueNAS und iSCSI-Backup-Ziel |
| ff-app-01 · .13 | Apache, native Dienste und Docker-Workloads |
| ff-mail-01 | Separater Mailserver im Proxmox-/LXC-Kontext |
| ff-mgmt-01 | Administrationsclient; Adresse im Verlauf geändert |
Adresspräfix: 192.168.10.0/24. Interne DNS-Zone: fraicheflow.test. Die Tabelle beschreibt das Lab, nicht eine öffentliche Infrastruktur.
Ausgewählte technische Nachweise
- DNS: Zonensyntax OK; ff-app-01, portal und nextcloud auf 192.168.10.13 aufgelöst.
- Web: Apache Syntax OK; HTTP 200 und HTTPS-Weiterleitung zur Nextcloud-Anmeldung.
- Backup: rsync-Sicherung, Cron-Konfiguration, Logging und dateibasierter Restore-Test im Projektverlauf bearbeitet.
- Container: Nextcloud, Redis, MariaDB, Portainer, Chrony und Webserver in
docker psals laufend angezeigt. - Monitoring: AutoKuma erzeugte Monitore; Socket.IO antwortete; System-MariaDB-Heartbeats
status=1.
Abgrenzung und Transparenz
Die Bearbeitung aller Aufgaben ist vom Projektverantwortlichen bestätigt. Wo keine Originalausgabe vorliegt, wird kein individueller Testwert erfunden. Die Berichte unterscheiden diese Bestätigung von direkt sichtbaren Ergebnissen. Die Zuordnung erfolgt thematisch; sie ersetzt keine amtliche oder vom Bildungsträger bestätigte Aufgabenabnahme.
Nicht als nachgewiesene Implementierung dargestellt: öffentlich vertrauenswürdiges DuckDNS-/Let’s-Encrypt-Zertifikat, Nginx Proxy Manager, vollständiger Disaster-Recovery-Test, produktives SLA und durchgängige externe Alarmzustellung.
Dokumentationsübersicht
- 01 Linux-Administration und Shell
- 02 Git und versionierte Dokumentation
- 03 Linux-Management-Client und lokales IAM
- 04 Architektur und Virtualisierung
- 05 Edge-Zugriff und SSH-Portweiterleitung
- 06 DNS mit BIND9
- 07 DHCP mit Kea
- 08 SSH-Administration und Zugriffsschutz
- 09 TrueNAS und Windows Storage Spaces
- 10 iSCSI und Block-Storage
- 11 Automatisiertes Backup und Restore
- 12 Nextcloud auf Apache, PHP und MariaDB
- 13 TLS-Zertifikate und HTTPS
- 14 Docker Engine und eigenes Webserver-Image
- 15 Nextcloud-Stack mit MariaDB und Redis
- 16 Portainer als Containerverwaltung
- 17 Zeitdienst mit Chrony im Container
- 18 Mailserver, DNS und Clientanbindung
- 19 Zentrales Monitoring mit Uptime Kuma
- 20 Abnahme, Wiederanlauf und Betriebsübergabe
Für das technische Gespräch
Ich kann die Dienstabhängigkeiten erklären, den Zugriffspfad vom Client bis zum Container nachvollziehen und Fehler anhand von DNS, Ports, Logs und Heartbeats eingrenzen. Besonders anschauliche Fälle sind die falsche DNS-Serveradresse, die Host-Header-Auswahl in Apache und die Trennung von roter Historie und aktuellem Online-Status.