Monedula
Articoli e open source

Questa pagina è stata tradotta automaticamente dall'inglese. Leggi l'originale

monedula-gitops v0.1.0, AGPL-3.0

GitOps per Apache Kafka

Descrivi topic, accessi, quote, schemi, utenti SCRAM e RBAC di Confluent come YAML in Git. monedula-gitops li confronta con il cluster in esecuzione, applica solo ciò che è cambiato e fa fallire la CI quando rileva un drift. Gli stessi manifest funzionano da una CLI o da un operator Kubernetes.

Inizia (in inglese) 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
terminale
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
tipi di risorsa, dai topic ai role binding RBAC di Confluent
8
immagini di broker testate in CI: Apache Kafka da 3.9 a 4.3, Confluent Platform da 7.6 a 8.3
25
scenari eseguibili nel repository, ognuno verificato end-to-end

Il problema

La configurazione di Kafka si trova raramente in un unico posto.

I topic arrivano da uno script, le ACL da un altro, gli schemi dalle pipeline applicative, le quote da un amministratore e i role binding RBAC di Confluent da un ulteriore strumento. Col tempo solo il cluster in esecuzione descrive il sistema, e nessuno ha revisionato quella descrizione.

Come funziona

  1. 01 import cluster

    Importare

    Trasforma un cluster in esecuzione in manifest.

  2. 02 YAML + pull request

    Dichiarare

    Topic, accessi, quote, schemi, utenti SCRAM e role binding come YAML in stile Kubernetes.

  3. 03 diff

    Confrontare

    diff e apply --dry-run mostrano prima il piano rispetto al cluster in esecuzione.

  4. 04 apply

    Applicare

    Vengono eseguite solo le operazioni necessarie. Il pruning e le modifiche rischiose attendono flag espliciti.

  5. 05 verify

    Verificare

    verify esce con codice 1 in caso di drift, così un job CI pianificato intercetta le modifiche fatte fuori da Git.

  1. Repository Git manifests/*.yaml, revisionati nelle pull request
  2. CLI in CI validate, diff, apply, verify
    Operator in Kubernetes CRD, admission webhook, ciclo di riconciliazione
  3. Kafka topic, ACL, quote, utenti SCRAM
    Schema Registry e MDS schemi, role binding RBAC di Confluent
I manifest in Git guidano la CLI in CI e l'operator in Kubernetes, che modificano Kafka, Schema Registry e MDS.

Un topic e i suoi accessi, in un solo manifest

La maggior parte degli strumenti per Kafka tiene un topic in un posto e i suoi accessi in un altro. monedula-gitops lega gli accessi al topic stesso: elenchi i producer e i consumer, e vengono generate le ACL di topic e di consumer group corrispondenti. Sui cluster con RBAC, lo stesso blocco può essere compilato in role binding di Confluent MDS.

Quando ti servono pattern con prefisso, consumer group condivisi o restrizioni sugli host, ci sono le risorse autonome KafkaAccessPolicy e KafkaRoleBinding.

Strimzi
KafkaTopic + KafkaUser
Confluent for Kubernetes
topic + risorse di role binding separate
Jikkou
topic + risorse principal separate
Terraform
una risorsa per ACL
monedula-gitops
un KafkaTopic con un blocco access

Importa un cluster esistente

import cluster legge topic, ACL, quote, schemi e, dove supportati, i role binding RBAC, e scrive i manifest. Verificarli sullo stesso cluster non rileva alcun drift.

Come importare un cluster (in inglese)

terminale 
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

Utenti SCRAM e role binding RBAC di Confluent

Un KafkaUser dichiara una credenziale SCRAM, così il topic, i suoi accessi e il principal che lo usa stanno insieme in Git. La CLI legge la password da una variabile d'ambiente o da un file; l'operator la legge da un Secret di Kubernetes, oppure ne genera una.

KafkaRoleBinding gestisce i role binding di Confluent MDS insieme alle ACL.

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 }

Niente viene eliminato per errore

--dry-run mostra in anteprima ogni modifica. La CLI non elimina mai un topic, un utente SCRAM o una quota che rimuovi da Git. --prune elimina solo ACL e role binding che rientrano in un permesso ancora dichiarato dai tuoi manifest, e le modifiche rischiose, come un aumento delle partizioni, un abbassamento della compatibilità di uno schema o la rimozione di un limite di quota, attendono --allow-destructive. In Kubernetes, la policy di eliminazione di un topic decide se eliminare la risorsa elimina anche il topic, e Delete richiede anche l'annotazione allow-delete.

Controlli di sicurezza (in inglese)

Codici di uscita
0Successo, o nessun drift per verify
1Drift rilevato (verify)
2Errore di validazione, di configurazione o di connessione, oppure un'operazione non riuscita
3Restano solo operazioni protette: attendono --allow-destructive

Installazione

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

I binari precompilati per Linux e macOS sono nella pagina delle release. Passo successivo: iniziare con la CLI (in inglese).

Domande

monedula-gitops è gratuito e posso usarlo al lavoro?
Sì. È sotto licenza AGPL-3.0, senza edizioni a pagamento, e usarlo sui tuoi cluster, come CLI o come operator nella tua infrastruttura, non ti obbliga a condividere il tuo codice o i tuoi manifest: gli obblighi della AGPL si applicano quando lo distribuisci, modificato o meno, o permetti ad altri di usarne una versione modificata attraverso una rete. Per una licenza commerciale, contattaci.
Funziona con Confluent Platform e Confluent Cloud?
Apache Kafka e Confluent Platform sono pienamente supportati, inclusi Schema Registry e, su Confluent Platform, i role binding MDS. Confluent Cloud è validato per topic, ACL, schemi e import; Cloud non espone le API per quote e SCRAM. Le versioni testate sono in piattaforme supportate (in inglese).
In cosa si differenzia da Jikkou?
Entrambi gestiscono Kafka come codice. monedula-gitops dichiara gli accessi sul topic stesso, funziona sia come CLI sia come operator Kubernetes che riconcilia in modo continuo, e gestisce i role binding di Confluent Platform tramite MDS. Jikkou funziona come CLI o come server API e copre più piattaforme e tipi di risorsa, come i connector di Kafka Connect e i role binding di Confluent Cloud. La pagina di confronto (in inglese) riporta i dettagli, con la data in cui sono stati verificati.

Supporto

Aiuto da chi sviluppa lo strumento

Possiamo aiutarti a gestire monedula-gitops su un'infrastruttura estesa, dalla progettazione all'operatività quotidiana.

Parliamone

Parte di
Monedula Flock

Altri strumenti gratuiti per Apache Kafka, dallo stesso team. Informazioni su Flock