Apache Kafka のための GitOps

トピック、アクセス、クォータ、スキーマ、SCRAM ユーザー、Confluent RBAC を Git 上の YAML として記述しておけば、monedula-gitops がそれを稼働中のクラスターと比較し、変わった部分だけを適用し、クラスターにドリフトが生じると CI を失敗させます。同じマニフェストを CLI からも Kubernetes オペレーターからも実行できます。

はじめる（英語） 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

ターミナル

$ 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: リソースの種類。トピックから Confluent RBAC のロールバインディングまで
8: CI でテスト済みのブローカーイメージ：Apache Kafka 3.9 から 4.3、Confluent Platform 7.6 から 8.3
25: リポジトリにある実行可能なシナリオ。それぞれエンドツーエンドで確認済み

課題

Kafka の設定が一か所にまとまっていることは、めったにありません。

トピックはあるスクリプトから、ACL は別のスクリプトから、スキーマはアプリケーションのパイプラインから、クォータは管理者から、Confluent RBAC のロールバインディングはさらに別のツールから生まれます。時間が経つと、システムを記述しているのは稼働中のクラスターだけになり、その記述は誰もレビューしていません。

仕組み

01 import cluster
インポート

稼働中のクラスターをマニフェストに変換します。
02 YAML + pull request
宣言

Kubernetes スタイルの YAML で書かれた、トピック、アクセス、クォータ、スキーマ、SCRAM ユーザー、ロールバインディング。
03 diff
差分

diff と apply --dry-run が、まず稼働中のクラスターに対する計画を表示します。
04 apply
適用

必要な操作だけが実行されます。プルーニングとリスクのある変更は、明示的なフラグを指定するまで実行されません。
05 verify
検証

verify はドリフトを見つけると終了コード 1 を返すので、定期実行の CI ジョブで Git を経由しない変更を検出できます。

Git リポジトリ manifests/*.yaml、プルリクエストでレビュー
→
CI の CLI validate, diff, apply, verify
Kubernetes のオペレーター CRD、アドミッション Webhook、リコンサイルループ
→
Kafka トピック、ACL、クォータ、SCRAM ユーザー
Schema Registry と MDS スキーマ、Confluent RBAC のロールバインディング

Git 上のマニフェストが CI の CLI と Kubernetes のオペレーターを動かし、それらが Kafka、Schema Registry、MDS を変更します。

トピックとそのアクセスを、1 つのマニフェストに

ほとんどの Kafka ツールは、トピックをある場所に、そのアクセスを別の場所に置きます。monedula-gitops はアクセスをトピック自体に結び付けます。プロデューサーとコンシューマーを列挙すれば、対応するトピックとコンシューマーグループの ACL が生成されます。RBAC を使うクラスターでは、同じブロックを Confluent MDS のロールバインディングにコンパイルすることもできます。

プレフィックス付きのパターン、共有のコンシューマーグループ、ホストの制限が必要な場合は、独立した KafkaAccessPolicy リソースと KafkaRoleBinding リソースが使えます。

Strimzi: KafkaTopic + KafkaUser
Confluent for Kubernetes: トピック + 別個のロールバインディングリソース
Jikkou: トピック + 別個のプリンシパルリソース
Terraform: ACL ごとに 1 リソース
monedula-gitops: access ブロックを持つ 1 つの KafkaTopic

既存のクラスターをインポート

import cluster はトピック、ACL、クォータ、スキーマ、そしてサポートされている場合は RBAC のロールバインディングを読み取り、マニフェストを書き出します。そのマニフェストを同じクラスターに対して検証すると、ドリフトは報告されません。

クラスターをインポートする方法（英語）

ターミナル

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

SCRAM ユーザーと Confluent RBAC のロールバインディング

KafkaUser は SCRAM 認証情報を宣言するので、トピック、そのアクセス、それを使うプリンシパルが Git にまとめて置かれます。CLI はパスワードを環境変数またはファイルから読み取り、オペレーターは Kubernetes の Secret から読み取るか、パスワードを生成します。

KafkaRoleBinding は、ACL と並べて Confluent MDS のロールバインディングを管理します。

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 }

うっかり削除されるものはありません

--dry-run はすべての変更をプレビューします。Git から取り除いたトピック、SCRAM ユーザー、クォータを、CLI が削除することはありません。--prune が削除するのは、マニフェストがまだ宣言している権限付与の範囲内にある ACL とロールバインディングだけです。パーティションの増加、スキーマ互換性の引き下げ、クォータ上限の削除のようなリスクのある変更は --allow-destructive を待ちます。Kubernetes では、トピックの削除ポリシーによって、リソースを削除したときにトピックも削除されるかどうかが決まり、Delete にはさらに allow-delete アノテーションが必要です。

安全ゲート（英語）

終了コード
0	成功、または `verify` でドリフトなし
1	ドリフトを検出（`verify`）
2	バリデーション、設定、接続のエラー、または操作の失敗
3	ゲート付きの操作だけが残っています。`--allow-destructive` を待っています

インストール

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

Linux と macOS 向けのビルド済みバイナリはリリースページにあります。次のステップ：CLI を使い始める（英語）。

よくある質問

monedula-gitops は無料ですか？仕事で使えますか？

はい、AGPL-3.0 ライセンスで有料版はなく、自分たちのクラスターで CLI として、または自社インフラ内のオペレーターとして使っても、コードやマニフェストを公開する義務は生じません。AGPL の義務は、改変の有無にかかわらずソフトウェアを配布する場合、または改変版をネットワーク経由で他者に利用させる場合に適用されます。商用ライセンスについては、お問い合わせください。

Confluent Platform や Confluent Cloud でも動きますか？

Apache Kafka と Confluent Platform を完全にサポートしており、Schema Registry や、Confluent Platform では MDS のロールバインディングも対象です。Confluent Cloud はトピック、ACL、スキーマ、インポートについて動作確認済みです。Cloud はクォータと SCRAM の API を公開していません。テスト済みのバージョンはサポート対象のプラットフォーム（英語）をご覧ください。

Jikkou とは何が違いますか？

どちらも Kafka をコードとして管理します。monedula-gitops はトピック自体にアクセスを宣言し、CLI としてだけでなく継続的にリコンサイルする Kubernetes オペレーターとしても動作し、MDS を通じて Confluent Platform のロールバインディングを管理します。Jikkou は CLI または API サーバーとして動作し、Kafka Connect のコネクターや Confluent Cloud のロールバインディングなど、より多くのプラットフォームとリソースの種類をカバーします。比較ページ（英語）に、確認した日付とともに詳細をまとめています。