---
title: "monedula-gitops"
repo: https://github.com/monedula-dev/monedula-gitops
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **Begleitender Beitrag:** [Monedula GitOps: deklaratives Kafka-Management für CLI und Kubernetes](/blog/monedula-gitops/) stellt das Release `v0.1.0`, das Ressourcenmodell und den grundlegenden Workflow vor.

## Warum

Kafka-Konfiguration liegt selten an einem einzigen Ort. Topics kommen aus
einem Skript, ACLs aus einem anderen, Schemas aus Anwendungs-Pipelines,
Quotas aus der Administration und Confluent-RBAC-Rollenbindungen aus wieder
einem anderen Werkzeug. Mit der Zeit ist der laufende Cluster die einzige
verlässliche Beschreibung des Systems — aber keine beabsichtigte und keine,
die man reviewen könnte.

`monedula-gitops` macht diese Beschreibung explizit: den gewünschten
Kafka-Zustand in Git beschreiben, wie Code reviewen, mit dem laufenden Cluster
vergleichen und den Cluster darauf zuführen.

Kafka besteht nicht nur aus Topics, deshalb deckt das Modell die Ressourcen
ab, die üblicherweise zusammengehören — Zugriffsregeln, Consumer Groups,
Quotas, Schemas, Credentials und, in der Confluent Platform,
RBAC-Rollenbindungen.

## Ein Modell, zwei Laufzeiten

CLI und Kubernetes-Operator nutzen dasselbe Ressourcenmodell und dieselbe
Reconciliation-Engine.

- **CLI** — Manifeste von einem Entwicklungsrechner oder aus einer
  CI/CD-Pipeline validieren, diffen, anwenden und verifizieren. `verify`
  liefert bei erkanntem Drift einen Exit-Code ungleich null und taugt damit
  als CI-Gate.
- **Operator** — dieselben Kubernetes-artigen Ressourcen als CRDs
  installieren und innerhalb eines Clusters fortlaufend abgleichen.

Credentials werden in beiden Laufzeiten unterschiedlich bereitgestellt —
Umgebungs- oder Dateireferenzen für die CLI, Kubernetes Secrets für den
Operator —, aber gewünschter Zustand, Drift-Regeln und Ausführungssemantik
bleiben konsistent. Ein Team kann mit Pipeline-getriebenen Änderungen
beginnen und den Operator später einführen, ohne ein zweites
Konfigurationsmodell zu entwerfen.

## Was es verwaltet

`KafkaCluster` (Verbindung, Authentifizierung, Defaults, Schema Registry,
optional Confluent MDS), `KafkaTopic` (Lebenszyklus, Partitionen,
Konfiguration, topic-lokaler Zugriff, Schemas), `KafkaAccessPolicy`
(fortgeschrittene und gemeinsam genutzte ACL-Regeln), `KafkaQuota` (Quotas
für Benutzer, Client-ID und IP), `KafkaUser` (SCRAM-Credentials) und
`KafkaRoleBinding` (Confluent MDS/RBAC).

Der häufigste Fall bleibt klein: Ein Topic und die Anwendungen, die es nutzen
dürfen, passen in ein Manifest, und die zugehörigen Topic- und
Consumer-Group-ACLs werden daraus erzeugt:

```yaml
apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaTopic
metadata:
  name: orders
spec:
  clusterRef:
    name: prod
  topicName: orders
  partitions: 6
  access:
    producers:
      - principal: User:svc-checkout
    consumers:
      - principal: User:svc-fraud
        group: fraud-orders
```

## Installation

```bash
brew install monedula-dev/tap/monedula-gitops
```

Ebenso verfügbar über `go install`, als vorgebaute Binaries aus den
GitHub-Releases und als Container-Image unter
`ghcr.io/monedula-dev/monedula-gitops`. Der Operator wird per Helm aus
`oci://ghcr.io/monedula-dev/charts/monedula-gitops` installiert.

## Mit einem bestehenden Cluster starten

Echte Umgebungen sind selten leer, deshalb liest `import cluster` den
aktuellen Kafka-Zustand und erzeugt daraus Manifeste — Topics,
Zugriffsregeln, Quotas, Schemas, SCRAM-Benutzer und, wo unterstützt,
Confluent-RBAC-Rollenbindungen. Entscheidend ist der Round Trip: Wird das
importierte Verzeichnis gegen denselben Cluster verifiziert, sollte kein
Drift gemeldet werden.

Riskante Operationen sind abgesichert, Löschen und Pruning erfordern eine
ausdrückliche Freigabe. Im Repository liegen zwei lauffähige Quickstarts (ein
CLI-Spielplatz mit Docker Compose und ein Operator-Spielplatz auf lokalem
Kubernetes) sowie ein Katalog mit 25 in sich geschlossenen Szenarien.