Monedula
Texte & Open Source

Diese Seite wurde maschinell aus dem Englischen übersetzt. Original lesen

monedula-gitops v0.1.0, AGPL-3.0

GitOps für Apache Kafka

Beschreiben Sie Topics, Zugriff, Quotas, Schemas, SCRAM-Benutzer und Confluent RBAC als YAML in Git. monedula-gitops vergleicht das mit dem laufenden Cluster, wendet nur an, was sich geändert hat, und lässt CI fehlschlagen, wenn der Cluster driftet. Dieselben Manifeste laufen über eine CLI oder einen Kubernetes-Operator.

Loslegen (auf Englisch) GitHub
brew install monedula-dev/tap/monedula-gitops
manifests/orders.yaml 
apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaTopic
metadata:
  name: orders
spec:
  clusterRef: { name: prod }
  topicName: orders
  partitions: 6
  config:
    retention.ms: "604800000"
  access:
    producers:
      - principal: User:svc-checkout
    consumers:
      - principal: User:svc-fraud
        group: fraud-orders
Terminal
monedula-gitops diff -f ./manifests --cluster-config-file ./cluster.yaml# preview: the topic, plus the ACLs its access block compiles tomonedula-gitops apply -f ./manifests --cluster-config-file ./cluster.yamlmonedula-gitops verify -f ./manifests --cluster-config-file ./cluster.yaml# exit 0: no drift. exit 1: drift, and the CI job fails.
6
Ressourcenarten, von Topics bis zu Confluent-RBAC-Rollenbindungen
8
in CI getestete Broker-Images: Apache Kafka 3.9 bis 4.3, Confluent Platform 7.6 bis 8.3
25
lauffähige Szenarien im Repository, jedes durchgängig geprüft

Das Problem

Kafka-Konfiguration liegt selten an einem einzigen Ort.

Topics kommen aus einem Skript, ACLs aus einem anderen, Schemas aus Anwendungs-Pipelines, Quotas von der Administration und Confluent-RBAC-Rollenbindungen aus wieder einem anderen Werkzeug. Mit der Zeit beschreibt nur noch der laufende Cluster das System, und diese Beschreibung hat niemand geprüft.

So funktioniert es

  1. 01 import cluster

    Importieren

    Einen laufenden Cluster in Manifeste verwandeln.

  2. 02 YAML + Pull Request

    Deklarieren

    Topics, Zugriff, Quotas, Schemas, SCRAM-Benutzer und Rollenbindungen als YAML im Kubernetes-Stil.

  3. 03 diff

    Vergleichen

    diff und apply --dry-run zeigen zuerst den Plan gegenüber dem laufenden Cluster.

  4. 04 apply

    Anwenden

    Nur die nötigen Operationen laufen. Pruning und riskante Änderungen warten auf explizite Flags.

  5. 05 verify

    Verifizieren

    verify endet bei Drift mit Exit-Code 1, sodass ein geplanter CI-Job Änderungen am Prozess vorbei erkennt.

  1. Git-Repository manifests/*.yaml, in Pull Requests geprüft
  2. CLI in CI validate, diff, apply, verify
    Operator in Kubernetes CRDs, Admission-Webhooks, Reconcile-Schleife
  3. Kafka Topics, ACLs, Quotas, SCRAM-Benutzer
    Schema Registry und MDS Schemas, Confluent-RBAC-Rollenbindungen
Die Manifeste in Git steuern die CLI in CI und den Operator in Kubernetes, die Kafka, Schema Registry und MDS ändern.

Ein Topic und sein Zugriff in einem Manifest

Die meisten Kafka-Werkzeuge halten ein Topic an einem Ort und seinen Zugriff an einem anderen. monedula-gitops hängt den Zugriff an das Topic selbst: Producer und Consumer auflisten, und die passenden Topic- und Consumer-Group-ACLs werden erzeugt. Auf Clustern mit RBAC kann derselbe Block zu Confluent-MDS-Rollenbindungen kompiliert werden.

Für präfixierte Muster, gemeinsam genutzte Consumer Groups oder Host-Einschränkungen gibt es die eigenständigen Ressourcen KafkaAccessPolicy und KafkaRoleBinding.

Strimzi
KafkaTopic + KafkaUser
Confluent for Kubernetes
Topic + separate Rollenbindungs-Ressourcen
Jikkou
Topic + separate Principal-Ressourcen
Terraform
eine Ressource pro ACL
monedula-gitops
ein KafkaTopic mit einem access-Block

Einen bestehenden Cluster importieren

import cluster liest Topics, ACLs, Quotas, Schemas und, wo unterstützt, RBAC-Rollenbindungen und schreibt daraus Manifeste. Werden sie gegen denselben Cluster verifiziert, wird kein Drift gemeldet.

Einen Cluster importieren (auf Englisch)

Terminal 
monedula-gitops import cluster --cluster-config-file ./clusters/prod.yaml --output-dir ./imported
monedula-gitops verify -f ./imported -R --cluster-config-file ./clusters/prod.yaml   # exits 0: no drift

SCRAM-Benutzer und Confluent-RBAC-Rollenbindungen

Ein KafkaUser deklariert ein SCRAM-Credential, sodass das Topic, sein Zugriff und der Principal, der es nutzt, gemeinsam in Git liegen. Die CLI liest das Passwort aus einer Umgebungsvariablen oder einer Datei; der Operator liest es aus einem Kubernetes Secret oder generiert eines.

KafkaRoleBinding verwaltet Confluent-MDS-Rollenbindungen neben den ACLs.

manifests/svc-checkout.yaml 
apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaUser
metadata:
  name: svc-checkout
spec:
  clusterRef: { name: prod }
  password:
    valueFrom: { env: SVC_CHECKOUT_PASSWORD }

Nichts wird versehentlich gelöscht

--dry-run zeigt jede Änderung vorab. Die CLI löscht nie Topics, SCRAM-Benutzer oder Quotas, die Sie aus Git entfernen. --prune löscht nur ACLs und Rollenbindungen, die unter eine Berechtigung fallen, die Ihre Manifeste noch deklarieren, und riskante Änderungen wie eine Erhöhung der Partitionszahl, eine niedrigere Schema-Kompatibilität oder ein entferntes Quota-Limit warten auf --allow-destructive. In Kubernetes entscheidet die Löschrichtlinie eines Topics, ob das Löschen der Ressource auch das Topic löscht, und Delete braucht zusätzlich die Annotation allow-delete.

Sicherheitsschranken (auf Englisch)

Exit-Codes
0Erfolg oder kein Drift bei verify
1Drift erkannt (verify)
2Validierungs-, Konfigurations- oder Verbindungsfehler oder eine fehlgeschlagene Operation
3Nur noch abgesicherte Operationen übrig, die auf --allow-destructive warten

Installation

Homebrew 
brew install monedula-dev/tap/monedula-gitops
Go 
go install github.com/monedula-dev/monedula-gitops/cmd/monedula-gitops@latest
Docker 
docker run --rm ghcr.io/monedula-dev/monedula-gitops:latest --help
Helm (operator) 
helm install monedula-gitops oci://ghcr.io/monedula-dev/charts/monedula-gitops

Vorgebaute Binaries für Linux und macOS liegen auf der Releases-Seite. Weiter: Erste Schritte mit der CLI (auf Englisch).

Fragen

Ist monedula-gitops kostenlos, und darf ich es bei der Arbeit nutzen?
Ja. Es steht unter der AGPL-3.0, ohne kostenpflichtige Edition, und wenn Sie es auf Ihren eigenen Clustern nutzen, als CLI oder als Operator in Ihrer eigenen Infrastruktur, müssen Sie weder Ihren Code noch Ihre Manifeste offenlegen: Pflichten aus der AGPL greifen, wenn Sie es verbreiten, ob verändert oder nicht, oder anderen ermöglichen, eine veränderte Version über ein Netzwerk zu nutzen. Für eine kommerzielle Lizenz kontaktieren Sie uns.
Funktioniert es mit Confluent Platform und Confluent Cloud?
Apache Kafka und Confluent Platform werden vollständig unterstützt, einschließlich Schema Registry und, auf Confluent Platform, MDS-Rollenbindungen. Confluent Cloud ist für Topics, ACLs, Schemas und Import validiert; Cloud stellt die APIs für Quotas und SCRAM nicht bereit. Die getesteten Versionen nennt die Seite Unterstützte Plattformen (auf Englisch).
Was unterscheidet es von Jikkou?
Beide verwalten Kafka als Code. monedula-gitops deklariert den Zugriff am Topic selbst, läuft sowohl als CLI als auch als Kubernetes-Operator, der fortlaufend abgleicht, und verwaltet Confluent-Platform-Rollenbindungen über MDS. Jikkou läuft als CLI oder API-Server und deckt mehr Plattformen und Ressourcentypen ab, etwa Kafka-Connect-Connectoren und Confluent-Cloud-Rollenbindungen. Die Vergleichsseite (auf Englisch) listet die Details samt dem Datum ihrer Prüfung auf.

Support

Hilfe von den Entwicklern des Tools

Wir können Ihnen helfen, monedula-gitops in einer großen Umgebung einzusetzen, vom Design bis zum täglichen Betrieb.

Sprechen Sie uns an

Teil von
Monedula Flock

Weitere kostenlose Tools für Apache Kafka vom selben Team. Über Flock