Die Lösung basiert auf einer GitOps-gesteuerte, verteilten Architektur. Alle relevanten Komponenten (Core, Agents, Infrastruktur wie NATS/Postgres, sowie Monitoring) werden zentral im Git-Repository versioniert über Fleet automatisch in das Kubernetes-Cluster ausgerollt.
Die Lösung basiert auf einer GitOps-gesteuerte, verteilten Architektur. Alle relevanten Komponenten (Core, Agents, Infrastruktur wie NATS/Postgres, sowie Monitoring) werden zentral im Git-Repository versioniert über Fleet automatisch in das Kubernetes-Cluster ausgerollt.
Damit trennen wir fachliche Logik (Core, Agents) von Basisdiensten (Messaging, Datenbank, Monitoring) und erhalten eine klare Struktur in Namespaces.
## Technishe Architektur
## Technishe Architektur
### GitOps & Control Plane
### GitOps & Control Plane
- GitRepo (fleet-local): definiert, welche Pfade aus dem `agent-core`-Gitlab-Repo deployt werden.
- GitRepo (fleet-local): definiert, welche Pfade aus dem `agent-core`-Gitlab-Repo deployt werden.
- Fleet Controller (cattle-fleet-system): überwacht die GitRepo-Definition mithilfe des `gitjob`, rendert Helm-Chats mit `helmops`, orchestriert/steuert Abhängigkeit und koordiniert und wann was deployt wird mittels `fleet-agent`.
- Fleet Controller (cattle-fleet-system): überwacht die GitRepo-Definition mithilfe des `gitjob`, rendert Helm-Chats mit `helmops`, orchestriert/steuert Abhängigkeit und koordiniert und wann was deployt wird mittels `fleet-agent`.
- (:red_circle: oder gitjob/helmops/fleet-agent einzeln?)
- Gitjob: holt den Code aus dem Git-Repository, damit Fleet die Inhalte verarbeiten kann.
- Gitjob: holt den Code aus dem Git-Repository, damit Fleet die Inhalte verarbeiten kann.
- Helmops: rendert und installiert Helm-Chart, basierend auf den Source-Code (:red_circle: das in `/gitops/.`)
- Helmops: rendert und installiert Helm-Chart, basierend auf den Source-Code
- Fleet-Agent: bietet das Bindeglied zwischen Fleet und Namespaces und spielt die Manifeste in die Ziel-Namespaes ein und reportiert Status zurück.
- Fleet-Agent: bietet das Bindeglied zwischen Fleet und Namespaces und spielt die Manifeste in die Ziel-Namespaes ein und reportiert Status zurück.
- Trennung Control Plane \<-\> Runtime
- Trennung Control Plane \<-\> Runtime
- Control Plane (Fleet) liegt im Namespace `cattle-fleet-system`.
- Control Plane (Fleet) liegt im Namespace `cattle-fleet-system`.
...
@@ -27,7 +20,7 @@ Damit trennen wir fachliche Logik (Core, Agents) von Basisdiensten (Messaging, D
...
@@ -27,7 +20,7 @@ Damit trennen wir fachliche Logik (Core, Agents) von Basisdiensten (Messaging, D
### Runtime-Namespaces
### Runtime-Namespaces
- Namespace core: beherbergt den zentralen Core-Service. Als `deployment` ist dieser Service dauerhaft erreichbar, persistiert in Postgres und kommuniziert über NATS.
- Namespace core: beherbergt den zentralen Core-Service. Als `deployment` ist dieser Service dauerhaft erreichbar, persistiert in Postgres und kommuniziert über NATS.
- Namespace Agents: enthält die spezialisierten Agenten (noshow, marathon usw.), die periodisch als Cronjobs laufen und nach dem Job wieder heruntergefahren werden (:red_circle: destroyd?)
- Namespace Agents: enthält die spezialisierten Agenten (noshow, marathon usw.), die periodisch als Cronjobs laufen und nach dem Job wieder heruntergefahren werden
- Namespace nats: stellt den Message Broker bereit.
- Namespace nats: stellt den Message Broker bereit.
- Namespace postgres: verwaltet den Datenbank-State und ist persistent über PVC (PersistentVolumeClaim).
- Namespace postgres: verwaltet den Datenbank-State und ist persistent über PVC (PersistentVolumeClaim).
- Namespace monitoring: ermöglicht Observability durch Loki/Promtail/Grafana.
- Namespace monitoring: ermöglicht Observability durch Loki/Promtail/Grafana.
...
@@ -36,50 +29,7 @@ Damit trennen wir fachliche Logik (Core, Agents) von Basisdiensten (Messaging, D
...
@@ -36,50 +29,7 @@ Damit trennen wir fachliche Logik (Core, Agents) von Basisdiensten (Messaging, D
- Agents \<-\> Core: Die Kommunikation ähnelt dem RPC-Pattern einfach über NATS. Die Agents senden einen Request und der Core antwortet darauf. Der Core imitiert keine Kommunikation.
- Agents \<-\> Core: Die Kommunikation ähnelt dem RPC-Pattern einfach über NATS. Die Agents senden einen Request und der Core antwortet darauf. Der Core imitiert keine Kommunikation.
- Core \<-\> Postgres: klassisches Read/Write mit DB-Connection
- Core \<-\> Postgres: klassisches Read/Write mit DB-Connection
- Logging: Promtail sammelt Container-Logs und pusht sie an Loki. Grafana visualisiert die Daten über Loki als Datasource (ausführlichere Beschreibung hier zu finden :link: LINK :red_circle:).
- Logging: Promtail sammelt Container-Logs und pusht sie an Loki. Grafana visualisiert die Daten über Loki als Datasource.
## :red_circle: ???
### Warum verteilte Architektur?
- Trennung von Verantwortlichkeiten:
- Core ist der zentrale Business Logic Server
- Agenten sind kleine, isolierte Tasks, die unabhängig voneinander skalierter und austauschbar sind.
- Lose Kopplung: Kommunikation über NATS entkoppelt Agents und Core zeitlich und organisatorisch.
- Erweiterbarkeit: Neue Agenten können hinzugefuegt werden ohne Core anzupassen.
- Resilient: Fällt ein Agent aus, bleiben die anderen lauffähig – Core bleibt stabil.
### Warum GitOps mit Fleet?
- Nachvollziehbarkeit: Jede Änderung im Cluster als Commit im Git-Repo nachvollziehbar.
- Automatisierung: Deployments erfolgen automatisch, konsistent und reproduzierbar.
- Abhängigkeiten steuerbar: Es wird sichergestellt, dass zB, der Core erst startet, wenn Postgres und NATS verfügbar sind.
- Multi-Namespace & Multi-Cluster fähig: Struktur kann problemlos auf grössere Umgebungen erweitert werden.
## Mehrwert für das Business
- Schnellers Onboarding: Neue Entwickler oder Betreiber verstehen sofort, welche Komponenten wo laufen
- Stabilität & Qualität: Fehler in der Infrastruktur wirken sich nicht chaotisch auf alle Services aus, sondern sind klar isoliert.
- Agilität: Agenten koennen unabhängig voneinander deployed oder aktualisiert werden – kürzere Entwicklungszyklen.
- Observability eingebaut: Logs sind zentralisiert via Loki/Grafana. Auch wenn Prometheus fehlt, ist das System schon recht gut beobachtbar.
## Erweiterbarkeit (Beispiel zu Monitoring)
Ein grosser Vorteil der Architektur ist die einfache Erweiterbarkeit:
- Prometheus/Alertmanager oder OpenTelemetry Collector koennen analog zu Loki/Grafana als eigene Bundles im Namespace monitoring hunzugefuegt werden.
- Dank GitOps genügt ein zusätzlicher Eintrag im Repo (`gitops/infra/monitoring/prometheus`) sowie deren Definition, und Fleet übernimmt das Deployment und die Steuerung.
- Keine strukturellen Änderungen nötig: Die Monitoring-Komponenten wären genauso lose gekoppelt wie heute Loki/Promtail.
Damit zeigt sich: Auch wenn Monitoring aktuell nur Logging abdeckt, ist die Erweiterung auf Metric/Tracing ohne Bruch möglich und weitestgehend darauf ausgelegt.
## Zusammenfassung
- Die Architektur trennt fachliche Logik, Infrastruktur und Steuerung klar voneinander.
- Durch GitOps mit Fleet haben wir eine automatisierte, reproduzierbare Deployment-Pipeline.
- Fachliche profitieren wir von Entkopplung, Erweiterbarkeit und Transparenz.
- Der Aufbau ist zukunftssicher: zusätzliche Monitoring-/Tracing-Komponenten können problemlos integriert werden.
- Die Verteilung mit Fleet/GitOps soll dem Unternehmen helfen, stabile, nachvollziehbare und leicht modifizierbare Artefakte an Kunden auszurollen.
