Belajar Apache Kafka - CI/CD & Infrastructure as Code

#Pendahuluan

Cluster Kafka yang dikonfigurasi lewat CLI yang dijalankan manual adalah sumber ketidakkonsistenan: tidak ada yang tahu persis konfigurasi produksi, dan perubahan sulit diaudit. Infrastructure as Code (IaC) memindahkan semua definisi — cluster, topic, ACL, skema, connector — ke repositori yang ter-version control.

Episode 31 ini akan membahas Terraform untuk infrastruktur Kafka, konfigurasi topic dan ACL sebagai code, pipeline CI/CD untuk pengujian dan deployment bertahap, serta GitOps dengan ArgoCD dan Flux untuk sinkronisasi otomatis.

#Infrastructure as Code

#Terraform untuk Kafka

Terraform bisa mengelola cluster Kafka cloud (MSK, Confluent) maupun resource Kafka itu sendiri (topic, ACL) lewat provider:

resource "aws_msk_cluster" "orders" {
  cluster_name  = "orders-kafka"
  kafka_version = "3.7.0"
  number_of_broker_nodes = 3
  broker_node_group_info {
    instance_type   = "kafka.m7g.large"
    client_subnets  = [aws_subnet.a.id, aws_subnet.b.id, aws_subnet.c.id]
  }
}

aws_msk_cluster mendeklarasikan cluster beserta versi dan instance. Karena definisi ada di code, setiap perubahan cluster melalui pull request dan bisa di-review sebelum diterapkan.

#Kubernetes Manifests dan Ansible

• Strimzi (episode 28): cluster, user, dan topic dideklarasikan sebagai CRD YAML dalam repositori — kombinasi sempurna dengan GitOps.
• Ansible: untuk provisioning node Kafka self-managed — install, konfigurasi server.properties, dan service management secara repeatable.
• CloudFormation/ARM: template AWS dan Azure untuk mereka yang sudah berinvestasi di ekosistem tersebut.

#Configuration as Code

#Topic dan ACL Definitions

Definisikan topic dan ACL dalam file yang bisa di-review dan diuji:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: orders
spec:
  partitions: 6
  replicas: 3
  config:
    cleanup.policy: delete
    retention.ms: 604800000

partitions: 6 dan config.retention.ms mendokumentasikan niat dengan jelas. Version control memberi histori: kapan topic diubah, oleh siapa, dan alasan apa.

#Schema dan Connector Config

• Skema: simpan skema Avro/Protobuf (episode 7) di repositori dan daftarkan lewat pipeline — perubahan skema melalui review dan kompatibilitas teruji.
• Connector: konfigurasi connector Kafka Connect (episode 12) disimpan sebagai JSON/YAML dan diterapkan lewat REST API dalam pipeline.

#Version Control Strategy

Satu repositori per service atau monorepo dengan direktori per environment (dev, staging, prod) adalah pilihan yang umum. Kunci utamanya: perubahan melewati pull request, ada review, dan penerapan otomatis — sehingga drift antar environment bisa dicegah.

#CI/CD Pipelines

#Automated Testing

Pipeline CI menjalankan pengujian sebelum perubahan diterapkan:

• Unit dan integration test untuk aplikasi klien (episode 32).
• Schema validation: uji kompatibilitas skema baru terhadap yang lama (backward/full).
• Contract testing: pastikan producer dan consumer memahami format yang sama.
• Performance testing: benchmark dampak perubahan konfigurasi sebelum produksi.

#Canary dan Blue-Green

Deployment aplikasi Kafka bisa memakai pola deployment umum:

• Canary: perkenalkan versi baru pada sebagian traffic; pantau metrik dan lag; jika sehat, perluas.
• Blue-green: dua environment; pindahkan seluruh klien dari versi lama ke baru setelah validasi; rollback cepat dengan memindahkan kembali.

Keduanya sangat berguna saat mengubah logika consumer atau skema — di mana kesalahan terdeteksi lebih baik di sebagian traffic daripada seluruhnya.

#GitOps Workflows

#ArgoCD dan Flux

GitOps menjadikan repositori git sebagai sumber kebenaran tunggal. ArgoCD atau Flux memantau repositori dan menyinkronkan state ke cluster secara otomatis:

argocd app sync kafka-stack

argocd app sync kafka-stack menarik definisi terbaru dari git dan menerapkannya. Semua perubahan harus lewat commit; operator menolak perubahan manual yang menyimpang dari git.

#Declarative Config, Drift, dan Rollback

• Declarative configurations: state diinginkan dinyatakan penuh; operator mewujudkannya.
• Drift detection: ArgoCD menandai perbedaan antara state git dan state aktual — memicu investigasi atau auto-sync.
• Rollback: karena setiap state ada di git, rollback cukup revert commit — operator mengembalikan semuanya ke versi sebelumnya.

#Penutup

Di episode 31 ini kalian sudah memahami infrastructure as code dengan Terraform, definisi topic, ACL, skema, dan connector sebagai code, pipeline CI/CD dengan testing dan canary deployment, serta GitOps dengan ArgoCD dan Flux.

Inti yang harus dibawa pulang:

• Definisi cluster, topic, dan ACL sebaiknya di-version control.
• Terraform dan Strimzi CRD adalah cara utama deklarasi infrastruktur.
• Uji skema dan kontrak di pipeline sebelum deployment.
• Canary dan blue-green mengurangi risiko perubahan klien.
• GitOps menjadikan git sebagai sumber kebenaran tunggal.
• Drift detection dan rollback otomatis menjaga konsistensi produksi.

Di episode 32 selanjutnya kita akan membahas strategi testing — unit test producer, consumer, dan topologi Streams, integration test dengan Testcontainers dan embedded Kafka, performance test dengan kafka-producer-perf-test, serta chaos engineering untuk menguji kegagalan.