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: 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: /srv/docker/ Beispiele: /srv/docker/nginx-proxy-manager /srv/docker/adguard /srv/docker/bookstack Reverse-Proxy-Integration Nahezu alle Containerdienste werden veröffentlicht über: 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: 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: portainer.home Die Veröffentlichung erfolgt über: 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: /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: 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: /srv/docker/ Beispiele: /srv/docker/nginx-proxy-manager /srv/docker/adguard /srv/docker/bookstack Netzwerkprinzip Container werden bewusst nicht direkt veröffentlicht. Der Zugriff erfolgt standardisiert über: 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: /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: 1. Daten zurückspielen 2. Stack erneut deployen 3. Container starten Backup-Strategie Die persistenten Daten werden mittels: 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: Portainer → Stack bearbeiten → Image aktualisieren → Redeploy Alternativ: docker compose pull docker compose up -d Monitoring neuer Versionen Die Infrastruktur verwendet: Diun zur Überwachung neuer Container-Versionen. Diun Zweck Diun überwacht verfügbare Updates für: Docker-Container Images neue Versionen Benachrichtigungen erfolgen über: ntfy Entscheidung gegen Watchtower Watchtower wurde bewusst verworfen. Grund: Docker-29-Kompatibilitätsprobleme automatische Änderungen unerwünscht fehlende Kontrolle über Wartungszeitpunkte Fehlerbild: 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