# Architektur & Infrastruktur

# Netzwerkarchitektur

# Gesamtübersicht

Die Infrastruktur „Hainbach 45“ basiert auf einer segmentierten Smart-Home- und Homelab-Architektur mit zentral verwalteter Netzwerk-, Container- und Diensteplattform.

Ziele der Architektur:

- Trennung kritischer Infrastruktur
- kontrollierte VLAN-Kommunikation
- zentrale DNS- und Reverse-Proxy-Architektur
- reproduzierbare Containerplattform
- mehrstufiges Backup- und Recovery-Konzept
- zentrale Monitoring- und Alerting-Plattform
- Reduktion von Single Points of Failure
- Vorbereitung auf professionelle Betriebs- und Sicherheitsstandards

Die Umgebung orientiert sich konzeptionell an etablierten Unternehmensprinzipien sowie ausgewählten Grundideen der NIS-2-Richtlinie.

[![Abb 1.png](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/scaled-1680-/abb-1.png)](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/abb-1.png)

## Zentrale Komponenten

### Netzwerk

- TP-Link Omada Infrastruktur
- VLAN-basierte Segmentierung
- getrennte WLANs für Produktiv-, IoT-, Gast- und Managementnetz
- zentrale ACL-Steuerung über Gateway-Firewallregeln

### Infrastrukturdienste

- AdGuard Home
- NGINX Proxy Manager
- Portainer
- ntfy
- Uptime Kuma

### Produktivdienste

- Nextcloud
- Vaultwarden
- Grafana
- InfluxDB
- BookStack

### Smart-Home-Plattform

- ioBroker
- Homematic IP / CCU3
- Shelly
- PV- und Energiemanagementsysteme

## Serverrollen

### App-Server

Zentrale Plattform für:
- Produktivdienste
- Containerplattform
- Monitoring
- Kollaboration
- Dokumentation

### Edge-Server

Zentrale Infrastrukturplattform für:
- DNS
- Reverse Proxy
- Infrastrukturzugriffe

### IoT-Server

Dedizierte Smart-Home- und Automatisierungsplattform.

## Architekturprinzipien

Die Umgebung basiert auf folgenden Grundprinzipien:

- Infrastrukturtrennung
- zentrale Verwaltung
- reproduzierbare Container
- hostbasierte Kernservices
- Split-DNS
- Reverse-Proxy-First-Prinzip
- systemd-first-Prinzip
- Backup aller persistenten Daten
- kontrollierte Updates

# Physische Topologie

Die physische Netzwerkstruktur von „Hainbach 45“ basiert auf einem zentralisierten Core-Design mit sternförmiger Verteilung aller relevanten Netzwerksegmente.

[![Hainbach 45_Netzwerktopologie (1).png](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/scaled-1680-/hainbach-45-netzwerktopologie-1.png)](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/hainbach-45-netzwerktopologie-1.png)
## Architekturprinzip

Die Infrastruktur wurde bewusst zentralisiert aufgebaut, um:

- VLAN-Management zu vereinfachen
- Access-Point-Verwaltung zu zentralisieren
- PoE-Versorgung zu bündeln
- strukturierte Segmentierung umzusetzen
- Fehleranalysen zu vereinfachen
- Infrastrukturkomponenten kontrolliert abzusichern

## Zentrale Netzwerkkomponenten

| Gerät | Modell | Funktion |
|---|---|---|
| Router | TP-Link ER605 v2.0 | Gateway / Routing / VLAN |
| Main Switch | TP-Link SG2210MP v4.20 | zentraler PoE-Core-Switch |
| Switch H45 | TP-Link SG3428 v2.30 | Haupt-LAN |
| Switch IoT | TP-Link SG3428 v2.30 | IoT-Netz |
| Switch ib-GES | TP-Link SG3210 v3.20 | zusätzliche Infrastruktur |
| Controller | TP-Link OC200 | zentrale Netzwerkverwaltung |

## Netzwerkdesign

Die Infrastruktur basiert auf folgenden Kernprinzipien:

- zentraler Routingpunkt
- VLAN-basierte Segmentierung
- Trennung von Infrastruktur-, Benutzer- und IoT-Netzen
- zentrale ACL-Steuerung
- dedizierte Infrastrukturserver
- Reverse-Proxy-First-Prinzip
- Split-DNS-Architektur

## Physische Struktur

Die Netzwerkverteilung erfolgt sternförmig vom zentralen Core-Switch aus.

Wichtige Bereiche:

- Produktivnetzwerk
- IoT-Netzwerk
- Managementnetz
- WLAN-Infrastruktur
- Serverplattform
- NAS-/Backup-Infrastruktur

## Management

Die zentrale Verwaltung erfolgt über:

- Omada Controller (OC200)
- zentrale Switch-Verwaltung
- zentrale Access-Point-Verwaltung
- zentrale WLAN-Konfiguration
- zentrale VLAN- und ACL-Konfiguration

## Infrastrukturserver

### App-Server

Zentrale Plattform für:

- Containerplattform
- Produktivdienste
- Monitoring
- Dokumentation
- Kollaborationsdienste

### Edge-Server

Dedizierter Infrastrukturserver für:

- AdGuard Home
- NGINX Proxy Manager
- DNS-Infrastruktur
- Reverse Proxy

### IoT-Server

Dedizierte Smart-Home-Plattform für:

- ioBroker
- zukünftige MQTT-Dienste
- Smart-Home-Integrationen

# Architekturprinzipien



# DHCP Strategie

# Server & Hosts

# Übersicht

# Server- & Hostsysteme
[![Gesamtarchitektur](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/scaled-1680-/abb-1.png)](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/abb-1.png)
Die Infrastruktur von Hainbach 45 basiert auf mehreren dedizierten Server- und Hostsystemen mit klar getrennten Aufgabenbereichen.

Die Trennung der Systeme dient:

- der Reduktion von Single Points of Failure
- der besseren Wartbarkeit
- der kontrollierten Segmentierung
- der sauberen Trennung von Infrastruktur- und Produktivdiensten
- der besseren Skalierbarkeit

---

## Architekturprinzipien

Die Serverlandschaft basiert auf folgenden Grundprinzipien:

- dedizierte Rollen pro System
- Containerisierung über Docker
- zentrale Verwaltung über Portainer
- Reverse-Proxy-First-Prinzip
- zentrale DNS-Infrastruktur
- hostbasierte Kernservices bei kritischen Funktionen
- systemd-basierte Betriebsservices
- kontrollierte Backupstrategie

---

## Übersicht der Systeme

| System | Rolle | Hauptaufgaben |
|---|---|---|
| App-Server | zentrale Produktivplattform | Containerdienste, Monitoring, Dokumentation |
| Edge-Server | Infrastrukturplattform | DNS, Reverse Proxy, Infrastrukturzugriffe |
| IoT-Server | Smart-Home-Plattform | ioBroker, Automatisierung |
| NAS-Systeme | Storage & Backup | Datenspeicherung, Replikation, Sicherung |

---

# App-Server

Der App-Server bildet die zentrale Produktivplattform der Umgebung.

## Hauptaufgaben

- Docker-Hosting
- Portainer
- Nextcloud
- Vaultwarden
- Grafana
- InfluxDB
- BookStack
- zentrale Infrastrukturservices

## Architektur

Der Server basiert auf:

- Docker
- Portainer
- zentralem Reverse Proxy
- persistenten Volumes
- zentraler Backupstrategie

## Besonderheiten

Der App-Server stellt einen zentralen Infrastrukturknoten dar.

Daher werden:

- Backups priorisiert
- Updates kontrolliert durchgeführt
- Dienste zentral überwacht

---

# Edge-Server

Der Edge-Server dient als dedizierte Infrastrukturplattform.

## Hauptaufgaben

- AdGuard Home
- NGINX Proxy Manager
- DNS-Infrastruktur
- Reverse Proxy
- Infrastrukturzugriffe
- externe Zugriffspfade

## Architekturprinzip

Der Edge-Server wurde bewusst von der Produktivplattform getrennt.

Dadurch bleiben:

- DNS
- Reverse Proxy
- Infrastrukturzugriffe

auch bei Problemen des App-Servers möglichst verfügbar.

## Besonderheiten

Der Server stellt einen kritischen Infrastrukturbaustein dar, da zentrale Netzwerkdienste von ihm abhängen.

---

# IoT-Server

Der IoT-Server bildet die dedizierte Smart-Home-Plattform.

## Hauptaufgaben

- ioBroker
- Homematic-Integration
- Smart-Home-Automatisierung
- zukünftige MQTT-Dienste
- OT-nahe Integrationen

## Architekturprinzip

Die Smart-Home-Plattform wurde bewusst von Produktiv- und Infrastrukturdiensten getrennt.

Vorteile:

- bessere Stabilität
- reduzierte Seiteneffekte
- einfachere Wartung
- klarere Segmentierung

---

# NAS-Infrastruktur

Die NAS-Systeme dienen:

- zentraler Datenspeicherung
- Backup
- Replikation
- Langzeitarchivierung

## Verwendete Systeme

- QNAP
- Synology

## Architekturprinzipien

Die Backupstrategie basiert auf mehreren Ebenen:

- Primärbackup
- Replikation
- externe Sicherung
- Offline-/Langzeitkonzepte

---

# Containerplattform

Die zentrale Containerverwaltung erfolgt über:

- Docker
- Portainer

Containerisierung wird verwendet für:

- bessere Wartbarkeit
- Reproduzierbarkeit
- vereinfachte Updates
- klare Service-Trennung

---

# Infrastrukturprinzipien

Die Infrastruktur orientiert sich an folgenden Grundprinzipien:

- zentrale Verwaltung
- kontrollierte Segmentierung
- reproduzierbare Systeme
- dokumentierte Architektur
- Backup aller persistenten Daten
- minimierte Angriffsflächen
- klare Rollenverteilung

# App-Server



# Edge-Server



# IoT-Server



# Rollen & Verantwortlichkeiten

# VLANs & WLAN

# VLAN Übersicht

[![ChatGPT Image 22. Mai 2026, 17_36_38.png](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/scaled-1680-/chatgpt-image-22-mai-2026-17-36-38.png)](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/chatgpt-image-22-mai-2026-17-36-38.png)

Die Infrastruktur „Hainbach 45“ basiert auf einer konsequent segmentierten VLAN-Architektur.

Ziel der Segmentierung ist:

- Trennung kritischer Systeme
- Reduktion lateraler Bewegungen
- kontrollierte Netzwerkkommunikation
- Isolation unsicherer IoT-Geräte
- vereinfachte Firewallsteuerung
- bessere Fehleranalyse
- strukturierter Infrastrukturaufbau

## Architekturprinzip

Die Netzwerksegmentierung orientiert sich an folgenden Grundprinzipien:

- Infrastrukturtrennung
- Least-Privilege-Kommunikation
- zentrale ACL-Steuerung
- kontrollierter Zugriff auf Managementsysteme
- Trennung von Benutzer-, Infrastruktur- und IoT-Netzen

## VLAN-Übersicht

| VLAN | Bezeichnung | Netzwerk | Zweck |
|---|---|---|---|
| 1 | Management | 10.45.1.0/24 | Switches, APs, Infrastrukturmanagement |
| 10 | H45 LAN | 10.45.10.0/24 | Produktivnetzwerk |
| 81 | IoT LAN | 10.45.81.0/24 | Smart-Home- und IoT-Geräte |
| 99 | Gastnetz | getrennt | isoliertes Gastnetzwerk |

## VLAN 1 – Management

Das Managementnetz dient ausschließlich der Verwaltung der Netzwerkinfrastruktur.

Enthaltene Systeme:

- Omada Controller
- Switches
- Access Points
- Managementschnittstellen

Der Zugriff erfolgt ausschließlich kontrolliert über definierte Firewallregeln.

## VLAN 10 – H45 LAN

Das Hauptnetzwerk beinhaltet:

- Serverplattform
- NAS-Systeme
- Arbeitsgeräte
- Infrastrukturserver
- zentrale Dienste

Dieses Netzwerk bildet das zentrale Produktivsegment der Umgebung.

## VLAN 81 – IoT LAN

Das IoT-Netzwerk enthält:

- Smart-Home-Geräte
- IoT-Komponenten
- nicht vertrauenswürdige Endgeräte
- Automatisierungskomponenten

Die Kommunikation erfolgt kontrolliert über ACL-Regeln.

Direkte Zugriffe auf Managementsysteme werden grundsätzlich unterbunden.

## Gastnetz

Das Gastnetz ist vollständig vom Produktivnetz getrennt.

Eigenschaften:

- ausschließlich Internetzugriff
- keine interne Kommunikation
- keine Erreichbarkeit von Infrastrukturkomponenten

## Kommunikationsprinzip

Die Kommunikation zwischen VLANs erfolgt ausschließlich kontrolliert über:

- Gateway-Firewallregeln
- ACLs
- definierte Freigaben
- Reverse-Proxy-Zugriffe

Grundsätzlich gilt:

- deny-by-default
- explizite Freigaben
- minimale Berechtigungen

## Sicherheitsprinzipien

Die VLAN-Architektur dient insbesondere:

- der Reduktion von Angriffsflächen
- der Segmentierung unsicherer Geräte
- der Trennung kritischer Dienste
- der besseren Überwachung
- der vereinfachten Fehleranalyse

Die Umgebung orientiert sich konzeptionell an professionellen Netzwerksegmentierungsprinzipien.

# WLAN Struktur

Die WLAN-Infrastruktur von Hainbach 45 basiert auf einer zentral verwalteten Omada-Architektur mit VLAN-basierter Segmentierung.

Ziele:

- Trennung unterschiedlicher Sicherheitszonen
- zentrale Verwaltung
- kontrollierte Netzwerksegmentierung
- optimierte WLAN-Abdeckung
- Unterstützung moderner WLAN-Standards
- sichere Einbindung von IoT-Geräten

---

## Verwendete SSIDs

| SSID | VLAN | Zweck | Frequenz |
|---|---|---|---|
| H45 | VLAN 10 | Haupt-WLAN / Produktivnetz | 2.4 / 5 / 6 GHz |
| H45-IoT | VLAN 81 | Smart-Home- und IoT-Geräte | 2.4 GHz |
| H45-Gast | VLAN 50 | Gastzugriff | 2.4 GHz |
| H45-Mgmt | VLAN 1 | Infrastrukturverwaltung | 5 GHz |

---

## Architekturprinzipien

Die WLAN-Architektur basiert auf folgenden Grundprinzipien:

- getrennte SSIDs pro Sicherheitszone
- VLAN-basierte Netztrennung
- zentrales WLAN-Management
- isoliertes Gastnetz
- getrennte IoT-Kommunikation
- dediziertes Management-WLAN
- kontrollierte Ost-West-Kommunikation

---

## Haupt-WLAN „H45“

Das Haupt-WLAN dient dem Zugriff auf:

- Server
- NAS-Systeme
- Arbeitsplatzgeräte
- Administratorgeräte
- Infrastrukturservices

Eigenschaften:

- VLAN 10
- primäres Produktivnetz
- Zugriff auf interne Dienste
- moderne WLAN-Standards
- Multi-Band-Betrieb

---

## IoT-WLAN „H45-IoT“

Das IoT-WLAN dient ausschließlich Smart-Home- und IoT-Geräten.

Enthaltene Geräte:

- Shelly
- PV-Systeme
- Sensorik
- Verbrauchersteuerungen
- Smart-Home-Komponenten

Eigenschaften:

- VLAN 81
- ausschließlich 2.4 GHz
- getrennt vom Hauptnetz
- eingeschränkte Kommunikationspfade

Die Segmentierung reduziert potenzielle Sicherheitsrisiken unsicherer IoT-Geräte.

---

## Gast-WLAN „H45-Gast“

Das Gastnetz dient Besuchern ausschließlich für Internetzugriffe.

Eigenschaften:

- vollständige Isolation vom internen Netzwerk
- kein Zugriff auf Infrastruktur oder Server
- separates VLAN
- getrennte SSID

---

## Management-WLAN „H45-Mgmt“

Das Management-WLAN dient ausschließlich administrativen Zugriffen.

Zwecke:

- Infrastrukturverwaltung
- Omada-Management
- Wartung
- Fehlersuche

Eigenschaften:

- VLAN 1
- ausschließlich für Administratorgeräte
- eingeschränkte Nutzung
- erhöhte Sicherheitsanforderungen

---

## Access-Point-Infrastruktur

Die WLAN-Abdeckung erfolgt zentral über mehrere TP-Link Omada Access Points.

Standorte:

| Access Point | Standort |
|---|---|
| AP-EG Garage | Garage |
| AP-EG Küche | Erdgeschoss |
| AP-KG Flur | Keller |
| AP-KG Werkstatt | Werkstatt |
| AP-OG Flur | Obergeschoss |

Die Verwaltung erfolgt zentral über den Omada Controller.

---

## Sicherheitsprinzipien

Die WLAN-Infrastruktur orientiert sich an folgenden Sicherheitsprinzipien:

- VLAN-Segmentierung
- getrennte Sicherheitszonen
- zentrale ACL-Steuerung
- minimierte Kommunikationspfade
- dedizierte Verwaltungszugänge
- Isolation unsicherer Geräte

---

## Besonderheiten

Das Haupt-WLAN nutzt moderne WLAN-Standards inklusive Multi-Link Operation (MLO).

Zusätzlich wurde bewusst eine getrennte IoT-Infrastruktur umgesetzt, um:

- Broadcast-Domänen zu reduzieren
- Risiken durch IoT-Geräte zu minimieren
- Fehlersuche zu vereinfachen
- Stabilität des Produktivnetzes zu erhöhen

# IoT Segmentierung



# Gastnetz

# Firewall

# DNS

# Übersicht

[![ChatGPT Image 22. Mai 2026, 18_14_21.png](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/scaled-1680-/chatgpt-image-22-mai-2026-18-14-21.png)](https://wiki.schwarzi.at/uploads/images/gallery/2026-05/chatgpt-image-22-mai-2026-18-14-21.png)
Die DNS-Infrastruktur bildet eine zentrale Grundlage der gesamten H45-Umgebung.

Nahezu alle Dienste hängen direkt oder indirekt von funktionierender Namensauflösung ab.

Die Architektur basiert auf:

- AdGuard Home
- DNS-Rewrites
- Split-DNS
- zentralem Reverse Proxy
- internen Hostnamen
- vereinheitlichten HTTPS-Zugriffen

---

# Zielsetzung

Ziele der DNS-Architektur:

- zentrale Namensauflösung
- interne Hostnamen statt IP-Adressen
- konsistente interne/externe URLs
- Vorbereitung auf Reverse-Proxy-Architektur
- vereinfachte Zertifikatsverwaltung
- minimierte Direktzugriffe auf Systeme
- bessere Wartbarkeit
- einfachere Migration von Diensten

---

# Architekturprinzipien

Die DNS-Infrastruktur basiert auf folgenden Grundprinzipien:

- zentrale DNS-Verwaltung
- Reverse-Proxy-first-Prinzip
- Split-DNS
- kontrollierte interne Hostnamen
- minimierte Direktzugriffe
- konsistente Dienstnamen
- zentrale Zugriffskontrolle

---

# Zentrale Komponenten

| Komponente | Funktion |
|---|---|
| AdGuard Home | DNS-Server / lokale DNS-Auflösung |
| DNS-Rewrites | interne Zielumleitungen |
| Split-DNS | interne/externe URL-Vereinheitlichung |
| NGINX Proxy Manager | zentrale HTTPS-Terminierung |

---

# Grundprinzip

Benutzer greifen grundsätzlich nicht direkt auf:

- Containerports
- interne Zielsysteme
- lokale IP-Adressen

zu.

Stattdessen erfolgt der Zugriff über:

- DNS-Namen
- HTTPS
- Reverse Proxy

---

# Typische Hostnamen

| Hostname | Funktion |
|---|---|
| portainer.home | Containerverwaltung |
| grafana.home | Monitoring |
| proxy.home | Reverse Proxy |
| adguard.home | DNS-Verwaltung |
| iobroker.home | Smart-Home |
| qnap.home | NAS |
| synology.home | Synology |

---

# Split-DNS

Die Umgebung verwendet Split-DNS.

Dadurch funktionieren identische URLs:

- intern
- extern
- über VPN

ohne unterschiedliche Hostnamen verwenden zu müssen.

---

# Sicherheitsprinzipien

Die DNS-Infrastruktur dient insbesondere:

- der zentralen Zugriffskontrolle
- der Reduktion direkter Systemzugriffe
- der Vereinheitlichung von HTTPS-Zugriffen
- der einfacheren Verwaltung
- der Vorbereitung auf professionelle Infrastrukturstandards

---

# Kritikalität

Die DNS-Infrastruktur stellt einen kritischen Infrastrukturbaustein dar.

Ein Ausfall führt typischerweise zu:

- Problemen bei interner Namensauflösung
- eingeschränkten Servicezugriffen
- Problemen beim Reverse Proxy
- Störungen interner Plattformdienste

---

# Zugehörige Seiten

- AdGuard Home
- Split-DNS
- DNS-Rewrites
- Namenskonventionen

# AdGuard Home

AdGuard Home dient als zentraler DNS-Server der H45-Infrastruktur.

Der Dienst übernimmt:

- DNS-Auflösung
- lokale Hostnamen
- DNS-Rewrites
- Split-DNS
- Werbe- und Trackingfilterung
- zentrale DNS-Verwaltung

---

# Architekturrolle

AdGuard Home bildet einen kritischen Infrastrukturbaustein.

Nahezu alle internen Dienste hängen direkt oder indirekt von funktionierender DNS-Auflösung ab.

Der Dienst läuft auf dem:

| System | Funktion |
|---|---|
| Edge-Server | DNS-Infrastruktur |

---

# Hauptaufgaben

## Lokale DNS-Auflösung

Interne Dienste werden über Hostnamen statt IP-Adressen erreicht.

Beispiele:

| Hostname | Ziel |
|---|---|
| portainer.home | Portainer |
| grafana.home | Grafana |
| iobroker.home | ioBroker |
| proxy.home | NGINX Proxy Manager |
| adguard.home | AdGuard Home |

---

## DNS-Rewrites

AdGuard verwendet DNS-Rewrites zur internen Auflösung von Diensten.

Dadurch können:

- interne Dienste
- Reverse-Proxy-Ziele
- öffentliche Domains intern umgeleitet werden

---

## Split-DNS

Die Infrastruktur verwendet Split-DNS.

Dadurch funktionieren identische URLs:

- intern
- extern
- via VPN

Intern werden die Domains direkt auf interne Systeme aufgelöst.

---

# Upstream-DNS

AdGuard Home verwendet externe DNS-Resolver für nicht lokale Anfragen.

Beispiele:

- Quad9
- Cloudflare
- Google DNS

Die Auswahl kann je nach Datenschutz- und Verfügbarkeitsanforderungen angepasst werden.

---

# DHCP-Integration

Die Clients erhalten den DNS-Server automatisch über DHCP.

Die Verteilung erfolgt zentral über:

- Omada Controller
- VLAN-spezifische DHCP-Konfiguration

---

# Sicherheitsprinzipien

Die DNS-Infrastruktur folgt folgenden Grundprinzipien:

- zentrale Namensauflösung
- minimierte Direktzugriffe
- kontrollierte interne Hostnamen
- Trennung interner/externer Infrastruktur
- vereinfachte Zertifikatsverwaltung

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- interne Hostnamen
- Reverse-Proxy-first-Prinzip
- zentrale DNS-Rewrites
- Split-DNS

Dadurch bleiben:

- URLs konsistent
- Dienste leichter migrierbar
- Zertifikate einfacher verwaltbar

---

# Kritikalität

AdGuard Home stellt einen kritischen Infrastrukturservice dar.

Ein Ausfall führt typischerweise zu:

- Problemen bei interner Namensauflösung
- eingeschränkter Erreichbarkeit interner Dienste
- Problemen bei Reverse-Proxy-Zugriffen
- Ausfällen interner Service-URLs

# Split-DNS

Die Infrastruktur von Hainbach 45 verwendet Split-DNS zur Vereinheitlichung interner und externer Dienstzugriffe.

Dadurch funktionieren dieselben URLs:

- intern im LAN
- extern über das Internet
- über VPN

---

# Zielsetzung

Ziele der Split-DNS-Architektur:

- identische interne/externe URLs
- Vermeidung von Hairpin NAT
- vereinfachte Zertifikatsverwaltung
- konsistente Benutzererfahrung
- zentrale Reverse-Proxy-Architektur
- einfachere Migration von Diensten

---

# Grundprinzip

Die DNS-Antwort hängt vom Standort des Clients ab.

## Intern

Interne Clients erhalten:

```text id="3w4r5v"
wiki.schwarzi.at → 10.45.10.8

# DNS-Rewrites

## Zweck

AdGuard Home dient als zentraler interner DNS-Resolver innerhalb der Infrastruktur Hainbach 45.

Mittels DNS-Rewrites werden interne Hostnamen zentral auf den Reverse Proxy (`10.45.10.8`) geleitet.

Dadurch entstehen folgende Vorteile:

- einheitliche interne URLs
- einfache Serviceerreichbarkeit
- zentrale HTTPS-Terminierung
- Vorbereitung für Split-DNS
- keine direkten Containerports notwendig
- bessere Wartbarkeit

---

## Grundprinzip

Die interne DNS-Auflösung erfolgt bewusst nicht direkt auf Zielserver oder Container.

Stattdessen erfolgt die Kommunikation über:

```text
Client
→ AdGuard DNS
→ Reverse Proxy (NGINX Proxy Manager)
→ Zielservice
```

Dadurch bleiben:

- Containerports verborgen
- HTTPS zentral verwaltbar
- Zertifikate konsistent
- Dienste einfacher migrierbar

---

# Aktuelle DNS-Rewrites

## Infrastruktur & Verwaltung

| Hostname | Ziel |
|---|---|
| `portainer.home` | `10.45.10.8` |
| `grafana.home` | `10.45.10.8` |
| `adguard.home` | `10.45.10.8` |
| `proxy.home` | `10.45.10.8` |
| `influx.home` | `10.45.10.8` |
| `uptime.home` | `10.45.10.8` |
| `wiki.home` | `10.45.10.8` |

---

## Smart Home & OT

| Hostname | Ziel |
|---|---|
| `iobroker.home` | `10.45.10.8` |
| `ccu3.home` | `10.45.10.8` |
| `hmi.home` | `10.45.10.8` |

---

## Storage & Plattformdienste

| Hostname | Ziel |
|---|---|
| `nextcloud.home` | `10.45.10.8` |
| `synology.home` | `10.45.10.8` |
| `qnap.home` | `10.45.10.8` |

---

## Netzwerk & Remotezugriff

| Hostname | Ziel |
|---|---|
| `wireguard.home` | `10.45.10.8` |

---

# Architekturentscheidung

Es werden bewusst keine direkten Containerports produktiv verwendet.

Stattdessen erfolgt der Zugriff standardisiert über:

```text
DNS-Rewrite
→ Reverse Proxy
→ Zielcontainer
```

Dies verbessert:

- Sicherheit
- Wartbarkeit
- Migrationsfähigkeit
- Zertifikatsverwaltung
- Benutzerfreundlichkeit

---

# Besonderheiten

Alle Hostnamen zeigen bewusst auf denselben zentralen Infrastrukturknoten:

```text
10.45.10.8
```

Dort erfolgt die eigentliche Dienstweiterleitung über:

- NGINX Proxy Manager
- virtuelle Hosts
- HTTPS-Terminierung
- interne Routingregeln

# Namenskonventionen

## Zweck

Die Infrastruktur von Hainbach 45 verwendet standardisierte Namenskonventionen zur besseren Übersichtlichkeit, Wartbarkeit und Skalierbarkeit.

Ziele:

- konsistente Hostnamen
- einfachere Administration
- bessere Lesbarkeit
- vereinfachtes Troubleshooting
- klare Infrastrukturtrennung
- nachvollziehbare Servicezuordnung

---

# Grundprinzipien

Die Namensgebung erfolgt nach folgenden Regeln:

- kurze und eindeutige Namen
- sprechende Hostnamen
- konsistente Schreibweise
- Kleinbuchstaben
- keine Sonderzeichen
- keine Leerzeichen
- thematische Gruppierung

---

# Interne Domains

Die interne Infrastruktur verwendet aktuell primär:

```text
.home
```

Beispiele:

```text
portainer.home
grafana.home
iobroker.home
wiki.home
```

---

# Öffentliche Domains

Extern erreichbare Dienste verwenden:

```text
schwarzi.at
```

Beispiele:

```text
wiki.schwarzi.at
vault.schwarzi.at
nxt.schwarzi.at
```

---

# Infrastruktur-Hostnamen

## Infrastruktur & Verwaltung

| Hostname | Funktion |
|---|---|
| `proxy.home` | Reverse Proxy |
| `adguard.home` | DNS-Server |
| `portainer.home` | Containerverwaltung |
| `grafana.home` | Monitoring |
| `influx.home` | Zeitreihendatenbank |
| `uptime.home` | Monitoring |

---

## Smart Home & OT

| Hostname | Funktion |
|---|---|
| `iobroker.home` | Smart-Home-Plattform |
| `ccu3.home` | Homematic-Zentrale |
| `hmi.home` | Bedienoberflächen |

---

## Storage & Plattformdienste

| Hostname | Funktion |
|---|---|
| `nextcloud.home` | Fileservice |
| `synology.home` | Synology NAS |
| `qnap.home` | QNAP NAS |
| `wiki.home` | Infrastruktur-Wiki |

---

## Netzwerk & Remotezugriff

| Hostname | Funktion |
|---|---|
| `wireguard.home` | VPN-Zugriff |

---

# Servernamen

Die physischen bzw. virtuellen Systeme verwenden sprechende Rollennamen.

| Servername | Funktion |
|---|---|
| `App-Server` | zentrale Produktivplattform |
| `Edge-Server` | Infrastrukturplattform |
| `IoT-Server` | Smart-Home-Plattform |

---

# Architekturprinzip

Die Namensgebung orientiert sich bewusst an:

- Rollen
- Funktionen
- Dienstarten
- Infrastruktursegmenten

Dadurch bleiben:

- Systeme leichter identifizierbar
- Dienste einfacher migrierbar
- Dokumentationen konsistent
- DNS-Strukturen übersichtlich

---

# Besonderheiten

Die Infrastruktur verwendet bewusst:

- interne Kurzdomains
- Reverse-Proxy-first-Prinzip
- DNS-Rewrites
- Split-DNS

Dadurch funktionieren interne und externe Zugriffe möglichst konsistent.

---

# Zukünftige Erweiterungen

Neue Dienste sollen:

- in bestehende Namensschemata passen
- konsistent benannt werden
- möglichst sprechende Namen verwenden
- direkt über Reverse Proxy erreichbar sein

# Reverse Proxy

# Übersicht

Die Reverse-Proxy-Infrastruktur bildet die zentrale Zugriffsschicht der H45-Umgebung.

Nahezu alle webbasierten Dienste werden nicht direkt, sondern über den zentralen Reverse Proxy veröffentlicht.

Die Architektur basiert auf:

- NGINX Proxy Manager
- zentraler HTTPS-Terminierung
- DNS-Rewrites
- Split-DNS
- internen und externen Domains
- zentralem Routing

---

# Zielsetzung

Ziele der Reverse-Proxy-Architektur:

- zentrale HTTPS-Verwaltung
- keine direkten Containerports
- konsistente URLs
- vereinfachte Zertifikatsverwaltung
- bessere Wartbarkeit
- vereinfachte Migration von Diensten
- zentrale Zugriffskontrolle

---

# Architekturprinzip

Zugriffe erfolgen grundsätzlich nicht direkt auf:

- Containerports
- interne Serviceports
- Zielsysteme

Stattdessen:

```text
Client
→ DNS
→ Reverse Proxy
→ Zielservice
```

Der Reverse Proxy übernimmt anschließend:

- HTTPS-Terminierung
- Hostname-Routing
- Weiterleitung
- Zertifikatsverwaltung

---

# Zentrale Komponente

| Komponente | Funktion |
|---|---|
| NGINX Proxy Manager | zentraler Reverse Proxy |

---

# Infrastrukturrolle

Der Reverse Proxy dient als zentrale Einstiegsschicht für:

- interne Dienste
- externe Dienste
- VPN-Zugriffe
- HTTPS
- Split-DNS

---

# Vorteile

## Zentrale HTTPS-Verwaltung

Zertifikate werden zentral verwaltet.

Dadurch entfällt HTTPS-Konfiguration auf einzelnen Diensten.

---

## Konsistente URLs

Interne und externe Zugriffe verwenden möglichst identische Hostnamen.

Beispiele:

```text
wiki.schwarzi.at
vault.schwarzi.at
nxt.schwarzi.at
```

---

## Keine direkten Containerports

Containerports werden möglichst nicht produktiv veröffentlicht.

Der Zugriff erfolgt standardisiert über:

```text
DNS
→ Reverse Proxy
→ Zielcontainer
```

---

# Abhängigkeiten

Die Reverse-Proxy-Infrastruktur hängt direkt ab von:

- DNS
- AdGuard Home
- Split-DNS
- funktionierenden Zielcontainern
- interner Netzwerkkonnektivität

---

# Sicherheitsprinzipien

Die Architektur folgt folgenden Grundprinzipien:

- zentrale Zugriffskontrolle
- minimierte Direktzugriffe
- zentrale HTTPS-Terminierung
- konsistente Hostnamen
- kontrollierte Veröffentlichung von Diensten

---

# Zugehörige Seiten

- NGINX Proxy Manager
- Proxy Hosts
- HTTPS / Zertifikate
- Externe Domains
- Interne Domains

# Nginx Proxy Manager

## Zweck

NGINX Proxy Manager (NPM) dient als zentraler Reverse Proxy der H45-Infrastruktur.

Der Dienst übernimmt:

- HTTPS-Terminierung
- Hostname-basiertes Routing
- Reverse Proxy
- interne/externe Dienstveröffentlichung
- Zertifikatsverwaltung
- Zugriffskontrolle

---

# Infrastrukturrolle

Der Reverse Proxy bildet die zentrale Zugriffsschicht für nahezu alle webbasierten Dienste.

Zugriffe erfolgen grundsätzlich nicht direkt auf:

- Containerports
- interne Zielsysteme
- lokale Serviceports

Stattdessen:

```text
Client
→ DNS
→ NGINX Proxy Manager
→ Zielservice
```

---

# Architekturprinzipien

Die Reverse-Proxy-Architektur folgt folgenden Grundprinzipien:

- zentrale HTTPS-Verwaltung
- keine direkten Containerports
- zentrale Zugriffskontrolle
- konsistente Hostnamen
- vereinfachte Migration von Diensten
- Split-DNS-Kompatibilität

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| Edge-Server | Reverse Proxy / HTTPS-Gateway |

---

# Proxy-Host-Struktur

Die Umgebung unterscheidet grundsätzlich zwischen:

## Internen Diensten

Nur intern erreichbar:

- `portainer.home`
- `grafana.home`
- `proxy.home`
- `adguard.home`
- `uptime.home`
- `wireguard.home`

---

## Öffentlichen Diensten

Extern erreichbar über HTTPS:

- `wiki.schwarzi.at`
- `vault.schwarzi.at`
- `nxt.schwarzi.at`
- `ntfy.schwarzi.at`
- `qnap.schwarzi.at`
- `syn.schwarzi.at`

---

# Interne Proxy Hosts

## Infrastruktur & Verwaltung

| Domain | Ziel |
|---|---|
| `adguard.home` | `http://10.45.10.8:3001` |
| `grafana.home` | `http://10.45.10.10:3000` |
| `influx.home` | `http://10.45.10.10:8086` |
| `portainer.home` | `https://10.45.10.10:9443` |
| `proxy.home` | `http://10.45.10.8:81` |
| `uptime.home` | `http://10.45.10.10:3003` |
| `wiki.home` | `http://10.45.10.10:3006` |

---

## Smart Home & OT

| Domain | Ziel |
|---|---|
| `iobroker.home` | `http://10.45.10.15:8081` |
| `hmi.home` | `http://10.45.10.15:8082` |
| `ccu3.home` | `http://10.45.81.15:80` |

---

## Netzwerk & Remotezugriff

| Domain | Ziel |
|---|---|
| `wireguard.home` | `http://10.45.10.8:51821` |

---

# Öffentliche Proxy Hosts

| Domain | Ziel |
|---|---|
| `wiki.schwarzi.at` | `http://10.45.10.10:3006` |
| `vault.schwarzi.at` | `http://10.45.10.10:8090` |
| `nxt.schwarzi.at` | `http://10.45.10.10:8080` |
| `ntfy.schwarzi.at` | `http://10.45.10.10:2586` |
| `qnap.schwarzi.at` | `https://10.45.10.52:443` |
| `syn.schwarzi.at` | `https://10.45.10.51:5845` |
| `geo.schwarzi.at` | `http://10.45.10.15:7999` |

---

# SSL-Strategie

Die Infrastruktur verwendet:

- interne HTTP-Hosts
- öffentliche HTTPS-Hosts
- zentrale Zertifikatsverwaltung

Öffentliche Dienste verwenden Let's Encrypt-Zertifikate direkt über NGINX Proxy Manager.

---

# Zugriffslisten

Die Umgebung verwendet Zugriffskontrolllisten zur Trennung von:

- internen Diensten
- öffentlichen Diensten
- geschützten Diensten

Aktuell vorhanden:

| Zugriffsliste | Zweck |
|---|---|
| `Intern` | ausschließlich interne Zugriffe |
| `Public + Credentials` | öffentliche Dienste mit Authentifizierung |

---

# Sicherheitsprinzipien

Die Reverse-Proxy-Architektur dient insbesondere:

- der zentralen Zugriffskontrolle
- der Reduktion direkter Systemzugriffe
- der zentralen HTTPS-Terminierung
- der konsistenten Dienstveröffentlichung
- der Vorbereitung auf professionelle Infrastrukturstandards

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- Split-DNS
- Reverse-Proxy-first-Prinzip
- DNS-Rewrites
- zentrale HTTPS-Terminierung
- konsistente interne/externe Domains

Dadurch bleiben:

- URLs konsistent
- Dienste leichter migrierbar
- Zertifikate zentral verwaltbar
- Zugriffe besser kontrollierbar

---

# Dokumentation

## Proxy Hosts

> Hier Screenshots der Proxy-Host-Konfiguration einfügen

## Zugriffslisten

> Hier Screenshot der Zugriffsliste einfügen

# HTTPS / Zertifikate

## Zweck

Die Infrastruktur von Hainbach 45 verwendet HTTPS zur verschlüsselten Kommunikation zwischen Clients und Diensten.

Die HTTPS-Verwaltung erfolgt zentral über:

```text
NGINX Proxy Manager
```

Dadurch müssen Zertifikate nicht auf einzelnen Diensten verwaltet werden.

---

# Architekturprinzip

HTTPS wird bewusst zentral terminiert.

Die Kommunikation erfolgt grundsätzlich:

```text
Client
→ HTTPS
→ Reverse Proxy
→ Zielservice
```

Die eigentlichen Zielservices laufen intern überwiegend weiterhin über HTTP.

---

# Vorteile der zentralen HTTPS-Terminierung

## Vereinfachte Zertifikatsverwaltung

Zertifikate werden ausschließlich zentral verwaltet.

Dadurch entfällt:

- Zertifikatsmanagement auf Einzelcontainern
- manuelle Zertifikatsverteilung
- komplexe Einzelkonfiguration

---

## Konsistente URLs

Alle Dienste verwenden standardisierte Domains.

Beispiele:

```text
wiki.schwarzi.at
vault.schwarzi.at
nxt.schwarzi.at
```

---

## Vereinfachte Migrationen

Da Zertifikate zentral verwaltet werden:

- können Dienste leichter verschoben werden
- bleiben URLs unverändert
- müssen Clients nicht angepasst werden

---

# Öffentliche HTTPS-Dienste

Folgende Dienste verwenden aktuell öffentliche HTTPS-Zertifikate:

| Domain | Dienst |
|---|---|
| `wiki.schwarzi.at` | Wiki / Dokumentation |
| `vault.schwarzi.at` | Vaultwarden |
| `nxt.schwarzi.at` | Nextcloud |
| `ntfy.schwarzi.at` | Benachrichtigungssystem |
| `qnap.schwarzi.at` | QNAP NAS |
| `syn.schwarzi.at` | Synology NAS |
| `geo.schwarzi.at` | Geo-/Map-Dienst |

---

# Zertifikatsquelle

Die öffentlichen Zertifikate werden automatisch über:

```text
Let's Encrypt
```

bezogen und verwaltet.

Die Verwaltung erfolgt direkt im:

```text
NGINX Proxy Manager
```

---

# Interne Dienste

Interne Dienste verwenden aktuell überwiegend:

- HTTP
- interne DNS-Rewrites
- interne VLAN-Kommunikation

Beispiele:

| Dienst | Zugriff |
|---|---|
| `portainer.home` | HTTP intern |
| `grafana.home` | HTTP intern |
| `proxy.home` | HTTP intern |
| `adguard.home` | HTTP intern |

---

# Split-DNS

Die Infrastruktur verwendet Split-DNS.

Dadurch funktionieren identische Domains:

- intern
- extern
- über VPN

ohne unterschiedliche URLs verwenden zu müssen.

---

# Sicherheitsprinzipien

Die HTTPS-Architektur dient insbesondere:

- verschlüsselter Kommunikation
- zentraler Zugriffskontrolle
- konsistenter Zertifikatsverwaltung
- Reduktion direkter Servicezugriffe
- vereinfachter Wartung

---

# Architekturentscheidung

Die Umgebung verwendet bewusst:

- Reverse-Proxy-first-Prinzip
- zentrale HTTPS-Terminierung
- Split-DNS
- DNS-Rewrites
- minimierte Direktzugriffe

Dadurch bleibt die Infrastruktur:

- konsistent
- wartbar
- skalierbar
- migrationsfähig

---

# Besonderheiten

Die Zielsysteme selbst benötigen meist keine öffentlichen Zertifikate mehr.

Die eigentliche HTTPS-Kommunikation endet bereits am Reverse Proxy.

Dadurch wird die interne Infrastruktur erheblich vereinfacht.

---

# Dokumentation

## Öffentliche Proxy Hosts

> Hier Screenshot der öffentlichen HTTPS-Proxy-Hosts einfügen

## Let's Encrypt / SSL-Konfiguration

> Optional Screenshot der SSL-Konfiguration einfügen

# Docker

# Übersicht

Die Infrastruktur von Hainbach 45 basiert zentral auf Docker-Containern.

Nahezu alle Plattformdienste laufen containerisiert.

Die Containerisierung dient insbesondere:

- standardisierten Deployments
- einfacheren Migrationen
- besserer Wartbarkeit
- isolierten Diensten
- vereinfachten Updates
- reproduzierbaren Konfigurationen

---

# Architekturprinzip

Die Umgebung verwendet bewusst:

- Docker
- Docker Compose
- Portainer
- zentrale Reverse-Proxy-Struktur
- persistente Volumes
- serviceorientierte Trennung

---

# Zentrale Verwaltungsplattform

Die Verwaltung erfolgt primär über:

```text
Portainer
```

Portainer dient zur:

- Stack-Verwaltung
- Containerverwaltung
- Log-Analyse
- Neustarts
- Updateverwaltung
- Compose-Deployment

---

# Infrastrukturprinzipien

Die Containerarchitektur folgt folgenden Grundprinzipien:

- ein Dienst pro Container
- Trennung von Daten und Anwendung
- persistente Volumes
- zentrale Proxy-Integration
- DNS-/Reverse-Proxy-first-Prinzip
- möglichst keine direkten Containerports

---

# Hauptplattformen

| System | Funktion |
|---|---|
| App-Server | zentrale Produktivplattform |
| Edge-Server | Infrastrukturplattform |
| IoT-Server | Smart-Home-Plattform |

---

# Wichtige Containerdienste

## Infrastruktur

| Dienst | Funktion |
|---|---|
| NGINX Proxy Manager | Reverse Proxy |
| AdGuard Home | DNS |
| Portainer | Containerverwaltung |
| Uptime Kuma | Monitoring |
| ntfy | Benachrichtigungen |

---

## Plattformdienste

| Dienst | Funktion |
|---|---|
| Nextcloud | Fileservice |
| Vaultwarden | Passwortverwaltung |
| BookStack | Dokumentation |

---

## Monitoring

| Dienst | Funktion |
|---|---|
| Grafana | Dashboards |
| InfluxDB | Zeitreihendatenbank |

---

## Smart Home & OT

| Dienst | Funktion |
|---|---|
| ioBroker | Smart-Home-Plattform |
| WireGuard | VPN |

---

# Datenhaltung

Containerdaten werden persistent gespeichert.

Typische Speicherorte:

```text
/srv/docker/
```

Beispiele:

```text
/srv/docker/nginx-proxy-manager
/srv/docker/adguard
/srv/docker/bookstack
```

---

# Reverse-Proxy-Integration

Nahezu alle Containerdienste werden veröffentlicht über:

```text
DNS
→ Reverse Proxy
→ Zielcontainer
```

Direkte Containerports werden möglichst vermieden.

---

# Sicherheitsprinzipien

Die Containerarchitektur dient insbesondere:

- Diensttrennung
- einfacheren Backups
- kontrollierten Veröffentlichungen
- vereinfachten Migrationen
- reproduzierbaren Deployments

---

# Backup-Strategie

Containerdaten werden zentral gesichert mittels:

```text
Restic
```

Die Sicherung erfolgt auf:

- QNAP NAS
- Replikation auf Synology
- zusätzliche externe Sicherung vorgesehen

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- Docker Compose
- Stack-basierte Deployments
- zentrale Proxy-Architektur
- zentrale DNS-Struktur
- serviceorientierte Trennung

Dadurch bleibt die Infrastruktur:

- modular
- wartbar
- migrationsfähig
- skalierbar

---

# Zugehörige Seiten

- Portainer
- Docker-Stacks
- Persistente Volumes
- Container-Backup
- Update-Strategie
- Netzwerkstruktur

# Portainer

# Portainer

## Zweck

Portainer dient als zentrale Verwaltungsoberfläche für die Docker-Infrastruktur von Hainbach 45.

Die Plattform ermöglicht die grafische Verwaltung von:

- Containern
- Docker-Stacks
- Volumes
- Netzwerken
- Logs
- Images
- Updates

---

# Infrastrukturrolle

Portainer bildet die zentrale Administrationsplattform für nahezu alle containerisierten Dienste.

Die Plattform wird verwendet für:

- Stack-Deployments
- Neustarts
- Fehleranalyse
- Containerverwaltung
- Updateverwaltung
- Log-Analyse

---

# Architekturprinzip

Die Umgebung verwendet bewusst:

- Docker Compose
- Stack-basierte Deployments
- zentrale Containerverwaltung
- persistente Datenhaltung
- Reverse-Proxy-Integration

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | zentrale Containerplattform |

---

# Zugriff

Der Zugriff erfolgt intern über:

```text
portainer.home
```

Die Veröffentlichung erfolgt über:

```text
DNS
→ Reverse Proxy
→ Portainer
```

---

# Zielsystem

| Dienst | Ziel |
|---|---|
| Portainer | `https://10.45.10.10:9443` |

---

# Hauptfunktionen

## Stack-Verwaltung

Container werden überwiegend als Docker-Stacks betrieben.

Dadurch bleiben:

- Konfigurationen reproduzierbar
- Deployments standardisiert
- Dienste leichter migrierbar

---

## Containerverwaltung

Portainer ermöglicht:

- Starten
- Stoppen
- Neustarten
- Entfernen
- Überwachen

von Containern.

---

## Log-Analyse

Logs können zentral eingesehen werden.

Dies erleichtert:

- Fehleranalyse
- Troubleshooting
- Serviceüberwachung

---

## Netzwerkverwaltung

Docker-Netzwerke können zentral verwaltet werden.

Dies betrifft insbesondere:

- interne Servicekommunikation
- Proxy-Netzwerke
- Containerisolation

---

# Wichtige Stacks

## Infrastruktur

| Stack | Funktion |
|---|---|
| nginx-proxy-manager | Reverse Proxy |
| adguard | DNS |
| uptime-kuma | Monitoring |
| ntfy | Benachrichtigungen |
| wireguard | VPN |

---

## Plattformdienste

| Stack | Funktion |
|---|---|
| nextcloud | Fileservice |
| vaultwarden | Passwortverwaltung |
| bookstack | Dokumentation |

---

## Monitoring

| Stack | Funktion |
|---|---|
| grafana | Dashboards |
| influxdb | Zeitreihendatenbank |

---

# Sicherheitsprinzipien

Die Plattform dient insbesondere:

- zentraler Verwaltung
- kontrollierten Deployments
- reproduzierbaren Konfigurationen
- vereinfachten Wartungsarbeiten
- besserer Übersichtlichkeit

---

# Backup-Strategie

Die Docker-Daten werden persistent gespeichert und mittels Restic gesichert.

Typische Speicherorte:

```text
/srv/docker/
```

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- Stack-basierte Deployments
- zentrale Containerverwaltung
- Reverse-Proxy-first-Prinzip
- DNS-Rewrites
- persistente Volumes

Dadurch bleibt die Infrastruktur:

- modular
- wartbar
- migrationsfähig
- skalierbar

---

# Dokumentation

## Portainer Dashboard

> Optional Screenshot des Portainer-Dashboards einfügen

## Stack-Übersicht

> Optional Screenshot der Stack-Liste einfügen

# Docker-Stacks

# Docker-Stacks

## Zweck

Die Infrastruktur von Hainbach 45 verwendet überwiegend Docker-Stacks auf Basis von Docker Compose.

Stacks dienen zur:

- standardisierten Bereitstellung
- Gruppierung zusammengehöriger Dienste
- reproduzierbaren Konfiguration
- vereinfachten Migration
- zentralen Verwaltung

---

# Architekturprinzip

Jeder Dienst bzw. Dienstverbund wird als eigener Stack betrieben.

Beispiele:

- Reverse Proxy
- DNS
- Monitoring
- Nextcloud
- Vaultwarden
- BookStack

Dadurch bleiben:

- Dienste isoliert
- Deployments übersichtlich
- Konfigurationen nachvollziehbar
- Wartungsarbeiten einfacher

---

# Verwaltung

Die Stack-Verwaltung erfolgt zentral über:

```text
Portainer
```

Deployments erfolgen typischerweise über:

- Docker Compose
- Stack-Dateien
- Portainer Webinterface

---

# Hauptstacks

## Infrastruktur

| Stack | Funktion |
|---|---|
| `nginx-proxy-manager` | Reverse Proxy |
| `adguard` | DNS |
| `uptime-kuma` | Monitoring |
| `ntfy` | Benachrichtigungen |
| `wireguard` | VPN |

---

## Plattformdienste

| Stack | Funktion |
|---|---|
| `nextcloud` | Fileservice |
| `vaultwarden` | Passwortverwaltung |
| `bookstack` | Dokumentation |

---

## Monitoring

| Stack | Funktion |
|---|---|
| `grafana` | Dashboards |
| `influxdb` | Zeitreihendatenbank |

---

## Smart Home & OT

| Stack | Funktion |
|---|---|
| `iobroker` | Smart-Home-Plattform |

---

# Aufbau eines Stacks

Ein typischer Stack besteht aus:

- Compose-Datei
- Containerdefinitionen
- Volumes
- Netzwerken
- Umgebungsvariablen
- Reverse-Proxy-Anbindung

---

# Persistente Datenhaltung

Containerdaten werden persistent gespeichert.

Typische Speicherorte:

```text
/srv/docker/
```

Beispiele:

```text
/srv/docker/nginx-proxy-manager
/srv/docker/adguard
/srv/docker/bookstack
```

---

# Netzwerkprinzip

Container werden bewusst nicht direkt veröffentlicht.

Der Zugriff erfolgt standardisiert über:

```text
DNS
→ Reverse Proxy
→ Zielcontainer
```

Direkte Containerports werden möglichst vermieden.

---

# Vorteile der Stack-Struktur

## Reproduzierbarkeit

Stacks können jederzeit erneut bereitgestellt werden.

---

## Migration

Dienste lassen sich einfacher auf andere Systeme verschieben.

---

## Wartbarkeit

Konfigurationen bleiben zentral dokumentiert.

---

## Backupfähigkeit

Volumes und Stack-Dateien können gezielt gesichert werden.

---

# Sicherheitsprinzipien

Die Stack-Architektur dient insbesondere:

- Diensttrennung
- kontrollierten Veröffentlichungen
- minimierten Direktzugriffen
- vereinfachten Backups
- reproduzierbaren Deployments

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- Compose-basierte Deployments
- serviceorientierte Trennung
- Reverse-Proxy-first-Prinzip
- zentrale DNS-Struktur
- persistente Volumes

Dadurch bleibt die Infrastruktur:

- modular
- wartbar
- skalierbar
- migrationsfähig

---

# Dokumentation

## Stack-Übersicht

> Optional Screenshot der Stack-Liste in Portainer einfügen

## Beispiel-Compose-Datei

> Optional Beispiel eines Compose-Stacks einfügen

# Persistente Daten

# Persistente Daten

## Zweck

Die Infrastruktur von Hainbach 45 verwendet persistente Datenhaltung zur dauerhaften Speicherung containerbezogener Daten.

Dadurch bleiben Daten erhalten bei:

- Container-Neustarts
- Updates
- Stack-Neuinstallationen
- Migrationen
- Hostwechseln

---

# Architekturprinzip

Container selbst werden als austauschbar betrachtet.

Persistente Daten werden bewusst außerhalb der Container gespeichert.

Dadurch bleiben:

- Konfigurationen
- Datenbanken
- Medien
- Benutzerdateien
- Zertifikate

unabhängig vom Container erhalten.

---

# Speicherstruktur

Die zentrale Datenhaltung erfolgt überwiegend unter:

```text
/srv/docker/
```

---

# Wichtige Verzeichnisse

## Infrastrukturdienste

| Dienst | Pfad |
|---|---|
| AdGuard Home | `/srv/docker/adguard` |
| NGINX Proxy Manager | `/srv/docker/nginx-proxy-manager` |
| BookStack | `/srv/docker/bookstack` |
| Uptime Kuma | `/srv/docker/uptime-kuma` |

---

## Plattformdienste

| Dienst | Pfad |
|---|---|
| Nextcloud | `/srv/docker/nextcloud` |
| Vaultwarden | `/srv/docker/vaultwarden` |
| ntfy | `/srv/docker/ntfy` |

---

## Monitoring

| Dienst | Pfad |
|---|---|
| Grafana | `/srv/docker/grafana` |
| InfluxDB | `/srv/docker/influxdb` |

---

## Smart Home & OT

| Dienst | Pfad |
|---|---|
| ioBroker | `/srv/docker/iobroker` |

---

# Vorteile persistenter Datenhaltung

## Einfachere Migration

Container können neu erstellt werden, ohne Daten zu verlieren.

---

## Vereinfachte Backups

Nur persistente Verzeichnisse müssen gesichert werden.

---

## Reproduzierbare Infrastruktur

Containerdefinition und Datenhaltung bleiben getrennt.

---

## Vereinfachte Wiederherstellung

Ein Restore erfolgt typischerweise durch:

```text
1. Daten zurückspielen
2. Stack erneut deployen
3. Container starten
```

---

# Backup-Strategie

Die persistenten Daten werden mittels:

```text
Restic
```

gesichert.

Backupziele:

- QNAP NAS
- Synology-Replikation
- geplante Offsite-Sicherung

---

# Architekturentscheidung

Die Infrastruktur verwendet bewusst:

- bind mounts
- persistente Verzeichnisse
- servicegetrennte Speicherstrukturen
- keine wichtigen Daten innerhalb von Containern

---

# Sicherheitsprinzipien

Die Datenstruktur dient insbesondere:

- kontrollierten Backups
- vereinfachten Restores
- besserer Übersichtlichkeit
- reduzierten Datenverlusten
- klaren Servicegrenzen

---

# Besonderheiten

Die Datenhaltung orientiert sich bewusst an:

- serviceorientierter Trennung
- reproduzierbaren Deployments
- einfacher Backupfähigkeit
- klarer Verzeichnisstruktur

Dadurch bleibt die Infrastruktur:

- wartbar
- nachvollziehbar
- migrationsfähig
- recoveryfähig

---

# Dokumentation

## Verzeichnisstruktur

> Optional Screenshot der `/srv/docker`-Struktur einfügen

## Backupintegration

> Optional Screenshot der Restic-Backupstruktur einfügen

# Update-Strategie

# Update-Strategie

## Zweck

Die Infrastruktur von Hainbach 45 verwendet eine kontrollierte und überwachte Update-Strategie.

Ziel ist:

- stabile Betriebsführung
- kontrollierte Wartungsfenster
- Vermeidung ungeprüfter Änderungen
- Reduktion von Ausfallrisiken
- frühzeitige Erkennung neuer Container-Versionen

---

# Grundprinzip

Updates werden bewusst:

- kontrolliert
- manuell
- nachvollziehbar

durchgeführt.

Automatische Containerupdates werden nicht verwendet.

---

# Architekturprinzipien

Die Update-Strategie basiert auf folgenden Grundprinzipien:

- keine unkontrollierten Auto-Updates
- zentrale Überwachung neuer Versionen
- geplante Wartungsfenster
- vorherige Backups
- reproduzierbare Stack-Deployments
- kontrollierte Neustarts

---

# Container-Updates

Container werden überwiegend aktualisiert über:

```text
Portainer
→ Stack bearbeiten
→ Image aktualisieren
→ Redeploy
```

Alternativ:

```text
docker compose pull
docker compose up -d
```

---

# Monitoring neuer Versionen

Die Infrastruktur verwendet:

```text
Diun
```

zur Überwachung neuer Container-Versionen.

---

# Diun

## Zweck

Diun überwacht verfügbare Updates für:

- Docker-Container
- Images
- neue Versionen

Benachrichtigungen erfolgen über:

```text
ntfy
```

---

# Entscheidung gegen Watchtower

Watchtower wurde bewusst verworfen.

Grund:

- Docker-29-Kompatibilitätsprobleme
- automatische Änderungen unerwünscht
- fehlende Kontrolle über Wartungszeitpunkte

Fehlerbild:

```text
client version 1.25 is too old
```

---

# Betriebssystem-Updates

Linux-Updates erfolgen bewusst getrennt von Containerupdates.

Aktualisiert werden insbesondere:

- Debian
- Raspberry Pi OS
- Sicherheitsupdates
- Kernelupdates

---

# Update-Monitoring

Die Infrastruktur verwendet zusätzlich:

- apt-Update-Checks
- systemd Timer
- ntfy-Benachrichtigungen

Dadurch werden verfügbare Updates automatisch gemeldet.

---

# Backup vor Updates

Vor größeren Änderungen werden bevorzugt erstellt:

- Restic-Backups
- Snapshots
- Konfigurationssicherungen

Insbesondere vor:

- Datenbankupdates
- Nextcloud-Upgrades
- Infrastrukturänderungen
- Reverse-Proxy-Anpassungen

---

# Wartungsstrategie

Updates erfolgen bevorzugt:

- außerhalb kritischer Nutzungszeiten
- kontrolliert
- schrittweise
- dokumentiert

---

# Sicherheitsprinzipien

Die Update-Strategie dient insbesondere:

- höherer Stabilität
- kontrollierten Änderungen
- reduzierten Ausfallrisiken
- nachvollziehbaren Wartungen
- einfacheren Rollbacks

---

# Architekturentscheidung

Die Infrastruktur verwendet bewusst:

- kontrollierte Updates
- keine Auto-Updater
- Monitoring statt Automatisierung
- zentrale Benachrichtigungen
- reproduzierbare Stack-Strukturen

Dadurch bleibt die Umgebung:

- stabil
- nachvollziehbar
- wartbar
- recoveryfähig

---

# Dokumentation

## Diun

> Optional Screenshot der Diun-Konfiguration einfügen

## ntfy-Updates

> Optional Screenshot der Update-Benachrichtigungen einfügen

## Portainer-Stacks

> Optional Screenshot der Stack-Verwaltung einfügen

# Server

# Plattformdienste

# Übersicht

## Zweck

Die Infrastruktur von Hainbach 45 verwendet mehrere zentrale Plattformdienste zur Bereitstellung von:

- Infrastrukturservices
- Monitoring
- Dokumentation
- Remotezugriff
- Visualisierung
- Benachrichtigungen

Die Dienste bilden die technische Grundlage der gesamten Smart-Home- und Homelab-Umgebung.

---

# Architekturprinzip

Die Plattformdienste basieren bewusst auf:

- Docker-Containern
- zentraler Verwaltung
- Reverse-Proxy-Integration
- DNS-basierter Erreichbarkeit
- persistenter Datenhaltung
- serviceorientierter Trennung

---

# Hauptdienste

| Dienst | Funktion |
|---|---|
| ntfy | Benachrichtigungen |
| Uptime Kuma | Monitoring |
| Grafana | Dashboards |
| InfluxDB | Zeitreihendatenbank |
| BookStack | Dokumentation |
| WireGuard | VPN-Zugriff |

---

# Architekturübersicht

Die Plattformdienste kommunizieren typischerweise über:

```text
DNS
→ Reverse Proxy
→ Plattformdienst
```

Dadurch bleiben:

- Zugriffe standardisiert
- Containerports verborgen
- HTTPS zentral verwaltbar
- Dienste einfacher migrierbar

---

# Infrastrukturprinzipien

Die Umgebung verwendet bewusst:

- serviceorientierte Trennung
- zentrale DNS-Struktur
- Reverse-Proxy-first-Prinzip
- containerisierte Dienste
- persistente Volumes
- reproduzierbare Deployments

---

# Zugriffskonzept

Die meisten Plattformdienste sind intern erreichbar über:

```text
*.home
```

Beispiele:

```text
grafana.home
portainer.home
wiki.home
adguard.home
```

Öffentliche Dienste werden zusätzlich veröffentlicht über:

```text
*.schwarzi.at
```

---

# Sicherheitsprinzipien

Die Plattformarchitektur dient insbesondere:

- kontrollierten Zugriffen
- zentraler Verwaltung
- vereinfachten Wartungen
- reduzierten Direktzugriffen
- besserer Infrastrukturübersicht

---

# Containerisierung

Nahezu alle Plattformdienste laufen containerisiert.

Die Verwaltung erfolgt zentral über:

```text
Portainer
```

---

# Persistente Datenhaltung

Konfigurationen und Daten werden dauerhaft gespeichert unter:

```text
/srv/docker/
```

Dadurch bleiben Dienste unabhängig von einzelnen Containern erhalten.

---

# Monitoringintegration

Die Plattformdienste sind in die Monitoringstruktur integriert über:

- Uptime Kuma
- ntfy
- Grafana
- InfluxDB

---

# Zugehörige Seiten

- ntfy
- Uptime Kuma
- Diun
- Grafana
- InfluxDB
- BookStack
- WireGuard

# ntfy

## Zweck

ntfy dient als zentrale Benachrichtigungsplattform der H45-Infrastruktur.

Der Dienst ermöglicht Push-Benachrichtigungen für:

- Backups
- Systemfehler
- Updatehinweise
- Monitoringereignisse
- Serviceausfälle

Benachrichtigungen werden direkt an mobile Geräte übertragen.

---

# Architekturprinzip

Die Infrastruktur verwendet bewusst:

- leichtgewichtige Push-Benachrichtigungen
- zentrale Topics
- systemd-basierte Integration
- minimale externe Abhängigkeiten

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | zentrale Benachrichtigungsplattform |

---

# Zugriff

## Intern

```text
http://10.45.10.10:2586
```

## Extern

```text
https://ntfy.schwarzi.at
```

---

# Verwendete Topics

| Topic | Zweck |
|---|---|
| `H45-Backup` | erfolgreiche Backups |
| `H45-Alerts` | Fehler / Warnungen |
| `H45-Updates` | OS- und Containerupdates |
| `H45-Uptime` | Uptime-Kuma-Benachrichtigungen |
| `H45-Notify` | allgemeine Tests |

---

# Hauptfunktionen

## Backup-Benachrichtigungen

Restic-Backups senden Meldungen bei:

- erfolgreichem Backup
- fehlgeschlagenem Backup

Die Integration erfolgt über:

- systemd
- ExecStartPost
- OnFailure

---

## Monitoring-Benachrichtigungen

Uptime Kuma verwendet ntfy für:

- Serviceausfälle
- Wiederherstellungen
- Statusänderungen

---

## Update-Benachrichtigungen

Updates werden überwacht über:

- Diun
- apt-Checks
- systemd Timer

Benachrichtigungen erfolgen zentral über ntfy.

---

# Android-Integration

Verwendete App:

```text
ntfy
```

Konfiguration:

| Einstellung | Wert |
|---|---|
| Server | `http://10.45.10.10:2586` |
| Topics | `H45-*` |
| Akkuoptimierung | deaktiviert |
| Hintergrundaktivität | erlaubt |

---

# Architekturübersicht

Benachrichtigungsfluss:

```text
Dienst
→ ntfy
→ Smartphone
```

---

# Sicherheitsprinzipien

Die Benachrichtigungsplattform dient insbesondere:

- schneller Fehlererkennung
- zentraler Alarmierung
- reduzierten Reaktionszeiten
- vereinfachter Betriebsüberwachung

---

# Architekturentscheidung

Die Umgebung verwendet bewusst:

- ntfy statt komplexer SaaS-Lösungen
- lokale Infrastruktur
- zentrale Topics
- systemd-first-Prinzip
- einfache HTTP-Integration

Dadurch bleibt die Plattform:

- leichtgewichtig
- wartbar
- datenschutzfreundlich
- stabil

---

# Besonderheiten

Die Integration erfolgt bewusst minimalinvasiv.

Bestehende Backup- und Monitoring-Skripte werden nicht unnötig verändert.

Benachrichtigungen werden stattdessen ergänzt über:

- systemd Drop-Ins
- zusätzliche Scripts
- OnFailure-Mechanismen

---

# Dokumentation

## ntfy Topics

> Optional Screenshot der ntfy-Topics einfügen

## Android-App

> Optional Screenshot der ntfy-App einfügen

## Uptime-Kuma-Integration

> Optional Screenshot der ntfy-Notification-Konfiguration einfügen

# Uptime Kuma

## Zweck

Uptime Kuma dient als zentrale Plattform zur Verfügbarkeitsüberwachung der H45-Infrastruktur.

Der Dienst überwacht:

- Infrastrukturkomponenten
- Webdienste
- DNS
- Smart-Home-Dienste
- NAS-Systeme
- Internetverbindungen

Bei Ausfällen erfolgen automatische Benachrichtigungen über ntfy.

---

# Architekturprinzip

Die Monitoring-Infrastruktur verwendet bewusst:

- zentrale Verfügbarkeitsüberwachung
- einfache HTTP-/Ping-Checks
- zentrale Benachrichtigungen
- containerisierte Dienste
- minimale Komplexität

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | Verfügbarkeitsmonitoring |

---

# Zugriff

## Intern

```text
uptime.home
```

## Direktzugriff

```text
http://10.45.10.10:3003
```

---

# Hauptfunktionen

## Infrastrukturmonitoring

Überwachung von:

- DNS
- Reverse Proxy
- Containerplattform
- NAS-Systemen
- Internetverbindungen

---

## Webdienstmonitoring

Überwachung von:

- Nextcloud
- Vaultwarden
- Portainer
- Grafana
- ioBroker
- ntfy

---

## Netzwerkmonitoring

Zusätzlich werden überwacht:

- Router
- NAS-Systeme
- Netzwerkverbindungen
- Internetzugriff

---

# Verwendete Monitore

| Monitor | Typ |
|---|---|
| Internet | Ping |
| AdGuard | HTTP |
| NGINX Proxy Manager | HTTP |
| Portainer | HTTPS |
| Nextcloud | HTTPS |
| Vaultwarden | HTTPS |
| ioBroker | HTTP |
| ntfy | HTTP |
| QNAP | Ping |
| Synology | Ping |

---

# Portainer-Besonderheit

Empfohlene URL:

```text
https://10.45.10.10:9443/api/status
```

Zusätzlich aktiviert:

```text
TLS/SSL-Fehler ignorieren
```

---

# Standard-Monitoring-Einstellungen

| Parameter | Wert |
|---|---|
| Prüfintervall | 60 Sekunden |
| Wiederholungen | 2 |
| Retry-Intervall | 30 Sekunden |
| Timeout | 15 Sekunden |

---

# Benachrichtigungen

Benachrichtigungen erfolgen zentral über:

```text
ntfy
```

Verwendetes Topic:

```text
H45-Uptime
```

---

# Architekturübersicht

Monitoringfluss:

```text
Dienste
→ Uptime Kuma
→ ntfy
→ Smartphone
```

---

# Docker-Integration

Uptime Kuma läuft containerisiert.

---

# Docker-Compose

```yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma

    restart: unless-stopped

    ports:
      - 3003:3001

    volumes:
      - /opt/uptime-kuma:/app/data

    environment:
      - TZ=Europe/Vienna
```

---

# Sicherheitsprinzipien

Die Monitoringplattform dient insbesondere:

- schneller Fehlererkennung
- zentraler Infrastrukturüberwachung
- reduzierten Reaktionszeiten
- frühzeitiger Problemerkennung

---

# Architekturentscheidung

Die Umgebung verwendet bewusst:

- einfache HTTP-/Ping-Monitore
- zentrale Benachrichtigungen
- containerisierte Überwachung
- ntfy-Integration
- Reverse-Proxy-first-Prinzip

Dadurch bleibt die Plattform:

- leichtgewichtig
- stabil
- nachvollziehbar
- wartbar

---

# Besonderheiten

Die Plattform überwacht bewusst:

- interne Infrastruktur
- öffentliche Dienste
- DNS
- Reverse Proxy
- Smart-Home-Dienste
- NAS-Systeme

Dadurch entsteht ein zentraler Überblick über den Infrastrukturstatus.

---

# Dokumentation

## Dashboard

> Optional Screenshot des Uptime-Kuma-Dashboards einfügen

## Monitore

> Optional Screenshot der Monitorliste einfügen

## ntfy-Integration

> Optional Screenshot der Notification-Konfiguration einfügen

# Diun

## Zweck

Diun dient zur Überwachung verfügbarer Updates für Docker-Container innerhalb der H45-Infrastruktur.

Der Dienst erkennt neue Container-Versionen und informiert zentral über:

- neue Images
- verfügbare Updates
- geänderte Container-Tags

Benachrichtigungen erfolgen über ntfy.

---

# Architekturprinzip

Die Infrastruktur verwendet bewusst:

- kontrollierte Updates
- keine automatischen Containerupdates
- zentrale Updateüberwachung
- Benachrichtigungen statt Auto-Updater

---

# Zielsetzung

Ziele der Plattform:

- frühzeitige Erkennung neuer Container-Versionen
- kontrollierte Wartungsfenster
- reduzierte Ausfallrisiken
- nachvollziehbare Updates
- stabile Infrastruktur

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | Container-Update-Monitoring |

---

# Hauptfunktionen

## Image-Überwachung

Diun überwacht:

- Docker Hub
- Container-Registries
- neue Image-Versionen
- geänderte Tags

---

## Benachrichtigungen

Benachrichtigungen erfolgen zentral über:

```text
ntfy
```

Verwendetes Topic:

```text
H45-Updates
```

---

# Architekturübersicht

Updatefluss:

```text
Container Registry
→ Diun
→ ntfy
→ Smartphone
```

---

# Verwendete Strategie

Die Umgebung verwendet bewusst:

- Monitoring statt Auto-Updates
- manuelle Freigabe neuer Versionen
- kontrollierte Deployments
- geplante Wartungsfenster

---

# Entscheidung gegen Watchtower

Watchtower wurde bewusst verworfen.

Gründe:

- Docker-29-Kompatibilitätsprobleme
- automatische Änderungen unerwünscht
- reduzierte Kontrolle
- höheres Risiko ungeprüfter Updates

Bekannter Fehler:

```text
client version 1.25 is too old
```

---

# Vorteile von Diun

## Kontrollierte Updates

Updates erfolgen ausschließlich bewusst und manuell.

---

## Frühzeitige Information

Neue Versionen werden frühzeitig erkannt.

---

## Reduzierte Risiken

Keine ungeprüften automatischen Änderungen an Produktivsystemen.

---

## Bessere Wartbarkeit

Updates können geplant und dokumentiert durchgeführt werden.

---

# Sicherheitsprinzipien

Die Updateüberwachung dient insbesondere:

- höherer Stabilität
- kontrollierten Änderungen
- reduzierten Ausfallrisiken
- nachvollziehbaren Wartungen

---

# Architekturentscheidung

Die Umgebung verwendet bewusst:

- Benachrichtigungen statt Auto-Updater
- ntfy-Integration
- manuelle Freigaben
- kontrollierte Wartungsfenster
- reproduzierbare Stack-Deployments

Dadurch bleibt die Infrastruktur:

- stabil
- wartbar
- nachvollziehbar
- recoveryfähig

---

# Besonderheiten

Die Plattform überwacht ausschließlich Container-Updates.

Betriebssystemupdates werden separat überwacht über:

- apt
- systemd Timer
- ntfy

---

# Dokumentation

## Diun Dashboard / Logs

> Optional Screenshot der Diun-Logs einfügen

## ntfy-Benachrichtigungen

> Optional Screenshot der Update-Benachrichtigungen einfügen

## Portainer Stack

> Optional Screenshot des Diun-Stacks einfügen

# Grafana

## Zweck

Grafana dient als zentrale Visualisierungsplattform der H45-Infrastruktur.

Die Plattform ermöglicht:

- Dashboards
- Zeitreihenvisualisierung
- Infrastrukturmonitoring
- Smart-Home-Visualisierung
- Langzeitanalysen

Die Datenbasis stammt primär aus InfluxDB.

---

# Architekturprinzip

Die Monitoring-Infrastruktur verwendet bewusst:

- zentrale Dashboards
- getrennte Datenspeicherung
- Zeitreihendatenbanken
- serviceübergreifende Visualisierung
- containerisierte Plattformdienste

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | Monitoring & Dashboards |

---

# Zugriff

## Intern

```text
grafana.home
```

## Direktzugriff

```text
http://10.45.10.10:3000
```

---

# Hauptfunktionen

## Infrastrukturmonitoring

Visualisierung von:

- Serverstatus
- Netzwerkdaten
- Containerzuständen
- Verfügbarkeiten
- Performancewerten

---

## Smart-Home-Monitoring

Visualisierung von:

- Shelly-Daten
- Energieverbrauch
- PV-Daten
- Sensorwerten
- Smart-Home-Zuständen

---

## Langzeitanalyse

Grafana ermöglicht:

- historische Analysen
- Trendbeobachtungen
- Zeitreihenvergleiche
- Langzeitmonitoring

---

# Datenquellen

| Datenquelle | Zweck |
|---|---|
| InfluxDB | Zeitreihendaten |
| ioBroker | Smart-Home-Daten |
| Uptime Kuma | Statusinformationen |

---

# Architekturübersicht

Monitoringfluss:

```text
Geräte / Dienste
→ ioBroker / Monitoring
→ InfluxDB
→ Grafana
→ Dashboard
```

---

# Verwendete Dashboards

## Infrastruktur

- Serverstatus
- Docker
- Netzwerk
- Verfügbarkeit

---

## Smart Home

- Shelly
- Energieverbrauch
- PV
- Sensorik
- Smart-Home-Zustände

---

# Sicherheitsprinzipien

Die Plattform dient insbesondere:

- zentraler Übersicht
- vereinfachter Analyse
- Infrastrukturtransparenz
- Langzeitüberwachung
- schneller Fehlererkennung

---

# Docker-Integration

Grafana läuft containerisiert.

Persistente Daten werden gespeichert unter:

```text
/srv/docker/grafana
```

---

# Reverse-Proxy-Integration

Der Zugriff erfolgt über:

```text
DNS
→ Reverse Proxy
→ Grafana
```

Direkte Containerports werden möglichst vermieden.

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- zentrale Dashboards
- Zeitreihendatenbanken
- serviceübergreifende Visualisierung
- Reverse-Proxy-first-Prinzip
- persistente Datenhaltung

Dadurch bleibt die Plattform:

- wartbar
- nachvollziehbar
- erweiterbar
- langfristig nutzbar

---

# Dokumentation

## Dashboards

> Optional Screenshot der Dashboards einfügen

## Datenquellen

> Optional Screenshot der InfluxDB-Datenquelle einfügen

## Smart-Home-Visualisierung

> Optional Screenshot der Energie-/Shelly-Dashboards einfügen

# InfluxDB

## Zweck

InfluxDB dient als zentrale Zeitreihendatenbank der H45-Infrastruktur.

Die Plattform speichert:

- Monitoringdaten
- Smart-Home-Daten
- Sensordaten
- Energieverbrauchswerte
- Zeitreiheninformationen

Die Daten werden primär durch Grafana visualisiert.

---

# Architekturprinzip

Die Infrastruktur verwendet bewusst:

- zentrale Zeitreihenspeicherung
- getrennte Datenspeicherung
- langfristige Datenhaltung
- serviceübergreifende Analyse
- containerisierte Plattformdienste

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | Zeitreihendatenbank |

---

# Zugriff

## Intern

```text
influx.home
```

## Direktzugriff

```text
http://10.45.10.10:8086
```

---

# Hauptfunktionen

## Zeitreihenspeicherung

Speicherung von:

- Sensordaten
- Statuswerten
- Energieverbrauch
- Leistungsdaten
- Infrastrukturmetriken

---

## Smart-Home-Daten

InfluxDB dient insbesondere als Datenspeicher für:

- ioBroker
- Shelly
- PV-Daten
- Temperaturwerte
- Energieverbrauchswerte

---

## Langzeitarchivierung

Die Plattform ermöglicht:

- historische Analysen
- Trendanalysen
- Langzeitvergleiche
- Zeitreihenvisualisierung

---

# Architekturübersicht

Datenfluss:

```text
Geräte / Sensoren
→ ioBroker
→ InfluxDB
→ Grafana
→ Dashboard
```

---

# Datenquellen

| Quelle | Zweck |
|---|---|
| ioBroker | Smart-Home-Daten |
| Shelly | Energie-/Leistungsdaten |
| Monitoringdienste | Infrastrukturmetriken |

---

# Verwendete Datenarten

## Smart Home

- Temperaturen
- Statuswerte
- Schaltzustände
- Energieverbrauch
- Leistungswerte

---

## Infrastruktur

- Systemstatus
- Netzwerkdaten
- Verfügbarkeiten
- Monitoringwerte

---

# Docker-Integration

InfluxDB läuft containerisiert.

Persistente Daten werden gespeichert unter:

```text
/srv/docker/influxdb
```

---

# Reverse-Proxy-Integration

Der Zugriff erfolgt intern über:

```text
DNS
→ Reverse Proxy
→ InfluxDB
```

Direkte Containerports werden möglichst vermieden.

---

# Sicherheitsprinzipien

Die Plattform dient insbesondere:

- zentraler Datenspeicherung
- langfristiger Analyse
- Infrastrukturtransparenz
- kontrollierter Datenhaltung
- serviceübergreifender Visualisierung

---

# Backup-Strategie

Die persistenten Daten werden mittels:

```text
Restic
```

gesichert.

Die Sicherung erfolgt gemeinsam mit den übrigen Docker-Daten.

---

# Besonderheiten

Die Umgebung verwendet bewusst:

- zentrale Zeitreihenspeicherung
- serviceübergreifende Datenerfassung
- persistente Datenhaltung
- Reverse-Proxy-first-Prinzip
- containerisierte Plattformdienste

Dadurch bleibt die Plattform:

- wartbar
- nachvollziehbar
- skalierbar
- langfristig nutzbar

---

# Kritikalität

InfluxDB gilt als wichtiger Infrastrukturbaustein für:

- Monitoring
- Langzeitanalysen
- Smart-Home-Auswertungen
- Grafana-Dashboards

Ein Ausfall führt primär zu:

- fehlenden historischen Daten
- eingeschränkten Dashboards
- fehlender Langzeitvisualisierung

---

# Dokumentation

## Datenbanken / Buckets

> Optional Screenshot der Buckets einfügen

## Grafana-Integration

> Optional Screenshot der Datenquelle einfügen

## Smart-Home-Daten

> Optional Screenshot der Zeitreihen einfügen

# BookStack

## Zweck

BookStack dient als zentrale Dokumentationsplattform der H45-Infrastruktur.

Die Plattform ersetzt das bisherige Word-basierte IT-Handbuch schrittweise durch ein strukturiertes, webbasiertes Betriebswiki.

BookStack wird verwendet für:

- Architektur- und Infrastrukturdokumentation
- Betriebs- und Wartungsdokumentation
- Smart-Home- und OT-Dokumentation
- Notfall- und Recovery-Dokumentation
- Lessons Learned
- technische Betriebsnotizen

---

# Architekturprinzip

BookStack basiert auf einer klaren Dokumentationshierarchie:

```text
Regal
→ Buch
→ Kapitel
→ Seite
```

Diese Struktur passt zur H45-Dokumentation deutlich besser als eine klassische Wiki-Ordnerstruktur.

---

# Infrastrukturstandort

| System | Funktion |
|---|---|
| App-Server | Dokumentationsplattform |

---

# Zugriff

## Intern

```text
wiki.home
```

## Extern

```text
wiki.schwarzi.at
```

---

# Zielsystem

| Dienst | Ziel |
|---|---|
| BookStack | `http://10.45.10.10:3006` |

---

# Reverse-Proxy-Integration

BookStack wird über NGINX Proxy Manager veröffentlicht.

Zugriffsfluss:

```text
Client
→ DNS
→ Reverse Proxy
→ BookStack
```

---

# APP_URL

BookStack benötigt eine eindeutige kanonische URL.

Empfohlene produktive Einstellung:

```text
APP_URL=https://wiki.schwarzi.at
```

Eine parallele gleichwertige Nutzung mehrerer Basis-URLs ist nicht vorgesehen.

---

# Struktur der H45-Dokumentation

## Regal

```text
Hainbach 45
```

## Bücher

| Buch | Zweck |
|---|---|
| Architektur & Infrastruktur | Aufbau der technischen Umgebung |
| Betrieb & Wartung | Betriebsprozesse, Backup, Monitoring, Updates |
| Smart Home & OT | ioBroker, CCU3, Shelly, PV, IoT |
| Notfall & Recovery | Wiederherstellung, Notfallzugriff, SPOFs |
| Wissensbasis / Lessons Learned | Erkenntnisse, Entscheidungen, Migrationshistorie |

---

# Vorteile gegenüber Word

BookStack bietet:

- bessere Navigation
- einfachere Aktualisierung einzelner Seiten
- Suchfunktion
- klare Kapitelstruktur
- PDF-Export
- Bilder und Diagramme
- Versionierung
- bessere Wartbarkeit

---

# Backup-Relevanz

BookStack ist ein kritischer Dokumentationsdienst.

Zu sichern sind insbesondere:

- BookStack-Konfiguration
- Datenbank
- hochgeladene Bilder
- Anhänge
- Seiteninhalte

Persistente Daten befinden sich unter:

```text
/srv/docker/bookstack
```

---

# Sicherheitsprinzipien

Die Plattform enthält potenziell sensible Infrastrukturinformationen.

Daher gelten folgende Prinzipien:

- keine Klartext-Passwörter
- Zugangsdaten bleiben in Vaultwarden
- Notfallinformationen nur kontrolliert dokumentieren
- öffentliche Erreichbarkeit nur bewusst freigeben
- regelmäßiges Backup

---

# Besonderheiten

BookStack wird als zentrale „Source of Truth“ für die H45-Dokumentation verwendet.

Das bisherige IT-Handbuch wird perspektivisch nur noch als:

- PDF-Export
- Archivkopie
- Offline-Notfalldokument

verwendet.

---

# Dokumentation

## Startseite / Regalstruktur

> Optional Screenshot der BookStack-Regalstruktur einfügen

## Bücherübersicht

> Optional Screenshot der Bücherübersicht einfügen

## Exportfunktion

> Optional Screenshot der PDF-Exportfunktion einfügen