---
title: "monedula-gitops"
repo: https://github.com/monedula-dev/monedula-gitops
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **Article associé :** [Monedula GitOps : la gestion déclarative de Kafka pour la CLI et Kubernetes](/blog/monedula-gitops/) présente la version `v0.1.0`, le modèle de ressources et le flux de travail de base.

## Pourquoi

La configuration de Kafka vit rarement au même endroit. Les topics viennent
d'un script, les ACL d'un autre, les schémas des pipelines applicatifs, les
quotas de l'administration et les role bindings RBAC de Confluent d'un outil
encore différent. Avec le temps, le cluster en production devient la seule
description fiable du système — mais une description ni intentionnelle ni
relisible.

`monedula-gitops` rend cette description explicite : décrire l'état Kafka
souhaité dans Git, le relire comme du code, le comparer au cluster en
production et faire converger le cluster vers lui.

Kafka, ce n'est pas seulement des topics : le modèle couvre donc les
ressources qui vont généralement ensemble — règles d'accès, groupes de
consommateurs, quotas, schémas, identifiants et, sur Confluent Platform, role
bindings RBAC.

## Un modèle, deux runtimes

La CLI et l'opérateur Kubernetes utilisent le même modèle de ressources et le
même moteur de réconciliation.

- **CLI** — valider, comparer, appliquer et vérifier les manifestes depuis un
  poste de développement ou un pipeline CI/CD. `verify` renvoie un code de
  sortie non nul lorsqu'un drift est détecté : il fait office de garde-fou de
  CI.
- **Opérateur** — installer ces mêmes ressources de style Kubernetes en tant
  que CRD et les réconcilier en continu dans un cluster.

Les identifiants sont fournis différemment dans chaque runtime — références
d'environnement ou de fichiers pour la CLI, Secrets Kubernetes pour
l'opérateur — mais l'état souhaité, les règles de drift et la sémantique
d'exécution restent cohérents. Une équipe peut commencer par des changements
pilotés par le pipeline et adopter l'opérateur plus tard, sans concevoir un
second modèle de configuration.

## Ce qu'il gère

`KafkaCluster` (connexion, authentification, valeurs par défaut, Schema
Registry, Confluent MDS optionnel), `KafkaTopic` (cycle de vie, partitions,
configuration, accès local au topic, schémas), `KafkaAccessPolicy` (règles ACL
avancées et partagées), `KafkaQuota` (quotas par utilisateur, client-id et
IP), `KafkaUser` (identifiants SCRAM) et `KafkaRoleBinding` (MDS/RBAC
Confluent).

Le cas courant reste petit : un topic et les applications autorisées à
l'utiliser tiennent dans un seul manifeste, d'où sont générées les ACL de
topic et de groupe de consommateurs correspondantes :

```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
```

## Installation

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

Également disponible via `go install`, sous forme de binaires précompilés dans
les releases GitHub et d'image de conteneur sur
`ghcr.io/monedula-dev/monedula-gitops`. L'opérateur s'installe avec Helm
depuis `oci://ghcr.io/monedula-dev/charts/monedula-gitops`.

## Partir d'un cluster existant

Les environnements réels sont rarement vides : `import cluster` lit l'état
Kafka actuel et en génère des manifestes — topics, règles d'accès, quotas,
schémas, utilisateurs SCRAM et role bindings RBAC de Confluent là où c'est
pris en charge. Tout l'intérêt est l'aller-retour : vérifier le répertoire
importé face au même cluster ne devrait signaler aucun drift.

Les opérations risquées sont protégées, et la suppression comme le pruning
exigent une activation explicite. Le dépôt contient deux quickstarts
exécutables (un terrain de jeu CLI avec Docker Compose et un terrain de jeu
opérateur sur Kubernetes local) ainsi qu'un catalogue de 25 scénarios
autonomes.