Esta página foi traduzida automaticamente do inglês. Ler o original

monedula-gitops v0.1.0, AGPL-3.0

GitOps para Apache Kafka

Descreva tópicos, acesso, cotas, esquemas, usuários SCRAM e RBAC do Confluent como YAML no Git. O monedula-gitops compara tudo isso com o cluster em execução, aplica só o que mudou e faz a CI falhar quando há drift no cluster. Os mesmos manifestos rodam a partir de uma CLI ou de um operador de Kubernetes.

Começar (em inglês) 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 to$ monedula-gitops apply -f ./manifests --cluster-config-file ./cluster.yaml$ monedula-gitops verify -f ./manifests --cluster-config-file ./cluster.yaml# exit 0: no drift. exit 1: drift, and the CI job fails.

6: tipos de recurso, de tópicos a role bindings RBAC do Confluent
8: imagens de broker testadas na CI: Apache Kafka 3.9 a 4.3, Confluent Platform 7.6 a 8.3
25: cenários executáveis no repositório, cada um verificado de ponta a ponta

O problema

A configuração do Kafka raramente fica em um só lugar.

Os tópicos vêm de um script, as ACLs de outro, os esquemas dos pipelines das aplicações, as cotas de um administrador e os role bindings RBAC do Confluent de mais uma ferramenta. Com o tempo, só o cluster em execução descreve o sistema, e ninguém revisou essa descrição.

Como funciona

01 import cluster
Importar

Transforme um cluster em execução em manifestos.
02 YAML + pull request
Declarar

Tópicos, acesso, cotas, esquemas, usuários SCRAM e role bindings como YAML no estilo Kubernetes.
03 diff
Comparar

diff e apply --dry-run mostram antes o plano em relação ao cluster em execução.
04 apply
Aplicar

Só as operações necessárias são executadas. O pruning e as mudanças arriscadas esperam flags explícitas.
05 verify
Verificar

verify sai com código 1 quando há drift, então um job agendado de CI detecta mudanças feitas fora do Git.

Repositório Git manifests/*.yaml, revisados em pull requests
→
CLI na CI validate, diff, apply, verify
Operador no Kubernetes CRDs, admission webhooks, loop de reconciliação
→
Kafka tópicos, ACLs, cotas, usuários SCRAM
Schema Registry e MDS esquemas, role bindings RBAC do Confluent

Os manifestos no Git acionam a CLI na CI e o operador no Kubernetes, que alteram o Kafka, o Schema Registry e o MDS.

Um tópico e seu acesso, em um só manifesto

A maioria das ferramentas de Kafka mantém um tópico em um lugar e o acesso a ele em outro. O monedula-gitops associa o acesso ao próprio tópico: liste os produtores e os consumidores, e as ACLs correspondentes de tópico e de grupo de consumidores são geradas. Em clusters com RBAC, o mesmo bloco pode ser compilado em role bindings do Confluent MDS.

Quando você precisa de padrões com prefixo, grupos de consumidores compartilhados ou restrições de host, existem os recursos independentes KafkaAccessPolicy e KafkaRoleBinding.

Strimzi: KafkaTopic + KafkaUser
Confluent for Kubernetes: tópico + recursos de role binding separados
Jikkou: tópico + recursos de principal separados
Terraform: um recurso por ACL
monedula-gitops: um KafkaTopic com um bloco access

Importe um cluster existente

import cluster lê tópicos, ACLs, cotas, esquemas e, onde houver suporte, role bindings RBAC, e escreve manifestos. Verificá-los contra o mesmo cluster não aponta nenhum drift.

Como importar um cluster (em 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

Usuários SCRAM e role bindings RBAC do Confluent

Um KafkaUser declara uma credencial SCRAM, então o tópico, o acesso a ele e o principal que o usa ficam juntos no Git. A CLI lê a senha de uma variável de ambiente ou de um arquivo; o operador a lê de um Secret do Kubernetes, ou gera uma.

KafkaRoleBinding gerencia role bindings do Confluent MDS junto com as 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 }

Nada é excluído por acidente

--dry-run pré-visualiza cada mudança. A CLI nunca exclui um tópico, usuário SCRAM ou cota que você remova do Git. --prune exclui apenas ACLs e role bindings que estejam dentro de uma permissão que seus manifestos ainda declaram, e mudanças arriscadas, como aumentar o número de partições, reduzir a compatibilidade de um esquema ou remover um limite de cota, esperam por --allow-destructive. No Kubernetes, a política de exclusão de um tópico decide se excluir o recurso também exclui o tópico, e Delete também exige a anotação allow-delete.

Travas de segurança (em inglês)

Códigos de saída
0	Sucesso, ou nenhum drift para `verify`
1	Drift detectado (`verify`)
2	Erro de validação, de configuração ou de conectividade, ou uma operação que falhou
3	Restam apenas operações protegidas: elas aguardam `--allow-destructive`

Instalação

HomebrewGoDockerHelm (operator)

Homebrew

brew install monedula-dev/tap/monedula-gitops

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

Binários pré-compilados para Linux e macOS estão na página de releases. Próximo passo: primeiros passos com a CLI (em inglês).

Perguntas

O monedula-gitops é gratuito e posso usá-lo no trabalho?

Sim. Ele é licenciado sob AGPL-3.0, sem edição paga, e usá-lo nos seus próprios clusters, como CLI ou como operador na sua própria infraestrutura, não obriga você a compartilhar seu código ou seus manifestos: as obrigações da AGPL se aplicam quando você o distribui, modificado ou não, ou permite que outros usem uma versão modificada por meio de uma rede. Para licenciamento comercial, entre em contato conosco.

Funciona com Confluent Platform e Confluent Cloud?

Apache Kafka e Confluent Platform têm suporte completo, incluindo o Schema Registry e, no Confluent Platform, os role bindings do MDS. O Confluent Cloud está validado para tópicos, ACLs, esquemas e importação; o Cloud não expõe as APIs de cotas e de SCRAM. Veja as versões testadas em plataformas suportadas (em inglês).

Qual é a diferença em relação ao Jikkou?

Os dois gerenciam Kafka como código. O monedula-gitops declara o acesso no próprio tópico, funciona tanto como CLI quanto como operador de Kubernetes que reconcilia continuamente, e gerencia role bindings do Confluent Platform via MDS. O Jikkou funciona como CLI ou servidor de API e cobre mais plataformas e tipos de recurso, como conectores do Kafka Connect e role bindings do Confluent Cloud. A página de comparação (em inglês) traz os detalhes, com a data em que foram verificados.

Suporte

Ajuda de quem desenvolve a ferramenta

Podemos ajudar você a rodar o monedula-gitops em um ambiente grande, do design às operações do dia a dia.

Fale com a gente

Parte do
Monedula Flock

Mais ferramentas gratuitas para Apache Kafka, da mesma equipe. Sobre o Flock

Go, AGPL-3.0, v0.10.0

monedula-acl-rbac-converter

CLI que converte ACLs do Apache Kafka em role bindings RBAC do Confluent via um plano com checksum e verifica o acesso efetivo antes de qualquer exclusão.

Página do produto Documentação (em inglês)

Java, AGPL-3.0, v0.10.0