---
title: "monedula-gitops"
repo: https://github.com/monedula-dev/monedula-gitops
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **Powiązany wpis:** [Monedula GitOps: deklaratywne zarządzanie Kafką dla CLI i Kubernetesa](/blog/monedula-gitops/) przedstawia wydanie `v0.1.0`, model zasobów i podstawowy przepływ pracy.

## Dlaczego

Konfiguracja Kafki rzadko mieszka w jednym miejscu. Tematy pochodzą z jednego
skryptu, ACL-e z drugiego, schematy z pipeline'ów aplikacji, limity od
administratora, a powiązania ról Confluent RBAC z jeszcze innego narzędzia.
Z czasem jedynym wiarygodnym opisem systemu staje się działający klaster —
opisem, którego nikt nie zaprojektował i którego nie da się przejrzeć.

`monedula-gitops` czyni ten opis jawnym: opisz pożądany stan Kafki w Gicie,
przejrzyj go jak kod, porównaj z działającym klastrem i doprowadź klaster do
tego stanu.

Kafka to nie tylko tematy, więc model obejmuje te zasoby, które zwykle idą
w parze — reguły dostępu, grupy konsumentów, limity, schematy, poświadczenia,
a w Confluent Platform także powiązania ról RBAC.

## Jeden model, dwa środowiska uruchomieniowe

CLI i operator Kubernetesa używają tego samego modelu zasobów i tego samego
silnika uzgadniania.

- **CLI** — waliduj, porównuj, stosuj i weryfikuj manifesty z maszyny
  dewelopera albo z pipeline'u CI/CD. `verify` zwraca niezerowy kod wyjścia,
  gdy wykryje dryf, więc działa jako bramka w CI.
- **Operator** — zainstaluj te same zasoby w stylu Kubernetesa jako CRD
  i uzgadniaj je w sposób ciągły wewnątrz klastra.

Poświadczenia dostarcza się inaczej w każdym środowisku — przez zmienne
środowiskowe lub odwołania do plików w CLI, przez Sekrety Kubernetesa
w operatorze — ale pożądany stan, reguły dryfu i semantyka wykonania
pozostają spójne. Zespół może zacząć od zmian sterowanych pipeline'em
i wdrożyć operator później, bez projektowania drugiego modelu konfiguracji.

## Czym zarządza

`KafkaCluster` (połączenie, uwierzytelnianie, wartości domyślne, Schema
Registry, opcjonalnie Confluent MDS), `KafkaTopic` (cykl życia, partycje,
konfiguracja, dostęp lokalny dla tematu, schematy), `KafkaAccessPolicy`
(zaawansowane i współdzielone reguły ACL), `KafkaQuota` (limity dla
użytkownika, client-id i IP), `KafkaUser` (poświadczenia SCRAM) oraz
`KafkaRoleBinding` (Confluent MDS/RBAC).

Najczęstszy przypadek pozostaje drobny — temat i aplikacje, które mają prawo
z niego korzystać, mieszczą się w jednym manifeście, a odpowiadające im ACL-e
tematu i grupy konsumentów są z niego generowane:

```yaml
apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaTopic
metadata:
  name: orders
spec:
  clusterRef:
    name: prod
  topicName: orders
  partitions: 6
  access:
    producers:
      - principal: User:svc-checkout
    consumers:
      - principal: User:svc-fraud
        group: fraud-orders
```

## Instalacja

```bash
brew install monedula-dev/tap/monedula-gitops
```

Dostępne także przez `go install`, jako gotowe binaria z wydań na GitHubie
oraz jako obraz kontenera pod `ghcr.io/monedula-dev/monedula-gitops`.
Operator instaluje się Helmem z
`oci://ghcr.io/monedula-dev/charts/monedula-gitops`.

## Zacznij od istniejącego klastra

Prawdziwe środowiska rzadko są puste, więc `import cluster` odczytuje bieżący
stan Kafki i generuje z niego manifesty — tematy, reguły dostępu, limity,
schematy, użytkowników SCRAM oraz powiązania ról Confluent RBAC tam, gdzie
jest to wspierane. Chodzi o podróż w obie strony: weryfikacja zaimportowanego
katalogu wobec tego samego klastra nie powinna zgłosić żadnego dryfu.

Ryzykowne operacje są zabezpieczone, a usuwanie i przycinanie wymagają
wyraźnej zgody. W repozytorium są dwa gotowe do uruchomienia quickstarty
(plac zabaw dla CLI na Docker Compose i plac zabaw dla operatora na lokalnym
Kubernetesie) oraz katalog 25 samodzielnych scenariuszy.