Belajar RabbitMQ - CI/CD, Infrastructure as Code & GitOps

#Pendahuluan

Sampai di sini, hampir semua konfigurasi RabbitMQ kita lakukan manual: mengetik rabbitmqadmin declare, rabbitmqctl set_policy, dan add_user satu per satu. Ini cepat untuk belajar, tapi bencana untuk produksi. Siapa yang menjamin cluster staging identik dengan production? Siapa yang tahu perubahan terakhir sebelum insiden?

Jawabannya: Infrastructure as Code (IaC). Konfigurasi RabbitMQ ditulis sebagai file yang bisa di-versioning, direview, dan dieksekusi ulang. Queue, exchange, policy, user, dan permission didefinisikan sebagai JSON atau kode, dan dikelola lewat pipeline CI/CD.

Episode ini membawa kalian dari definisi JSON, otomasi dengan Terraform dan Ansible, pengujian alur pesan di pipeline, hingga GitOps — di mana Git menjadi satu-satunya sumber kebenaran dan sinkronisasi berjalan otomatis.

#Infrastructure as Code

#Definisi sebagai JSON

Semua definisi RabbitMQ bisa diekspor dan diimpor sebagai JSON. File ini adalah representasi lengkap topologi — queue, exchange, binding, policy, dan permission:

{
  "vhosts": [{"name": "prod"}],
  "queues": [
    {"name": "orders.q", "vhost": "prod", "durable": true,
     "arguments": {"x-queue-type": "quorum"}}
  ],
  "exchanges": [
    {"name": "orders", "vhost": "prod", "type": "topic"}
  ],
  "bindings": [
    {"source": "orders", "vhost": "prod", "destination": "orders.q",
     "routing_key": "order.*"}
  ],
  "policies": [
    {"vhost": "prod", "name": "ha", "pattern": "^orders\\.",
     "definition": {"max-length": 10000}}
  ]
}

File di atas mendeklarasikan vhost, quorum queue, exchange topic, binding, dan policy — semuanya dalam satu dokumen yang bisa di-commit ke Git.

#Terraform dan Ansible

Terraform memiliki provider RabbitMQ yang mendeklarasikan resource secara idempotent. Ansible bisa mengeksekusi perintah rabbitmqctl lewat modul. Pilih sesuai budaya tim: Terraform untuk resource-cloud style, Ansible untuk pengelolaan server yang ada. Yang terpenting, keduanya mengotomatiskan aplikasi definisi JSON di atas ke setiap environment.

Contoh deklarasi queue dengan Terraform:

resource "rabbitmq_queue" "orders" {
  name    = "orders.q"
  vhost   = rabbitmq_vhost.prod.name
  settings {
    durable = true
    arguments = { "x-queue-type" = "quorum" }
  }
}

Dengan pola ini, environment staging dan production didefinisikan dari kode yang sama — perbedaannya hanya pada nilai variable.

#CI/CD Integration

#Menguji Alur Pesan

Pipeline CI/CD harus menguji bahwa alur pesan bekerja. Terapkan smoke test: jalankan broker test, publish pesan, dan verifikasi consumer menerimanya. Ini menangkap regresi sebelum sampai ke production:

python producer.py --queue smoke && python consumer.py --once --queue smoke

#Load Testing dengan PerfTest

PerfTest adalah alat resmi untuk benchmark RabbitMQ. Jalankan di pipeline untuk membandingkan performa sebelum dan sesudah perubahan konfigurasi:

rabbitmq-perf-test --uri amqp://localhost --queue bench \
  --producers 4 --consumers 4 --time 60

Perintah rabbitmq-perf-test menjalankan publisher dan consumer selama 60 detik, menghasilkan metrik throughput dan latency untuk baseline.

#Blue-Green dan Canary Release

Untuk perubahan topologi yang berisiko, pakai blue-green: jalankan topologi baru (green) paralel dengan yang lama (blue), pindahkan trafik bertahap, lalu matikan yang lama. Canary release mengarahkan sebagian kecil trafik ke konfigurasi baru lebih dulu — jika metrik sehat, perluas sisanya.

#GitOps Workflows

#Git sebagai Sumber Kebenaran

Dalam GitOps, Git adalah satu-satunya sumber kebenaran. Setiap perubahan konfigurasi lewat pull request yang di-review; cluster dilarang diubah manual. Tools seperti ArgoCD dan Flux menyinkronkan state Git ke cluster secara otomatis.

#Deteksi Drift Konfigurasi

Jika ada yang mengubah cluster secara manual, sinkronisasi GitOps berikutnya akan mendeteksi drift dan mengembalikan state sesuai Git (atau meng-alert). Inilah cara menjaga konsistensi antar environment tanpa memercayai ingatan manusia.

#Penutup

Di episode 30 ini kalian sudah mendefinisikan topologi RabbitMQ sebagai JSON, mengotomasi dengan Terraform dan Ansible, menguji alur pesan dengan smoke test dan PerfTest, serta menerapkan GitOps dengan ArgoCD, Flux, dan deteksi drift.

Inti yang harus dibawa pulang:

• Topologi lengkap bisa dideklarasikan sebagai satu file JSON.
• Terraform dan Ansible mengotomasi aplikasi definisi ke environment.
• Smoke test publish-consume menangkap regresi di pipeline.
• PerfTest memberi baseline performa yang bisa dibandingkan.
• Blue-green dan canary mengurangi risiko perubahan topologi.
• Git menjadi sumber kebenaran; perubahan melewati review.
• ArgoCD dan Flux menyinkronkan otomatis dan mendeteksi drift.

Di episode 31 selanjutnya kita akan menyusun backup, restore dan disaster recovery — mengekspor definisi, menyusun strategi backup pesan, memulihkan dengan import definisi, merencanakan RPO dan RTO, memakai Federation dan Shovel untuk DR, serta melakukan migrasi antar cluster tanpa downtime. Ini jaring pengaman terakhir sebelum produksi!