Monedula

Esta página se tradujo automáticamente del inglés. Leer el original

monedula-gitops v1.0.0, AGPL-3.0

GitOps para Apache Kafka

Describe topics, acceso, cuotas, esquemas, usuarios SCRAM y RBAC de Confluent como YAML en Git. monedula-gitops lo compara con el clúster en vivo, aplica solo lo que ha cambiado y hace fallar la CI cuando hay drift. Los mismos manifiestos se ejecutan desde una CLI o un operador de Kubernetes.

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
Empezar (en inglés) GitHub
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.

El problema

La configuración de Kafka rara vez vive en un solo sitio.

Los topics vienen de un script, las ACL de otro, los esquemas de los pipelines de las aplicaciones, las cuotas de un administrador y los role bindings RBAC de Confluent de otra herramienta más. Con el tiempo, solo el clúster en vivo describe el sistema, y nadie ha revisado esa descripción.

6
tipos de recursos, de los topics a los role bindings RBAC de Confluent
8
imágenes de broker probadas en CI: Apache Kafka 3.9 a 4.3, Confluent Platform 7.6 a 8.3
25
escenarios ejecutables en el repositorio, cada uno comprobado de principio a fin

Cómo funciona

  1. 01

    Importar import cluster

    Convierte un clúster en vivo en manifiestos.

  2. 02

    Declarar YAML + pull request

    Topics, acceso, cuotas, esquemas, usuarios SCRAM y role bindings como YAML al estilo Kubernetes.

  3. 03

    Comparar diff

    diff y apply --dry-run muestran primero el plan frente al clúster en vivo.

  4. 04

    Aplicar apply

    Solo se ejecutan las operaciones necesarias. El pruning y los cambios arriesgados esperan flags explícitos.

  5. 05

    Verificar verify

    verify termina con código 1 si hay drift, así que un job de CI programado detecta los cambios hechos fuera de Git.

  1. Repositorio Git manifests/*.yaml, revisados en pull requests
  2. CLI en CI validate, diff, apply, verify
    Operador en Kubernetes CRD, webhooks de admisión, bucle de reconciliación
  3. Kafka topics, ACL, cuotas, usuarios SCRAM
    Schema Registry y MDS esquemas, role bindings RBAC de Confluent
Los manifiestos en Git dirigen la CLI en CI y el operador en Kubernetes, que modifican Kafka, Schema Registry y MDS.

Un topic y su acceso, en un solo manifiesto

La mayoría de las herramientas de Kafka guardan un topic en un sitio y su acceso en otro. monedula-gitops vincula el acceso al propio topic: enumera los productores y los consumidores, y se generan las ACL de topic y de grupo de consumidores correspondientes. En clústeres con RBAC, el mismo bloque puede compilarse en role bindings de Confluent MDS.

Cuando necesitas patrones con prefijo, grupos de consumidores compartidos o restricciones de host, tienes los recursos independientes KafkaAccessPolicy y KafkaRoleBinding.

Strimzi
KafkaTopic + KafkaUser
Confluent for Kubernetes
topic + recursos de role binding separados
Jikkou
topic + recursos de principal separados
Terraform
un recurso por ACL
monedula-gitops
un KafkaTopic con un bloque access

Importa un clúster existente

import cluster lee topics, ACL, cuotas, esquemas y, donde hay soporte, role bindings RBAC, y escribe manifiestos. Verificarlos contra el mismo clúster no reporta ningún drift.

Cómo importar un clúster (en inglés)

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

Usuarios SCRAM y role bindings RBAC de Confluent

Un KafkaUser declara una credencial SCRAM, así que el topic, su acceso y el principal que lo usa se definen juntos en Git. La CLI lee la contraseña de una variable de entorno o de un archivo; el operador la lee de un Secret de Kubernetes, o genera una.

KafkaRoleBinding gestiona los role bindings de Confluent MDS junto a las 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 }

Nada se elimina por accidente

--dry-run previsualiza cada cambio. La CLI nunca elimina un topic, un usuario SCRAM o una cuota que quites de Git. --prune solo elimina ACL y role bindings que caen dentro de un permiso que tus manifiestos todavía declaran, y los cambios arriesgados, como aumentar el número de particiones, rebajar la compatibilidad de un esquema o quitar un límite de cuota, esperan a --allow-destructive. En Kubernetes, la política de eliminación de un topic decide si eliminar el recurso también elimina el topic, y Delete requiere además la anotación allow-delete.

Las barreras de seguridad (en inglés)

Códigos de salida
0Éxito, o ningún drift para verify
1Drift detectado (verify)
2Error de validación, de configuración o de conexión, o una operación fallida
3Solo quedan operaciones protegidas: esperan a --allow-destructive

Instalación

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

Hay binarios precompilados para Linux y macOS en la página de releases. Siguiente paso: primeros pasos con la CLI (en inglés).

Preguntas

¿monedula-gitops es gratuito y puedo usarlo en el trabajo?
Sí. Tiene licencia AGPL-3.0, sin edición de pago, y usarlo en tus propios clústeres, como CLI o como operador en tu propia infraestructura, no te obliga a compartir tu código ni tus manifiestos: las obligaciones de la AGPL se aplican cuando lo distribuyes, modificado o no, o cuando permites que otros usen una versión modificada a través de una red. Para una licencia comercial, contáctanos.
¿Funciona con Confluent Platform y Confluent Cloud?
Apache Kafka y Confluent Platform tienen soporte completo, incluidos Schema Registry y, en Confluent Platform, los role bindings de MDS. Confluent Cloud está validado para topics, ACL, esquemas e importación; Cloud no expone las API de cuotas ni de SCRAM. Consulta las versiones probadas en plataformas compatibles (en inglés).
¿En qué se diferencia de Jikkou?
Ambas gestionan Kafka como código. monedula-gitops declara el acceso en el propio topic, se ejecuta tanto como CLI como operador de Kubernetes que reconcilia de forma continua, y gestiona los role bindings de Confluent Platform a través de MDS. Jikkou se ejecuta como CLI o como servidor de API y cubre más plataformas y tipos de recursos, como los conectores de Kafka Connect y los role bindings de Confluent Cloud. La página de comparación (en inglés) recoge los detalles, con la fecha en que se comprobaron.

Soporte

Ayuda de quienes lo desarrollan

Podemos ayudarte a usar monedula-gitops en una infraestructura grande, desde el diseño hasta la operación diaria.

Habla con nosotros

Parte de
Monedula Flock

Más herramientas gratuitas para Apache Kafka del mismo equipo. Acerca de Flock