Use Case Docker #

Docker bukan tool yang diciptakan untuk satu tujuan spesifik. Ia adalah platform generik yang bisa diterapkan di banyak konteks — dari laptop developer, pipeline CI/CD, sampai kluster Kubernetes di cloud. Karena fleksibilitasnya, pertanyaannya bukan “bisa Docker dipakai di sini?” tapi “seberapa besar nilai yang Docker bawa ke konteks ini, dan apa trade-off-nya?”

Artikel ini membahas use case Docker yang paling umum dan relevan di industri. Untuk setiap use case, kamu akan melihat masalah yang dipecahkan, contoh konkret, manfaat utama, dan catatan penting yang perlu diperhatikan. Pada akhir artikel ada ringkasan tabel yang bisa kamu pakai sebagai cheat sheet saat mengambil keputusan.

Tujuan artikel ini bukan membuat Docker terkesan bisa dipakai untuk segalanya. Ada situasi di mana Docker memang bukan pilihan terbaik — dan kita akan membahasnya secara jujur di bagian akhir.

Local Development Environment #

Use case paling universal dan paling cepat terasa nilainya. Hampir semua developer yang belajar Docker mulai dari sini.

Masalah yang Diselesaikan #

Pernah dengar “di laptop saya jalan, di laptop kamu error”? Ini terjadi karena setiap laptop punya kondisi OS, library, dan konfigurasi sendiri. Developer A pakai macOS dengan Python 3.11, developer B pakai Windows dengan Python 3.9, developer C pakai Linux dengan Python 3.12. Hasil: kode yang sama berperilaku berbeda.

Docker menjawab ini dengan satu prinsip: semua developer menjalankan stack yang sama persis, didefinisikan dalam satu file.

Contoh Konkret #

Sebuah tim punya aplikasi yang butuh:

• Backend API (Go 1.22 + Postgres 16 + Redis 7).
• Worker (Python 3.12 + Kafka).
• Frontend (Node 20 + Nginx).

Tanpa Docker, setiap developer harus install Go, Postgres, Redis, Python, Kafka, Node, Nginx — masing-masing dengan versi yang harus cocok. Dengan Docker, satu file docker-compose.yml mendefinisikan semuanya, dan satu perintah menjalankan semuanya:

# docker-compose.yml
services:
  api:
    build: ./api
    ports:
      - "8080:8080"
    depends_on:
      - postgres
      - redis
  worker:
    build: ./worker
    depends_on:
      - kafka
  web:
    build: ./web
    ports:
      - "3000:3000"
  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: dev
  redis:
    image: redis:7
  kafka:
    image: bitnami/kafka:3.7

Developer baru cukup git clone, lalu docker compose up. Dalam 5 menit, seluruh stack berjalan di laptop — identik dengan apa yang berjalan di staging dan production.

Manfaat #

• Onboarding cepat untuk developer baru. Tidak perlu setup environment satu per satu.
• Environment konsisten untuk seluruh tim. Tidak ada lagi “di laptop saya jalan”.
• Tidak mengotori host. Tidak ada Postgres atau Redis yang di-install global di laptop.
• Multiple project coexist. Bisa jalankan stack berbeda di waktu yang sama tanpa konflik.

Tips praktis: Simpan docker-compose.yml di root repo, dan tambahkan docker compose up ke README. Developer baru bisa productive dalam hitungan menit, bukan hari. Untuk project lebih besar, pisahkan docker-compose.override.yml (konfigurasi dev lokal) dari docker-compose.yml (definisi service) agar keduanya bisa di-version control tanpa konflik.

Application Isolation #

Use case kedua yang paling langsung terasa: menjalankan beberapa aplikasi yang butuh dependency konflik di satu host.

Masalah yang Diselesaikan #

Di server tradisional, semua aplikasi berbagi runtime dan library yang sama. Aplikasi A butuh library versi lama, aplikasi B butuh versi baru — dan keduanya harus coexist di satu OS.

Contoh Konkret #

Bayangkan satu server dengan tiga aplikasi:

• App A — microservice lama, butuh Python 3.8 + library C versi 1.0.
• App B — service baru, butuh Python 3.12 + library C versi 2.0.
• App C — script analitik, butuh Python 2.7 (legacy, tidak bisa di-upgrade).

Tanpa Docker, administrator server harus memilih satu versi Python dan library C, lalu mengutak-atik symlink atau venv — solusi rapuh yang sering rusak setelah update OS.

Dengan Docker, masing-masing aplikasi berjalan di container dengan image-nya sendiri:

# App A
FROM python:3.8-slim
RUN apt-get install -y libfoo-dev=1.0
COPY . /app
CMD ["python", "/app/main.py"]

# App B
FROM python:3.12-slim
RUN apt-get install -y libfoo-dev=2.0
COPY . /app
CMD ["python", "/app/main.py"]

Ketiganya berjalan di server yang sama, saling terisolasi, tanpa konflik.

Manfaat #

• Dependency isolation. Setiap aplikasi membawa dependency-nya sendiri.
• Clean removal. Hapus container, dan tidak ada jejak yang tertinggal.
• Update aman. Update satu aplikasi tidak memengaruhi yang lain.
• Resource limit per container. Container A bisa dibatasi 256 MB, container B 1 GB.

Microservices Architecture #

Docker adalah pondasi teknis untuk microservices. Hampir tidak ada arsitektur microservices modern yang tidak menggunakan container.

Masalah yang Diselesaikan #

Aplikasi monolith sulit di-scale, lambat di-deploy, dan rentan terhadap regresi. Perubahan kecil di satu modul mengharuskan redeploy seluruh aplikasi. Kalau satu service mati, seluruh aplikasi ikut down.

Microservices memecah aplikasi menjadi service kecil yang independen. Tapi setiap service kecil tetap butuh environment, runtime, dan deployment yang terpisah. Di sinilah Docker menjadi pondasinya.

flowchart TB
    API[API Gateway]
    API --> Auth[auth-service]
    API --> User[user-service]
    API --> Order[order-service]
    API --> Payment[payment-service]
    API --> Notif[notification-service]
    User --> DBUser[(user-db)]
    Order --> DBOrder[(order-db)]
    Payment --> DBPay[(payment-db)]

Setiap service dalam diagram di atas adalah container terpisah, dengan image terpisah, deployment terpisah, dan scaling terpisah.

Manfaat #

• Independent deployment. Service bisa di-deploy kapan saja tanpa koordinasi.
• Independent scaling. Service yang sibuk di-scale, yang sepi tetap kecil.
• Failure isolation. Bug atau crash di satu service tidak menjatuhkan yang lain.
• Polyglot freedom. Tiap service bisa pakai bahasa/runtime berbeda tanpa konflik.

Biasanya Dikombinasikan Dengan #

• Kubernetes — orkestrasi multi-host dengan self-healing dan autoscaling.
• Service Mesh (Istio, Linkerd) — observability dan policy antar service.
• API Gateway (Kong, Envoy, NGINX) — routing dan authentication terpusat.

CI/CD Pipeline #

Docker mengubah CI/CD dari “build di server CI dengan konfigurasi X, deploy ke server production dengan konfigurasi Y” menjadi satu pipeline yang sama dari awal sampai akhir.

Alur Standar CI/CD dengan Docker #

flowchart LR
    A[Git push] --> B[CI Server]
    B --> C[docker build]
    C --> D[run tests in container]
    D --> E{Tests pass?}
    E -- Tidak --> F[Fail pipeline]
    E -- Ya --> G[docker push ke Registry]
    G --> H[Deploy ke Staging]
    H --> I[Smoke test]
    I --> J{OK?}
    J -- Ya --> K[Deploy ke Production]
    J -- Tidak --> L[Block + alert]

Yang penting: image yang dites = image yang dideploy. Tidak ada perbedaan antara environment build, test, staging, dan production — semuanya menjalankan image yang sama.

Contoh Pipeline (GitHub Actions) #

# .github/workflows/deploy.yml
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Run tests
        run: |
          docker run --rm app:${{ github.sha }} npm test          
      - name: Push to registry
        run: |
          echo "${{ secrets.REGISTRY_TOKEN }}" | docker login -u user --password-stdin
          docker push app:${{ github.sha }}          
      - name: Deploy
        run: ./deploy.sh app:${{ github.sha }}

Manfaat #

• Build reproducible. Image yang sama selalu bisa dibangun ulang dari Dockerfile.
• Test environment identik dengan production. Tidak ada lagi “test pass di CI, fail di production”.
• Artifact standar. Image Docker adalah format universal — bisa dipakai di Kubernetes, ECS, Fargate, Cloud Run, atau Docker Swarm.
• Fast feedback loop. Build image biasanya < 5 menit, test 1–10 menit, total < 15 menit per perubahan.

Production Deployment #

Docker image sebagai artefak deployment adalah standar industri saat ini. Image yang dihasilkan dari pipeline CI bisa di-deploy ke banyak platform tanpa modifikasi.

Platform Deployment Populer #

Contoh Deployment Kubernetes Sederhana #

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: registry.example.com/web:v1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080

Manfaat #

• Deployment cepat dan konsisten. Image yang sama ke semua environment.
• Rollback mudah. Tinggal ganti tag image ke versi sebelumnya.
• Immutable infrastructure. Server tidak diubah setelah deploy — di-replace dengan container baru.
• Auto-scaling. Horizontal Pod Autoscaler scale container berdasarkan CPU, memory, atau custom metric.

Prinsip penting di production: Container harus stateless. Semua state (session, file upload, cache) disimpan di luar container — di database, Redis, object storage, atau volume. Container sendiri bisa di-restart atau di-replace kapan saja tanpa kehilangan data.

Legacy Application Modernization #

Salah satu use case yang paling undervalued: Docker sebagai jembatan untuk memodernisasi aplikasi lama tanpa rewrite besar-besaran.

Masalah yang Diselesaikan #

Aplikasi legacy sering kali:

• Berjalan di OS yang sudah end-of-life (CentOS 6, Ubuntu 14.04).
• Punya dependency yang tidak tersedia di OS modern.
• Pakai library yang sudah deprecated dan tidak bisa di-upgrade.
• Instalasinya multi-step dan dokumentasinya hilang.

Tanpa Docker, opsinya: rewrite dari awal (mahal dan lama), atau terus menjalankan server lama (resiko keamanan tinggi).

Solusi: Containerization tanpa Rewrite #

Aplikasi lama dibungkus dalam container yang berisi OS lama + dependency lama. Container ini berjalan di host modern tanpa konflik, dan tim punya waktu untuk memodernisasi kode secara bertahap.

# Contoh: PHP 5.6 + Apache + library lama
FROM ubuntu:14.04
RUN apt-get update && apt-get install -y \
    php5 \
    php5-mysql \
    libapache2-mod-php5 \
    && rm -rf /var/lib/apt/lists/*
COPY ./legacy-app /var/www/html
EXPOSE 80
CMD ["apache2ctl", "-D", "FOREGROUND"]

Container ini akan berjalan di host Ubuntu 22.04 atau Amazon Linux 2023 tanpa masalah. Aplikasi legacy tetap bekerja, dan tim bisa migrasi ke PHP 8 + framework modern secara bertahap.

Manfaat #

• Tidak perlu upgrade besar-besaran sekaligus.
• Risiko perubahan minimal untuk aplikasi yang sudah stabil.
• Waktu yang lebih panjang untuk modernisasi bertahap.
• Memperpanjang usia aplikasi tanpa mengorbankan keamanan host.

Database dan Stateful Service #

Topik yang sering diperdebatkan: apakah database production layak dijalankan di Docker? Jawaban singkatnya: tergantung.

Untuk Development dan Testing — Sangat Cocok #

Docker adalah cara tercepat untuk menjalankan database di local atau di CI:

• PostgreSQL untuk development.
• Redis untuk integration test.
• Elasticsearch untuk eksperimen.
• MongoDB, MySQL, MariaDB, ClickHouse — semua punya image official yang siap pakai.

# docker-compose.yml untuk database development
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: dev
      POSTGRES_DB: myapp
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  redis:
    image: redis:7-alpine
    volumes:
      - redisdata:/data
    ports:
      - "6379:6379"

volumes:
  pgdata:
  redisdata:

Wajib pakai volume untuk database. Data di dalam container tanpa volume akan hilang saat container dihapus — ini salah satu jebakan paling umum. Selalu mount volume atau named volume untuk directory data database.

Untuk Production — Hati-hati #

Menjalankan database production di Docker memang mungkin dan banyak perusahaan melakukannya, tapi butuh setup yang matang:

• Storage yang tepat — local SSD dengan driver yang bagus (overlay2), atau cloud block storage (EBS, Persistent Disk).
• Backup strategy — automated backup ke S3/GCS, plus tested restore.
• Monitoring — Prometheus + postgres_exporter, atau Datadog/New Relic.
• High availability — replikasi, failover otomatis, atau managed service.

Untuk kebanyakan tim, lebih baik pakai managed database service (RDS, Cloud SQL, Azure Database, Supabase, PlanetScale) daripada self-host di Docker — kecuali kamu punya dedicated DBA dan alasan kuat.

Tooling dan Utility Container #

Pola yang sangat berguna: “saya tidak install tool-nya, saya jalankan container-nya”.

Daripada meng-install tool CLI global di host, jalankan via Docker untuk menghindari konflik dependency dan menjaga host tetap bersih.

Contoh umum:

# Terraform via Docker
docker run -it --rm -v $PWD:/workspace -w /workspace hashicorp/terraform:1.7 plan

# Hugo (static site generator) via Docker
docker run --rm -v $PWD:/src -p 1313:1313 hugomods/hugo:base server

# FFmpeg untuk video processing
docker run --rm -v $PWD:/data jrottenberg/ffmpeg -i /data/input.mp4 /data/output.webm

# psql client untuk query database remote
docker run -it --rm postgres:16-alpine psql -h db.example.com -U user mydb

# Python REPL dengan library tertentu
docker run -it --rm python:3.12-slim python

Manfaat #

• Tidak ada tool yang di-install global — host tetap bersih.
• Versi tool selalu terkontrol — pakai tag image yang spesifik.
• Reproducible — script yang jalan hari ini akan jalan 5 tahun lagi kalau image tag-nya sama.
• Aman untuk tool yang butuh dependency berat (misal: ffmpeg butuh libavcodec dan teman-temannya).

Event-Driven dan Background Worker #

Container adalah unit eksekusi yang sempurna untuk worker yang memproses event dari queue.

Contoh Arsitektur #

flowchart LR
    API[API Service] --> Q[Message Queue<br/>Kafka / SQS / RabbitMQ]
    Q --> W1[Worker 1]
    Q --> W2[Worker 2]
    Q --> W3[Worker 3]
    W1 --> DB[(Database)]
    W2 --> DB
    W3 --> DB

Tiap worker adalah container yang:

• Polling queue untuk pesan baru.
• Memproses pesan (render image, kirim email, hitung billing, dll).
• Acknowledge pesan setelah selesai.
• Crash dan di-restart otomatis oleh orchestrator kalau gagal.

Contoh Worker Sederhana #

# worker.py
import boto3

sqs = boto3.client('sqs')
queue_url = 'https://sqs.us-east-1.amazonaws.com/123/my-queue'

while True:
    response = sqs.receive_message(QueueUrl=queue_url, MaxNumberOfMessages=1)
    for msg in response.get('Messages', []):
        process(msg['Body'])
        sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=msg['ReceiptHandle'])

# Dockerfile untuk worker
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "worker.py"]

Manfaat #

• Mudah di-scale — tinggal tambah replica worker saat queue panjang.
• Crash isolation — bug di satu worker tidak menjatuhkan yang lain.
• Auto-restart — orchestrator restart worker yang mati.
• Resource limit jelas — worker bisa dibatasi CPU/memory agar tidak mengganggu service lain.

Eksperimen dan Sandbox #

Mau coba bahasa baru, framework baru, atau database baru? Docker adalah cara teraman dan tercepat.

# Coba PostgreSQL 17 (masih beta)
docker run --rm -d --name pg17 postgres:17beta

# Coba Redis dengan modul graph
docker run --rm -d redis/redis-stack-server

# Coba framework web baru
docker run --rm -p 8080:8080 ghcr.io/some-framework/demo

# Benchmark dua versi Python
docker run --rm python:3.11 python -c "import time; ..."
docker run --rm python:3.12 python -c "import time; ..."

Setelah selesai, docker rm -f container dan tidak ada jejak yang tertinggal di host. Mau coba hal lain? Tinggal docker run lagi.

Machine Learning dan AI Workloads #

Docker sangat umum di workflow ML/AI:

• Training — jalankan training job di container dengan GPU dan library tertentu.
• Inference — model ML di-serve lewat container API (FastAPI, TorchServe, Triton).
• Jupyter Notebook — image jupyter/datascience-notebook memberi kamu environment lengkap dalam satu container.
• MLOps pipeline — model training → evaluation → packaging → deployment semua dalam container.

# docker-compose untuk ML development
services:
  jupyter:
    image: jupyter/datascience-notebook
    ports:
      - "8888:8888"
    volumes:
      - ./notebooks:/home/jovyan/work
    environment:
      JUPYTER_ENABLE_LAB: "yes"

  mlflow:
    image: ghcr.io/mlflow/mlflow
    ports:
      - "5000:5000"
    command: mlflow server --host 0.0.0.0

Edge Computing dan IoT #

Container ringan dan immutable menjadikannya ideal untuk edge device — server kecil di lapangan, gateway IoT, atau device retail.

Contoh deployment:

• Retail kiosk — menjalankan aplikasi POS di Raspberry Pi via container.
• Industrial gateway — meng-aggregate data sensor dan forward ke cloud.
• CDN edge node — menjalankan proxy/reverse proxy di banyak lokasi geografis.
• K8s on the edge — K3s (Kubernetes ringan) berjalan di edge device.

Catatan untuk edge: Image harus kecil (gunakan alpine atau distroless), tahu cara update dirinya sendiri (watchtower, k3s auto-upgrade), dan toleran terhadap network intermiten (cache lokal, retry exponential backoff).

Kapan Docker Kurang Cocok? #

Docker bukan obat untuk semua penyakit. Ada situasi di mana ia bukan pilihan terbaik.

Aplikasi dengan GUI native yang berat. Aplikasi desktop yang butuh akses ke GPU penuh, OpenGL, atau hardware 3D sering bermasalah di container. X11 forwarding atau VNC bisa jadi workaround, tapi tidak seamless.

High-performance I/O yang ekstrem. Database dengan throughput tinggi (ratusan ribu IOPS) butuh tuning kernel dan filesystem yang kadang tidak achievable di dalam container. Benchmark dulu sebelum commit.

Stateful workload kritikal tanpa orkestrasi matang. Database production tanpa backup strategy, monitoring, dan HA yang jelas akan menyakiti kamu di saat yang tidak terduga.

Aplikasi yang sangat bergantung pada kernel module tertentu. Beberapa aplikasi butuh akses langsung ke kernel module yang tidak tersedia atau susah di-mount di container.

Environment dengan regulasi yang sangat ketat. Beberapa industri (defense, government classified) punya aturan yang melarang container atau shared kernel.

Aplikasi yang sudah bekerja sempurna dan tidak akan dikembangkan. Jangan re-engineer aplikasi yang sudah stabil. Biarkan ia di VM atau bare metal.

Ringkasan Use Case #

Tabel cheat sheet untuk keputusan cepat:

Ringkasan #

• Docker adalah platform generik dengan banyak use case, bukan tool satu tujuan. Nilainya datang dari konsistensi image, isolasi proses, dan portabilitas.
• Local development adalah use case paling cepat terasa nilainya — onboarding developer baru dari hari menjadi menit.
• Application isolation memecahkan masalah dependency hell yang selama ini jadi sumber utama masalah deployment.
• Microservices tanpa container hampir tidak mungkin di skala besar. Container adalah pondasi teknisnya.
• CI/CD dengan Docker menghasilkan pipeline yang benar-benar reproducible — image yang dites = image yang dideploy.
• Production deployment paling baik dilakukan via orchestrator (Kubernetes, ECS, Fargate) dengan image sebagai artifact.
• Legacy modernization lewat containerization memungkinkan migrasi bertahap tanpa rewrite besar-besaran.
• Database production di Docker mungkin tapi butuh setup matang. Untuk kebanyakan tim, managed service lebih praktis.
• Tooling via container menjaga host tetap bersih dan versi tool terkontrol.
• Worker, ML, edge, sandbox — semua use case yang kuat dengan Docker.
• Docker bukan untuk semua hal. GUI native, high-perf I/O ekstrem, dan workload legacy yang stabil mungkin lebih baik di VM atau bare metal.

← Sebelumnya: VM vs Container   Berikutnya: Architecture Overview →