c7482368864adfeaa65ae63c6b00c7a2fbc5fc9d
Homelab Infrastructure (KalliLab CORE)
Dieses Repository ist die zentrale Quelle ("Single Source of Truth") fuer die komplette Infrastruktur meines Homelabs.
WICHTIG - Einstieg
Vor jeder Aenderung lesen:
HOMELAB_ARCHITECTURE_MASTER_V2.mddocs/WORKFLOW.md
Bei Restore-, Host-Ausfall- oder Wiederanlauf-Fragen zusaetzlich:
docs/DISASTER_RECOVERY.mddocs/RESTORE_MATRIX.md
Architektur
- Host: Unraid
- Container: Docker Compose
- Reverse Proxy: Traefik v3 (Service-Routing via Docker-Labels, File-Provider nur fuer zentrale Dynamic-Config)
- Zugriff: Tailscale (VPN)
- DNS: AdGuard Home + Unbound
- GitOps: Gitea + Komodo
Grundprinzipien
- Gitea Online ist der operative Sollzustand.
- Der lokale Clone ist die Arbeitskopie.
- Komodo deployed automatisch aus Gitea und ist kein Bearbeitungsort.
- Keine produktiven Container ausserhalb von Compose.
- Traefik ist der einzige oeffentliche Einstiegspunkt.
- Secrets werden niemals im Repository gespeichert.
Repository-Struktur
core/-> Basisdienste (Gitea)security/-> sicherheitskritische Diensteinfra/-> Datenbanken und technische Servicesapps/-> Anwendungenops/-> Monitoring und Toolshost-services/-> Dienste mit Host-Netztraefik/-> Reverse Proxy Konfigurationdocs/-> Dokumentation und Prozesseenv/-> Beispiel-Umgebungsvariablen
Kurz-Workflow
- In GitHub Desktop
Fetch origin. - Wenn noetig
Pull origin. - Lokal aendern.
- Commit erstellen.
Push origin.- Komodo-Webhook und Ergebnis pruefen.
- Doku bei Bedarf aktualisieren.
Status
- Komodo ist der primaere und einzige produktive Stack-Manager.
- Komodo bleibt bewusst bei nativer Authentifizierung; zentrale Traefik-Auth wird dort nicht pauschal vorgeschaltet.
- Portainer CE ist abgeschaltet und kein Teil des aktiven Betriebs mehr.
- Homepage ist das aktive produktive Frontend / Start-Dashboard.
- Traefik
dynamic/bleibt eine dokumentierte manuelle Host-Sync-Ausnahme ausserhalb des normalen Komodo-Deployments. - Mutable Image-Tags sind auf die aktuell laufenden Digests eingefroren; echte Versions-Upgrades erfolgen bewusst separat.
- Disaster-Recovery und dienstspezifische Restore-Quellen sind in
docs/DISASTER_RECOVERY.mdunddocs/RESTORE_MATRIX.mdbeschrieben. - Der verbindliche Detailablauf steht in
docs/WORKFLOW.md. nextcloud,bentopdfundmonitoringfolgen dem dokumentierten Netz-/Secret-/Traefik-Modell; der zentrale Monitoring-Stack buendelt Prometheus, Loki, Promtail, Grafana und InfluxDB 3 Core.
Description
Languages
Shell
68%
PowerShell
25.7%
Python
5.6%
JavaScript
0.4%
Dockerfile
0.3%