Container #
Container adalah cara mengemas aplikasi beserta semua dependensinya — library, konfigurasi runtime, file — ke dalam satu unit yang bisa dijalankan secara konsisten di environment manapun. Berbeda dengan VM yang memvirtualisasi hardware, container memvirtualisasi OS — mereka berbagi kernel yang sama dengan host tapi terisolasi satu sama lain. Hasilnya: container jauh lebih ringan dari VM, startup dalam hitungan detik, dan sangat cocok untuk workload cloud-native yang dinamis.
VM vs Container — Perbedaan Fundamental #
Virtual Machine:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ App A │ │ App B │ │ App C │
├──────────┤ ├──────────┤ ├──────────┤
│ OS Full │ │ OS Full │ │ OS Full │ ← setiap VM punya OS sendiri
│ (GBs) │ │ (GBs) │ │ (GBs) │
└────┬─────┘ └────┬─────┘ └────┬─────┘
└──────────────┴──────────────┘
Hypervisor
Hardware Fisik
Startup: menit (boot OS)
Overhead: besar (tiap VM punya OS sendiri)
Isolasi: sangat kuat (kernel terpisah)
Portabilitas: terbatas (image besar, boot lambat)
Container:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ App A │ │ App B │ │ App C │
│ + Libs │ │ + Libs │ │ + Libs │ ← hanya app + dependensi
└────┬─────┘ └────┬─────┘ └────┬─────┘
└──────────────┴──────────────┘
Container Runtime (Docker, containerd)
Host OS (satu kernel, shared)
Hardware Fisik
Startup: detik (tidak perlu boot OS)
Overhead: kecil (tidak punya OS sendiri)
Isolasi: lebih ringan (share kernel)
Portabilitas: sangat tinggi (image kecil, portable)
Anatomi Container Image #
Container image adalah blueprint — template yang immutable dan bisa dijalankan menjadi container instance.
Layer System Container Image:
Image = tumpukan layer yang immutable
Layer 4: COPY app/ ./app/ ← kode aplikasi kamu
Layer 3: RUN pip install -r requirements.txt ← dependensi
Layer 2: COPY requirements.txt .
Layer 1: FROM python:3.11-slim ← base image (OS minimal + Python)
Keuntungan layer system:
✓ Layer yang sama di-share antar image (tidak di-download ulang)
✓ Cache build — jika layer tidak berubah, tidak di-rebuild
✓ Setiap layer hanya menyimpan perubahan dari layer sebelumnya
Contoh Dockerfile sederhana:
FROM python:3.11-slim ← mulai dari base image resmi
WORKDIR /app ← direktori kerja dalam container
COPY requirements.txt . ← copy dulu (untuk cache efisien)
RUN pip install --no-cache-dir -r requirements.txt
COPY app/ ./app/ ← copy kode (layer paling sering berubah)
EXPOSE 8080 ← dokumentasi port yang dipakai
CMD ["python", "app/main.py"] ← perintah yang dijalankan saat start
Container Registry #
Image yang sudah di-build perlu disimpan di suatu tempat agar bisa di-deploy ke manapun. Container registry adalah storage khusus untuk container image.
Alur Build → Push → Pull:
Developer machine:
docker build -t myapp:v1.2.3 . ← build image
docker push registry.example.com/myapp:v1.2.3 ← push ke registry
Container Registry:
→ Menyimpan semua versi image
→ Bisa public (siapapun bisa pull) atau private (butuh auth)
→ Managed service dari cloud provider atau self-hosted
Deployment target (server, Kubernetes):
→ Pull image dari registry
→ Run container dari image
Tagging yang baik:
✓ myapp:1.2.3 ← semantic version (immutable)
✓ myapp:1.2 ← minor version (update patch otomatis)
✗ myapp:latest ← tidak spesifik, bisa berubah sewaktu-waktu
hindari di produksi
Orkestrasi Container — Kubernetes #
Menjalankan satu container di satu server mudah. Menjalankan ratusan container di puluhan server, dengan auto-scaling, self-healing, dan zero-downtime deployment — itulah yang diselesaikan oleh container orchestrator seperti Kubernetes.
Masalah tanpa Orchestrator:
✗ Bagaimana distribusikan container ke server yang punya kapasitas?
✗ Bagaimana restart container yang crash secara otomatis?
✗ Bagaimana update container tanpa downtime?
✗ Bagaimana scale container naik/turun berdasarkan beban?
✗ Bagaimana service discovery — container A cari container B di mana?
Kubernetes menyelesaikan ini semua:
Cluster Kubernetes:
┌────────────────────────────────────────────────────┐
│ Control Plane │
│ (API Server, etcd, Scheduler, Controller Manager) │
└────────────────────────────────────────────────────┘
│ manage
┌──────┼──────┐
▼ ▼ ▼
Node 1 Node 2 Node 3
[Pod A] [Pod B] [Pod C] ← Pod = satu atau lebih container
[Pod D] [Pod E]
Konsep dasar Kubernetes (vendor-agnostic):
Pod: unit terkecil — satu atau beberapa container
Deployment: definisi "inginkan N replika Pod ini berjalan"
Service: abstraksi network untuk sekumpulan Pod
Ingress: routing HTTP/HTTPS dari luar ke Service
Managed Kubernetes vs Self-Managed #
Di cloud, Kubernetes tersedia sebagai managed service — provider mengelola control plane, kamu mengelola workload.
Self-Managed Kubernetes:
□ Install dan konfigurasi control plane (etcd, API server, dll)
□ Kelola upgrade Kubernetes secara manual
□ Kelola sertifikat dan keamanan control plane
□ Monitor health control plane
✓ Kontrol penuh atas konfigurasi
✗ Overhead operasional yang sangat signifikan
✗ Butuh expertise Kubernetes yang dalam
Managed Kubernetes (EKS, GKE, AKS):
✓ Control plane dikelola provider (HA, patching, upgrade)
✓ Integrasi native dengan layanan cloud (LB, storage, IAM)
✓ Kamu hanya kelola worker nodes dan workload
✗ Biaya tambahan untuk managed control plane
✗ Sedikit kurang fleksibel dibanding self-managed
Rekomendasi: hampir selalu pilih managed Kubernetes
kecuali ada kebutuhan kontrol yang sangat spesifik
Kapan Container, Kapan VM #
Pilih Container jika:
✓ Aplikasi baru yang dibangun cloud-native
✓ Microservices yang perlu scale independen
✓ Workload yang butuh startup cepat (auto-scaling responsif)
✓ Tim yang sudah familiar atau siap belajar container
✓ Ingin konsistensi environment dari dev ke prod
Pilih VM jika:
✓ Legacy application yang tidak bisa di-containerize
✓ Software yang butuh akses OS level atau kernel tertentu
✓ Workload stateful yang kompleks (beberapa database masih
lebih mudah di-manage di VM)
✓ Regulasi yang membutuhkan isolasi yang lebih kuat dari container
✓ Tim yang belum siap dengan complexity Kubernetes
Ringkasan #
- Container memvirtualisasi OS, bukan hardware — share kernel dengan host, jauh lebih ringan dari VM, startup dalam detik.
- Container image adalah blueprint immutable berlayer — layer yang sama di-share antar image; build cache menggunakan layer yang tidak berubah.
- Selalu gunakan tag spesifik (semantic version) di produksi — hindari tag
:latestyang tidak deterministik.- Kubernetes memecahkan orchestration container dalam skala besar — scheduling, self-healing, scaling, dan service discovery secara otomatis.
- Managed Kubernetes hampir selalu lebih baik dari self-managed — kecuali ada kebutuhan kontrol yang sangat spesifik.
- Container bukan pengganti VM untuk semua kasus — legacy app, workload dengan isolasi ketat, atau tim yang belum siap masih lebih cocok dengan VM.