Belajar ChromaDB - Deployment Networking

#Pendahuluan

Server ChromaDB sudah aman secara default — dipatch, di-auth, dan terisolasi. Episode 15 membawa kalian ke langkah berikutnya: menyebarkan server dengan benar ke infrastruktur yang sesungguhnya. Kita akan membahas Docker container, Kubernetes dengan Helm, TLS dan reverse proxy, load balancing, serta isolasi jaringan.

Setelah episode ini, kalian tidak hanya bisa menjalankan ChromaDB — kalian bisa men-deploy-nya sebagai service yang layak dipakai tim produksi.

#Deploy dengan Docker Container

#Menjalankan Server dalam Container

ChromaDB menyediakan image resmi. Menjalankan server Rust dalam container dengan volume persisten:

docker run -d --name chroma \
  -p 8000:8000 \
  -v chroma-data:/chroma/chroma \
  -e CHROMA_SERVER_HOST=0.0.0.0 \
  -e CHROMA_SERVER_AUTHN_PROVIDER=chromadb.auth.token_authn.TokenAuthenticationServerProvider \
  -e CHROMA_SERVER_AUTHN_CREDENTIALS_FILE=/chroma/creds.txt \
  ghcr.io/chroma-core/chroma

Perintah docker run -d --name chroma ... ghcr.io/chroma-core/chroma memetakan port 8000, memasang volume chroma-data agar data bertahan, dan mengaktifkan token auth. Volume persisten adalah kunci — tanpa itu, data hilang setiap container di-restart.

#Docker Compose untuk Development

Untuk development tim, docker-compose.yml jauh lebih nyaman:

services:
  chroma:
    image: ghcr.io/chroma-core/chroma:1.5.9
    ports:
      - "8000:8000"
    volumes:
      - chroma-data:/chroma/chroma
volumes:
  chroma-data:

Pinning image ke tag spesifik ghcr.io/chroma-core/chroma:1.5.9 — bukan latest — menjaga reproduktibilitas dan menghindari upgrade tak terduga yang mengubah perilaku.

#Deploy ke Kubernetes dengan Helm

#Menginstall Chart

Untuk orkestrasi penuh, pakai Helm chart ChromaDB. Tambahkan repo dan install:

helm repo add chroma https://chroma-core.github.io/chroma
helm install chroma chroma/chroma \
  --namespace chroma \
  --create-namespace

helm install chroma chroma/chroma membuat Deployment, Service, dan PersistentVolumeClaim secara otomatis. Chart ini menangani replicas, storage, dan resource request yang sudah di-tune untuk produksi.

#Kustomisasi dengan values.yaml

Semua pengaturan dari episode 12-13 bisa diatur lewat file values:

persistence:
  size: 50Gi
auth:
  token:
    enabled: true
    token: "rahasia-kuat-2026"
service:
  type: ClusterIP

values.yaml di atas mengatur storage 50Gi, mengaktifkan token auth, dan menyembunyikan Service di dalam cluster (ClusterIP). Service hanya bisa diakses dari dalam cluster — aplikasi RAG kalian yang menghubungkannya.

#TLS dan Reverse Proxy

#Nginx sebagai Pintu Masuk TLS

Server ChromaDB sendiri tidak harus menangani TLS — biarkan reverse proxy yang melakukannya. Contoh konfigurasi Nginx:

server {
    listen 443 ssl;
    server_name chroma.example.com;
 
    ssl_certificate     /etc/ssl/chroma.crt;
    ssl_certificate_key /etc/ssl/chroma.key;
 
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Authorization $http_authorization;
    }
}

location / { proxy_pass http://127.0.0.1:8000; ... } meneruskan HTTPS ke server ChromaDB di internal. Blok proxy_set_header Authorization memastikan token klien diteruskan — kehilangan header ini membuat semua request ditolak auth.

#Kenapa TLS Itu Wajib

Tanpa TLS, token auth dari episode 13 dikirim dalam plaintext — siapa pun yang menyadap jaringan bisa mencurinya. Kombinasi yang benar: TLS di depan (reverse proxy), auth di dalam (ChromaDB). Keduanya bukan pengganti, melainkan lapisan yang berbeda.

#Load Balancing dan Isolasi Jaringan

#Load Balancing untuk Skala Baca

ChromaDB bisa dijalankan dengan beberapa replika di belakang load balancer. Di Kubernetes, cukup ubah replica count:

helm upgrade chroma chroma/chroma \
  --set replicaCount=2

helm upgrade chroma chroma/chroma --set replicaCount=2 menaikkan jumlah replika. Load balancer Kubernetes membagi beban antar replika — kombinasi dengan episode 17 untuk strategi scaling yang lengkap.

#Firewall dan Security Group

Di cloud, isolasi jaringan dimulai dari security group. Aturan yang disarankan untuk server ChromaDB:

inbound:  8000  dari <CIDR host aplikasi>  (TCP)
inbound:  8000  dari <CIDR load balancer>  (TCP)
outbound: semua

Tidak ada CIDR publik di inbound — hanya host aplikasi dan load balancer yang boleh masuk. Ini contoh paling nyata dari network isolation di episode 14. Verifikasi berkala dengan scanner external bahwa port 8000 tidak terekspos ke internet.

#Penutup

Episode 15 membawa ChromaDB ke infrastruktur produksi: container Docker dengan volume persisten dan pinning versi, Kubernetes lewat Helm dengan kustomisasi values, TLS dan reverse proxy sebagai gerbang HTTPS yang mempertahankan header auth, load balancing untuk skala baca, serta isolasi jaringan dengan firewall dan security group.

Inti yang harus dibawa pulang:

• Docker butuh volume persisten; tanpa itu data hilang saat restart.
• Pin image ke versi spesifik, bukan latest.
• Helm menangani Deployment, Service, dan storage sekaligus.
• Reverse proxy menangani TLS; header Authorization harus diteruskan.
• TLS di depan dan auth di dalam adalah lapisan yang saling melengkapi.
• Security group hanya mengizinkan host aplikasi dan load balancer.

Di episode 16 selanjutnya kita akan membahas privacy dan data handling — risiko embedding inversion yang bisa merekonstruksi dokumen dari vektor, enkripsi data at rest, penanganan PII, retention policy, dan audit log akses data. Keamanan teknis sudah kuat; sekarang saatnya mengamankan dari sisi data dan regulasi.