---
title: "monedula-gitops"
repo: https://github.com/monedula-dev/monedula-gitops
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **関連記事：** [Monedula GitOps — CLI と Kubernetes のための宣言的な Kafka 管理](/blog/monedula-gitops/) では、`v0.1.0` リリース、リソースモデル、基本的なワークフローを紹介しています。

## なぜ

Kafka の設定が一か所にまとまっていることは、めったにありません。トピックは
あるスクリプトから、ACL は別のスクリプトから、スキーマはアプリケーションの
パイプラインから、クォータは管理者から、Confluent RBAC のロールバインディング
はさらに別のツールから生まれます。時間が経つと、稼働中のクラスタだけが
システムの唯一の信頼できる記述になります — 意図して書かれたものでも、
レビューできるものでもない記述が。

`monedula-gitops` は、その記述を明示的なものにします。あるべき Kafka の状態を
Git に記述し、コードと同じようにレビューし、稼働中のクラスタと比較し、
クラスタをその状態へ収束させます。

Kafka はトピックだけではないので、モデルはふつう一緒に扱われるリソース —
アクセスルール、コンシューマーグループ、クォータ、スキーマ、認証情報、そして
Confluent Platform ではロールバインディング — までをカバーします。

## 1 つのモデル、2 つのランタイム

CLI と Kubernetes オペレーターは、同じリソースモデルと同じリコンサイル
エンジンを使います。

- **CLI** — 開発マシンや CI/CD パイプラインから、マニフェストを検証し、
  差分を取り、適用し、確認します。`verify` はドリフトを見つけると 0 以外の
  終了コードを返すので、CI のゲートとして機能します。
- **オペレーター** — 同じ Kubernetes スタイルのリソースを CRD として
  インストールし、クラスタ内で継続的にリコンサイルします。

認証情報の与え方はランタイムごとに異なります — CLI では環境変数やファイルの
参照、オペレーターでは Kubernetes の Secret です — が、あるべき状態、
ドリフトのルール、実行のセマンティクスは一貫しています。チームはまず
パイプライン駆動の変更から始め、2 つ目の設定モデルを設計することなく、
後からオペレーターを導入できます。

## 管理できるもの

`KafkaCluster`（接続、認証、デフォルト値、Schema Registry、任意の Confluent
MDS）、`KafkaTopic`（ライフサイクル、パーティション、設定、トピックローカルな
アクセス、スキーマ）、`KafkaAccessPolicy`（高度な、あるいは共有される ACL
ルール）、`KafkaQuota`（ユーザー、client-id、IP のクォータ）、`KafkaUser`
（SCRAM 認証情報）、`KafkaRoleBinding`（Confluent MDS/RBAC）。

よくあるケースは小さいままです。トピックとその利用を許可されたアプリケーション
は 1 つのマニフェストに収まり、対応するトピックとコンシューマーグループの ACL
はそこから生成されます。

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

## インストール

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

`go install`、GitHub リリースのビルド済みバイナリ、
`ghcr.io/monedula-dev/monedula-gitops` のコンテナイメージも利用できます。
オペレーターは Helm で `oci://ghcr.io/monedula-dev/charts/monedula-gitops`
からインストールします。

## 既存クラスタから始める

現実の環境が空であることはまずないので、`import cluster` は現在の Kafka の
状態を読み取り、そこからマニフェストを生成します — トピック、アクセスルール、
クォータ、スキーマ、SCRAM ユーザー、そしてサポートされている場合は Confluent
RBAC のロールバインディングまで。大事なのはラウンドトリップです。インポート
したディレクトリを同じクラスタに対して検証すると、ドリフトは報告されないはず
です。

リスクのある操作にはガードがかかっており、削除とプルーニングは明示的に
有効化しないと実行されません。リポジトリには、実行できるクイックスタートが
2 つ（Docker Compose の CLI プレイグラウンドと、ローカル Kubernetes 上の
オペレーターのプレイグラウンド）と、25 個の自己完結したシナリオのカタログが
入っています。