Monedula
Écrits & open source

Cette page a été traduite automatiquement depuis l’anglais. Lire l’original

monedula-gitops v0.1.0, AGPL-3.0

GitOps pour Apache Kafka

Décrivez topics, accès, quotas, schémas, utilisateurs SCRAM et RBAC Confluent en YAML dans Git. monedula-gitops compare cette description au cluster en production, n'applique que ce qui a changé et fait échouer la CI en cas de drift. Les mêmes manifestes s'exécutent depuis une CLI ou un opérateur Kubernetes.

Commencer (en anglais) 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
types de ressources, des topics aux bindings de rôles RBAC Confluent
8
images de broker testées dans la CI : Apache Kafka 3.9 à 4.3, Confluent Platform 7.6 à 8.3
25
scénarios exécutables dans le dépôt, chacun vérifié de bout en bout

Le problème

La configuration de Kafka est rarement réunie en un seul endroit.

Les topics viennent d'un script, les ACL d'un autre, les schémas des pipelines applicatifs, les quotas d'un administrateur et les bindings de rôles RBAC Confluent d'un outil encore différent. Avec le temps, seul le cluster en production décrit le système, et personne n'a relu cette description.

Comment ça fonctionne

  1. 01 import cluster

    Importer

    Générer des manifestes depuis un cluster en production.

  2. 02 YAML + pull request

    Déclarer

    Topics, accès, quotas, schémas, utilisateurs SCRAM et bindings de rôles en YAML de style Kubernetes.

  3. 03 diff

    Comparer

    diff et apply --dry-run montrent d'abord le plan face au cluster en production.

  4. 04 apply

    Appliquer

    Seules les opérations nécessaires s'exécutent. Le pruning et les changements risqués attendent des flags explicites.

  5. 05 verify

    Vérifier

    verify renvoie le code 1 en cas de drift : un job CI planifié détecte ainsi les changements faits en dehors de Git.

  1. Dépôt Git manifests/*.yaml, relus dans des pull requests
  2. CLI dans la CI validate, diff, apply, verify
    Opérateur dans Kubernetes CRD, webhooks d'admission, boucle de réconciliation
  3. Kafka topics, ACL, quotas, utilisateurs SCRAM
    Schema Registry et MDS schémas, bindings de rôles RBAC Confluent
Les manifestes dans Git pilotent la CLI dans la CI et l'opérateur dans Kubernetes, qui modifient Kafka, Schema Registry et MDS.

Un topic et ses accès, dans un seul manifeste

La plupart des outils Kafka gardent un topic à un endroit et ses accès à un autre. monedula-gitops rattache les accès au topic lui-même : listez les producteurs et les consommateurs, et les ACL de topic et de groupe de consommateurs correspondantes sont générées. Sur les clusters dotés du RBAC, ce même bloc peut être compilé en bindings de rôles Confluent MDS.

Pour les patterns préfixés, les groupes de consommateurs partagés ou les restrictions d'hôte, les ressources autonomes KafkaAccessPolicy et KafkaRoleBinding sont disponibles.

Strimzi
KafkaTopic + KafkaUser
Confluent for Kubernetes
topic + ressources de binding de rôle séparées
Jikkou
topic + ressources de principal séparées
Terraform
une ressource par ACL
monedula-gitops
un KafkaTopic avec un bloc access

Importer un cluster existant

import cluster lit les topics, les ACL, les quotas, les schémas et, là où c'est pris en charge, les bindings de rôles RBAC, puis écrit des manifestes. Les vérifier face au même cluster ne signale aucun drift.

Importer un cluster (en anglais)

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

Utilisateurs SCRAM et bindings de rôles RBAC Confluent

Un KafkaUser déclare des identifiants SCRAM : le topic, ses accès et le principal qui l'utilise sont décrits ensemble dans Git. La CLI lit le mot de passe dans une variable d'environnement ou un fichier ; l'opérateur le lit dans un Secret Kubernetes, ou en génère un.

KafkaRoleBinding gère les bindings de rôles Confluent MDS aux côtés des 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 }

Rien n'est supprimé par accident

--dry-run prévisualise chaque changement. La CLI ne supprime jamais un topic, un utilisateur SCRAM ou un quota que vous retirez de Git. --prune ne supprime que les ACL et les bindings de rôles qui relèvent d'une autorisation que vos manifestes déclarent encore, et les changements risqués, comme une augmentation du nombre de partitions, un abaissement de la compatibilité de schéma ou la suppression d'une limite de quota, attendent --allow-destructive. Dans Kubernetes, la politique de suppression d'un topic détermine si la suppression de la ressource supprime aussi le topic, et Delete exige en plus l'annotation allow-delete.

Les garde-fous (en anglais)

Codes de sortie
0Succès, ou aucun drift pour verify
1Drift détecté (verify)
2Erreur de validation, de configuration ou de connexion, ou opération en échec
3Il ne reste que des opérations protégées : elles attendent --allow-destructive

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

Des binaires précompilés pour Linux et macOS sont disponibles sur la page des releases. Ensuite : démarrer avec la CLI (en anglais).

Questions

monedula-gitops est-il gratuit, et puis-je l'utiliser au travail ?
Oui. Il est sous licence AGPL-3.0, sans édition payante, et l'utiliser sur vos propres clusters, comme CLI ou comme opérateur dans votre propre infrastructure, ne vous oblige pas à partager votre code ni vos manifestes : les obligations de l'AGPL s'appliquent lorsque vous le distribuez, modifié ou non, ou lorsque vous permettez à d'autres d'utiliser une version modifiée via un réseau. Pour une licence commerciale, contactez-nous.
Fonctionne-t-il avec Confluent Platform et Confluent Cloud ?
Apache Kafka et Confluent Platform sont entièrement pris en charge, y compris Schema Registry et, sur Confluent Platform, les bindings de rôles MDS. Confluent Cloud est validé pour les topics, les ACL, les schémas et l'import ; Cloud n'expose pas les API de quotas et de SCRAM. Les versions testées figurent sur la page plateformes prises en charge (en anglais).
En quoi est-il différent de Jikkou ?
Les deux gèrent Kafka comme du code. monedula-gitops déclare les accès sur le topic lui-même, s'exécute aussi bien comme CLI que comme opérateur Kubernetes qui réconcilie en continu, et gère les bindings de rôles de Confluent Platform via MDS. Jikkou s'exécute comme CLI ou comme serveur d'API et couvre davantage de plateformes et de types de ressources, comme les connecteurs Kafka Connect et les bindings de rôles de Confluent Cloud. La page de comparaison (en anglais) détaille les différences, avec la date de leur vérification.

Assistance

L’aide de ceux qui le développent

Nous pouvons vous aider à mettre en œuvre monedula-gitops sur un parc étendu, de la conception à l’exploitation au quotidien.

Parlons-en

Fait partie de
Monedula Flock

D’autres outils gratuits pour Apache Kafka, par la même équipe. À propos de Flock