Belajar RabbitMQ - Docker & Kubernetes Deployment

#Pendahuluan

Sejak episode 3 kalian menjalankan RabbitMQ di Docker dengan perintah docker run. Sekarang waktunya melakukannya dengan benar: konfigurasi melalui environment variables, penyimpanan yang tahan restart, clustering multi-kontainer, dan akhirnya deployment ke Kubernetes — tempat RabbitMQ produksi modern sebenarnya hidup.

Kubernetes membawa RabbitMQ ke level berikutnya: node-node di-replikasi lewat StatefulSet, disk disimpan di PersistentVolume, dan operator resmi mengelola seluruh siklus hidup cluster. Tanpa pengaturan yang tepat, RabbitMQ di K8s bisa kehilangan data — misalnya karena container di-restart tanpa volume.

Episode ini membangun fondasi Docker dulu, lalu menaikkan ke Kubernetes dengan praktik terbaik: operator, headless services, probe, dan strategi update yang aman.

#Docker Deployment

#Image Resmi dan Environment Variables

Gunakan image resmi dan konfigurasikan lewat environment variables:

docker run -d --name rabbitmq \
  -e RABBITMQ_DEFAULT_USER=arman \
  -e RABBITMQ_DEFAULT_PASS=Arman123 \
  -e RABBITMQ_DEFAULT_VHOST=/ \
  -p 5672:5672 -p 15672:15672 \
  rabbitmq:3.13-management

Environment variable RABBITMQ_DEFAULT_USER membuat user default secara otomatis — menggantikan kebutuhan skrip add_user manual.

#Volume untuk Persistence

Data queue dan metadata harus disimpan di volume, bukan di layer container yang hilang saat restart:

docker run -d --name rabbitmq \
  -v rabbitmq_data:/var/lib/rabbitmq \
  -p 5672:5672 -p 15672:15672 \
  rabbitmq:3.13-management

Volume rabbitmq_data memastikan pesan dan metadata selamat dari docker restart maupun penggantian container.

#Docker Compose Clustering

Compose memudahkan menjalankan cluster multi-node di satu host:

services:
  rabbitmq1:
    image: rabbitmq:3.13-management
    hostname: rabbitmq1
    environment:
      - RABBITMQ_ERLANG_COOKIE=rahasiaCookie
    volumes:
      - rabbitmq1_data:/var/lib/rabbitmq
  rabbitmq2:
    image: rabbitmq:3.13-management
    hostname: rabbitmq2
    environment:
      - RABBITMQ_ERLANG_COOKIE=rahasiaCookie
    volumes:
      - rabbitmq2_data:/var/lib/rabbitmq

Semua node berbagi cookie yang sama, lalu node-node bergabung melalui peer discovery — detail formasi mengikuti pola episode 19.

#Kubernetes Deployment

#RabbitMQ Cluster Operator

Cara terbaik men-deploy RabbitMQ di K8s adalah RabbitMQ Cluster Operator — mengelola StatefulSet, service, dan konfigurasi secara otomatis lewat CRD:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbit-prod
spec:
  replicas: 3
  persistence:
    storageClassName: standard
    storage: 10Gi
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: "2"
      memory: 4Gi

CRD RabbitmqCluster meminta operator membangun cluster 3 node dengan PersistentVolume 10 GiB dan resource request-limit yang wajar.

#StatefulSet, ConfigMaps, dan Secrets

Operator menghasilkan StatefulSet (urutan startup yang stabil), ConfigMap untuk konfigurasi rabbitmq.conf, dan Secret untuk kredensial default serta cookie. Semua perubahan konfigurasi dilakukan lewat resource K8s, bukan SSH ke pod — ini prinsip GitOps yang kita perdalam di episode 30.

#Best Practices K8s

#Headless Service dan Peer Discovery

Cluster membutuhkan headless service agar tiap pod punya DNS stabil (rabbit-prod-0.rabbit-prod.rabbitmq.svc). Operator mengonfigurasi ini otomatis, dan peer discovery memakai DNS tersebut untuk menemukan sesama node.

#Probes dan Rolling Updates

Kubernetes memakai liveness probe untuk merestart pod yang macet dan readiness probe untuk menahan trafik sebelum pod siap:

readinessProbe:
  exec:
    command: ["rabbitmq-diagnostics", "ping"]
  initialDelaySeconds: 20
livenessProbe:
  exec:
    command: ["rabbitmq-diagnostics", "status"]
  initialDelaySeconds: 30

Untuk rolling updates, hapus dan ganti pod satu per satu dengan interval, agar cluster tidak pernah kehilangan mayoritas node sekaligus. Operator menangani ini saat image di-update.

#Resource Limits dan HPA

Pasang request dan limit (contoh di CRD di atas) agar pod tidak menguras node. HPA jarang cocok untuk stateful workload seperti RabbitMQ — menambah replica pod tidak otomatis memperbaiki bottleneck, karena queue data tetap berada di node pemiliknya. Ukur dulu; jika perlu skalabilitas, pertimbangkan stream atau desain topologi.

#Penutup

Di episode 29 ini kalian sudah men-deploy RabbitMQ di Docker dengan env vars dan volume, membangun cluster dengan Docker Compose, serta men-deploy di Kubernetes dengan RabbitMQ Cluster Operator, StatefulSet, PersistentVolume, probe, dan praktik rolling update.

Inti yang harus dibawa pulang:

• Gunakan image resmi dan environment variables untuk konfigurasi awal.
• Volume wajib ada untuk menyimpan data agar tahan restart.
• Docker Compose mempermudah cluster multi-node di satu host.
• RabbitMQ Cluster Operator mengelola lifecycle cluster di K8s.
• Headless service memberi DNS stabil untuk peer discovery.
• Liveness dan readiness probe penting untuk orkestrasi yang aman.
• HPA jarang tepat untuk stateful workload seperti RabbitMQ.

Di episode 30 selanjutnya kita akan mengelola CI/CD, Infrastructure as Code dan GitOps — mendefinisikan queue dan exchange sebagai JSON definitions, mengotomasi dengan Terraform dan Ansible, menguji alur pesan dengan PerfTest, menerapkan blue-green dan canary releases, serta sinkronisasi otomatis dengan ArgoCD dan Flux. Infrastruktur sebagai kode, mulai sekarang!