Belajar Apache Kafka - Docker & Container Best Practices

#Pendahuluan

Docker adalah cara tercepat menjalankan Kafka di development dan sering juga di produksi. Image resmi sudah mengemas Kafka, KRaft, dan seluruh CLI — kalian tinggal mengatur konfigurasi lewat environment variable. Namun container punya jebakan: JVM yang tidak sadar limit memori, listener yang salah arah, dan data yang hilang karena volume tidak di-mount.

Episode 29 ini akan membahas image resmi dan Confluent, Dockerfile custom untuk aplikasi klien, Docker Compose untuk stack lengkap — multi-broker, Schema Registry, ksqlDB — serta pertimbangan volume, JVM, health check, dan logging di dalam container.

#Image Docker Kafka

#Official dan Confluent Images

Dua sumber image utama:

• apache/kafka: image resmi Apache Kafka, mendukung KRaft dan environment variable.
• confluentinc/cp-kafka: image Confluent dengan utilitas ekosistem (Schema Registry, ksqlDB) dan konfigurasi env lengkap.

Untuk development, apache/kafka cukup; untuk stack Confluent (Schema Registry, Connect, ksqlDB), image Confluent terintegrasi lebih mudah.

#Environment Variable Configuration

Image Kafka menerima konfigurasi broker lewat environment variable dengan pola KAFKA_:

KAFKA_BROKER_ID: "1"
KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
KAFKA_PROCESS_ROLES: broker,controller
KAFKA_NODE_ID: "1"
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: "1"

KAFKA_PROCESS_ROLES: broker,controller menjalankan peran combined (KRaft), dan KAFKA_ADVERTISED_LISTENERS menetapkan alamat yang diumumkan — bagian yang paling sering salah di container (episode 15).

#Dockerfile Custom

#Best Practices untuk Aplikasi Klien

Image aplikasi klien sebaiknya ringan dan declaratif. Prinsip utama: aplikasi dan Kafka dipisah, image memakai base yang di-pin versi, dan konfigurasi disuntikkan saat runtime:

FROM eclipse-temurin:17-jre-alpine
COPY target/order-producer.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

eclipse-temurin:17-jre-alpine adalah base JRE ringan. Prinsipnya sama untuk semua bahasa: build artifact terpisah, base image minimal, secret tidak di-bake ke image.

#Docker Compose Setup

#Stack Lengkap Multi-Broker

Compose menggabungkan seluruh stack dalam satu file. Contoh broker tunggal dengan Schema Registry dan ksqlDB:

services:
  broker:
    image: confluentinc/cp-kafka:7.6.0
    ports: ["9092:9092"]
    environment:
      KAFKA_BROKER_ID: "1"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://broker:29092,PLAINTEXT_HOST://localhost:9092
  schema-registry:
    image: confluentinc/cp-schema-registry:7.6.0
    ports: ["8081:8081"]
    environment:
      SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: broker:29092

PLAINTEXT://broker:29092 dipakai sesama service, PLAINTEXT_HOST://localhost:9092 untuk klien dari host — pemisahan yang dibahas di episode 15. Port 8081 membuka Schema Registry.

#Networking antar Service

Gunakan network Compose default: service saling memanggil dengan nama service (broker, schema-registry). Untuk produksi, definisikan network eksplisit dan batasi koneksi; untuk development, ports ekspos listener HOST ke mesin kalian.

#Pertimbangan Container

#Volume dan JVM Settings

Data broker harus bertahan melewati restart container:

volumes:
  - kafka-data:/var/lib/kafka/data
deploy:
  resources:
    limits:
      memory: 2g
      cpus: "2"

volumes: kafka-data:/var/lib/kafka/data menyimpan log di named volume. Tanpa volume, semua data hilang saat container dihapus — bencana untuk produksi. Arahkan juga lokasi log ke direktori yang di-mount (log.dirs).

#Memory Limits dan Heap

Masalah klasik: JVM membaca host RAM dan mengatur heap terlalu besar, atau container limit memori tidak dikenali. Solusinya pakai container-aware JVM:

java -Xms512m -Xmx1g -jar kafka-server-start.jar config/server.properties

-Xmx1g mengunci heap secara eksplisit. Pastikan limits.memory memberi ruang di atas heap untuk off-heap, page cache, dan overhead. Jangan biarkan JVM mengira host RAM penuh tersedia.

#Health Checks

Container perlu health check agar orchestrator tahu kapan siap:

healthcheck:
  test: ["CMD-SHELL", "kafka-broker-api-versions.sh --bootstrap-server localhost:9092"]
  interval: 10s
  timeout: 5s
  retries: 3

kafka-broker-api-versions.sh --bootstrap-server localhost:9092 memverifikasi broker benar-benar merespons, bukan sekadar proses hidup. Ini memberi sinyal yang andal untuk readiness orchestration.

#Logging Drivers

Container seharusnya menulis log ke stdout/stderr agar logging driver (json-file, journald, atau sidecar) menangkapnya. Jangan menulis log ke file di dalam container tanpa pengumpulan. Batasi ukuran log driver agar disk host tidak penuh oleh log yang meledak.

#Penutup

Di episode 29 ini kalian sudah memahami containerisasi Kafka: image resmi dan Confluent, environment variable configuration, Dockerfile custom untuk aplikasi, Docker Compose untuk stack lengkap, serta pertimbangan volume, JVM, memori, health check, dan logging.

Inti yang harus dibawa pulang:

• Pakai image resmi dan konfigurasi lewat environment variable.
• Advertised listener harus berbeda untuk container dan host.
• Mount volume untuk data broker; tanpa itu data hilang saat restart.
• Set -Xmx eksplisit; JVM tidak otomatis sadar limit container.
• Health check dengan CLI Kafka, bukan sekadar cek proses.
• Arahkan log ke stdout/stderr dan batasi ukurannya.

Di episode 30 selanjutnya kita akan membahas cloud-native Kafka — AWS MSK, Confluent Cloud, dan Azure Event Hubs. Kalian akan belajar membuat cluster MSK, autentikasi IAM, MSK Connect, tier konfigurasi Confluent Cloud, serta pertimbangan biaya dan vendor lock-in.