Container #

Dalam lanskap komputasi modern yang berorientasi pada cloud (cloud-native), Container telah menjadi standar de facto untuk mengemas, mendistribusikan, dan menjalankan aplikasi. Berbeda dengan Virtual Machine yang memvirtualisasikan perangkat keras fisik, container bekerja dengan cara memvirtualisasikan sistem operasi (OS-level virtualization). Dengan mengemas kode aplikasi beserta seluruh pustaka dependensi, file konfigurasi, dan runtime yang dibutuhkannya ke dalam satu unit portabel yang ringan, container menjamin aplikasi kita dapat berjalan dengan perilaku yang konsisten di lingkungan mana pun — mulai dari laptop lokal developer, server pengujian staging, hingga kluster produksi skala besar di cloud. Artikel ini akan mengupas tuntas cara kerja isolasi kontainer, anatomi sistem layer image, alur distribusi melalui registry, serta dasar-dasar orkestrasi skala besar menggunakan Kubernetes.

Perbedaan Fundamental: VM vs Container #

Untuk memahami mengapa industri beralih secara masif ke kontainerisasi, kita harus memahami perbedaan arsitektur dasar antara Virtual Machine dan Container.

flowchart TD
    subgraph VM_Arch ["Arsitektur Virtual Machine"]
        direction BT
        HW1["Hardware Fisik Server"] --> Hypervisor["Hypervisor (Nitro / KVM)"]
        Hypervisor --> VM1["VM 1<br>(App A + Guest OS)"]
        Hypervisor --> VM2["VM 2<br>(App B + Guest OS)"]
    end

    subgraph Container_Arch ["Arsitektur Container"]
        direction BT
        HW2["Hardware Fisik Server"] --> HostOS["Host OS (Shared Linux Kernel)"]
        HostOS --> Engine["Container Runtime (Containerd / Docker)"]
        Engine --> Cont1["Container 1<br>(App A + Libs)"]
        Engine --> Cont2["Container 2<br>(App B + Libs)"]
    end

1. Virtualisasi Hardware vs Virtualisasi OS #

• Virtual Machine: Setiap VM berjalan dengan menyertakan satu sistem operasi tamu (Guest OS) yang utuh di dalamnya. Hypervisor mengalokasikan memori RAM dan core CPU fisik secara statis untuk VM tersebut. Proses booting OS tamu memakan waktu menit dan mengonsumsi overhead resource memori ratusan megabyte hingga gigabyte sebelum aplikasi kita sempat berjalan.
• Container: Seluruh container yang berjalan di satu server fisik saling berbagi kernel sistem operasi host (Host OS Kernel) yang sama. Container tidak memerlukan OS tamu sendiri. Lapisan runtime kontainer (seperti containerd atau Docker) hanya membuat isolasi logis tingkat proses. Hasilnya, container dapat dimulai (startup) dalam hitungan milidetik hingga detik, dan overhead memori yang digunakan hampir mendekati nol di luar konsumsi memori aplikasi itu sendiri.

2. Teknologi di Balik Isolasi Kontainer Linux #

Isolasi kontainer bukanlah keajaiban baru, melainkan pemanfaatan dari dua fitur inti yang telah lama ada di dalam kernel Linux:

• Namespaces: Fitur yang bertugas membatasi apa yang dapat dilihat oleh sebuah proses. Kernel Linux menyediakan berbagai namespace terisolasi untuk setiap container:
  • PID (Process ID): Container hanya dapat melihat proses internalnya sendiri, tidak dapat mendeteksi proses milik host atau container lain.
  • NET (Network): Menyediakan perangkat jaringan, alamat IP, dan tabel routing virtual terisolasi untuk tiap container.
  • MNT (Mount): Membatasi sistem berkas agar container hanya memiliki akses root directory / virtualnya sendiri.
• Control Groups (cgroups): Fitur yang bertugas membatasi seberapa banyak resource hardware yang dapat digunakan oleh sebuah proses. Melalui cgroups, kita dapat membatasi agar Container A maksimal hanya boleh mengonsumsi 0.5 core CPU dan 256 MB RAM pada server host, mencegah skenario “noisy neighbor” di mana satu container menyedot seluruh resource server hingga membuat container lain crash.

Anatomi Container Image dan Layer System #

Container Image adalah sebuah blueprint atau template baca-saja (read-only template) yang memuat seluruh instruksi untuk menjalankan sebuah kontainer. Image dibangun menggunakan sistem berkas bertumpuk (Union File System atau UnionFS).

Setiap instruksi di dalam file deklaratif (seperti Dockerfile) akan menciptakan satu lapisan berkas (layer) baru yang bersifat kekal (immutable).

Tumpukan Layer Container Image:
┌───────────────────────────────────────────────┐
│ [READ-WRITE LAYER] Container runtime layer    │  <-- Dibuat saat kontainer RUN (temp file)
├───────────────────────────────────────────────┤
│ [READ-ONLY LAYER] CMD ["node", "server.js"]   │
├───────────────────────────────────────────────┤
│ [READ-ONLY LAYER] COPY . .                    │  <-- Kode aplikasi kita
├───────────────────────────────────────────────┤
│ [READ-ONLY LAYER] RUN npm install             │  <-- Pustaka dependensi
├───────────────────────────────────────────────┤
│ [READ-ONLY LAYER] FROM node:20-alpine         │  <-- Base image (Alpine Linux + Node.js)
└───────────────────────────────────────────────┘

Mekanisme Copy-on-Write (CoW) #

Ketika kita menjalankan sebuah kontainer dari sebuah image, runtime kontainer tidak menduplikasi berkas image tersebut secara fisik. Runtime hanya menempelkan satu lapisan tipis yang dapat ditulis (thin read-write layer) di bagian paling atas tumpukan layer.

• Jika aplikasi di dalam kontainer mencoba membaca berkas, sistem akan mencarinya ke bawah tumpukan layer.
• Jika aplikasi memodifikasi berkas yang ada di layer base image, UnionFS akan menyalin berkas tersebut ke layer read-write teratas terlebih dahulu sebelum memodifikasinya (Copy-on-Write).
• Keuntungan: Banyak kontainer dapat berjalan dari satu image yang sama secara efisien, menghemat penggunaan ruang penyimpanan lokal server host kita.

Best Practice: Multi-stage Build Dockerfile #

Untuk meminimalkan ukuran file image dan celah keamanan (vulnerability surface area), kita wajib menggunakan teknik Multi-stage Build. Teknik ini memisahkan lingkungan kompilasi/build (yang membutuhkan banyak perkakas compiler berukuran besar) dengan lingkungan runtime produksi yang hanya memerlukan file binari hasil kompilasi akhir.

# ANTI-PATTERN: Dockerfile satu tahap (Single-stage)
# JANGAN: Menggabungkan compiler SDK ke dalam image produksi akhir!
FROM golang:1.22
WORKDIR /app
COPY . .
RUN go build -o main .
CMD ["/app/main"]  # Image akhir berukuran > 800 MB!

# --- Separator Stage ---

# BENAR: Dockerfile Multi-stage
# ✓ STAGE 1: Compiler & Builder
FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /bin/app .

# ✓ STAGE 2: Runtime Produksi Minimal
FROM alpine:3.19
WORKDIR /app
# Salin HANYA file binary hasil kompilasi dari stage builder
COPY --from=builder /bin/app /app/app
# Jalankan sebagai non-root user demi keamanan
USER nobody
EXPOSE 8080
CMD ["/app/app"]  # Image akhir berukuran hanya ~ 20 MB!

Pengelolaan Image dengan Container Registry #

Setelah container image berhasil dibangun di server integrasi otomatis (CI/CD), image tersebut harus disimpan di tempat yang aman agar dapat ditarik oleh server produksi cloud kita. Tempat penyimpanan khusus ini disebut sebagai Container Registry.

Alur Kerja Distribusi Image (Workflow) #

1. Build: Script CI/CD membangun image dari source code repository: docker build -t app:v1.0.0 ..
2. Push: Image diunggah ke registry melalui koneksi terotentikasi: docker push registry.example.com/app:v1.0.0.
3. Pull: Server produksi (seperti kluster VM atau Kubernetes node) mengunduh image tersebut dari registry untuk dijalankan: docker run registry.example.com/app:v1.0.0.

Rekomendasi Manajemen Tagging Image #

Tagging digunakan untuk menandai versi dari sebuah image. Penerapan tagging yang salah dapat merusak stabilitas lingkungan produksi kita.

• myapp:latest (ANTI-PATTERN): Jangan pernah menggunakan tag :latest di lingkungan produksi. Tag :latest bersifat dinamis dan akan terus menunjuk pada image yang paling baru diunggah. Jika sistem auto-healing atau auto-scaling menarik ulang image di tengah malam, VM kita mungkin akan mendapatkan versi kode baru yang belum diuji secara tidak sengaja, memicu crash aplikasi yang sulit dilacak.
• myapp:v1.2.3 (BENAR): Gunakan penomoran versi semantik (Semantic Versioning) yang bersifat tetap (immutable). Sekali versi v1.2.3 dirilis, isi image tersebut tidak boleh diubah kembali. Jika ada perbaikan bug kecil, buat tag baru v1.2.4.
• myapp:sha-8f2a1b9 (SANGAT DIREKOMENDASIKAN): Menggunakan hash komit git pendek (Git Commit SHA) sebagai tag. Ini menjamin ketertelusuran penuh dari versi kontainer yang berjalan di cloud langsung ke baris kode sumber asli di Git.

Orkestrasi Container Skala Besar dengan Kubernetes #

Menjalankan satu kontainer di satu server VM menggunakan perintah docker run sangatlah mudah. Namun, bagaimana jika kita harus mengelola ratusan kontainer aplikasi microservices yang tersebar di puluhan server fisik? Bagaimana cara melakukan auto-scaling saat trafik melonjak? Bagaimana cara mengganti kontainer yang crash tanpa downtime?

Kebutuhan kompleks inilah yang diselesaikan oleh Container Orchestrator, di mana Kubernetes (biasa disingkat K8s) telah menjadi standar industri global.

flowchart TD
    subgraph ControlPlane ["Kubernetes Control Plane (Master Node)"]
        APIServer["kube-apiserver<br>(Pintu Masuk API HTTP)"]
        Etcd["etcd database<br>(Penyimpan State Kluster)"]
        Scheduler["kube-scheduler<br>(Penentu Lokasi Pod)"]
        KCM["kube-controller-manager<br>(Reconciliation Loop)"]
        
        APIServer --> Etcd
        KCM --> APIServer
        Scheduler --> APIServer
    end

    subgraph WorkerNodes ["Worker Nodes (Infrastruktur VM)"]
        subgraph Node1 ["Worker Node 1"]
            Kubelet1["kubelet agent"]
            PodA["Pod A<br>(Container App)"]
            PodB["Pod B<br>(Container App)"]
        end

        subgraph Node2 ["Worker Node 2"]
            Kubelet2["kubelet agent"]
            PodC["Pod C<br>(Container App)"]
        end
    end

    APIServer -->|"Kirim Perintah Deploy"| Kubelet1
    APIServer -->|"Kirim Perintah Deploy"| Kubelet2

Komponen Utama Kubernetes #

Kubernetes membagi beban kerjanya ke dalam dua kelompok server utama:

1. Control Plane (Master Node) #

Otak utama yang mengendalikan seluruh status kluster:

• kube-apiserver: Gateway komunikasi utama yang mengekspos REST API. Semua konfigurasi dimasukkan lewat file manifest YAML melalui komponen ini.
• etcd: Database key-value terdistribusi yang sangat konsisten, digunakan sebagai penyimpanan status tunggal (single source of truth) dari seluruh konfigurasi kluster.
• kube-scheduler: Menentukan di VM node mana sebuah kontainer baru harus diletakkan berdasarkan ketersediaan memori dan CPU kosong.
• kube-controller-manager: Menjalankan siklus rekonsiliasi (reconciliation loop). Tugasnya memastikan status kluster yang berjalan di lapangan selalu cocok dengan status ideal yang kita definisikan di file konfigurasi.

2. Worker Nodes (Data Plane) #

Server VM fisik yang bertugas menjalankan kontainer aplikasi kita:

• kubelet: Agen yang berjalan di setiap node, bertanggung jawab memantau kesehatan kontainer dan menerima instruksi langsung dari control plane.
• kube-proxy: Mengelola aturan routing jaringan virtual di tingkat node untuk memuluskan lalu lintas data antar kontainer.

Konsep Abstraksi Utama Kubernetes #

• Pod: Unit komputasi terkecil di Kubernetes. Pod membungkus satu atau beberapa kontainer yang berbagi alamat IP dan port jaringan yang sama.
• Deployment: Objek deklaratif yang menentukan replika aplikasi (misalnya: “Saya ingin ada 3 instans Pod dari web-app:v1.0.0 yang selalu berjalan”). K8s otomatis melakukan self-healing dengan membuat Pod baru jika salah satu Pod mati.
• Service: Menyediakan alamat IP internal tetap dan load balancer bawaan di depan sekelompok Pod yang dinamis.
• Ingress: Komponen routing HTTP/HTTPS luar kluster yang mengarahkan trafik domain internet ke Service yang tepat di dalam kluster.

Managed Kubernetes vs Self-Managed #

Di lingkungan cloud, kita memiliki dua pilihan utama dalam mengadopsi Kubernetes:

Rekomendasi: Selalu pilih Managed Kubernetes (seperti AWS EKS atau GCP GKE) untuk workload produksi perusahaan kita. Kompleksitas operasional mengelola master node dan etcd kluster mandiri terlalu berisiko dan menguras waktu tim operasi kita yang seharusnya bisa digunakan untuk mengembangkan fitur produk.

Kapan Memilih Container vs Virtual Machine #

Meskipun kontainer menawarkan banyak kelebihan, tidak semua workload cocok dipindahkan ke dalam kontainer.

Pilih Container jika: #

• Aplikasi Baru (Greenfield Projects): Aplikasi yang dirancang dengan arsitektur microservices terdistribusi yang membutuhkan skalabilitas dinamis.
• Pipeline CI/CD yang Cepat: Tim yang membutuhkan rilis kode berkali-kali dalam sehari, di mana kecepatan start-up dan build image sangat memengaruhi produktivitas.
• Konsistensi Lingkungan: Mencegah insiden “it works on my machine” karena jaminan isolasi file system runtime.

Tetap Gunakan Virtual Machine (VM) jika: #

• Aplikasi Monolitik Besar: Aplikasi legacy raksasa yang tidak mudah dipotong menjadi potongan kecil, mengonsumsi banyak resource statis, dan memakan waktu booting OS tamu yang lama.
• Persyaratan Akses Kernel Khusus: Aplikasi yang membutuhkan konfigurasi modul kernel OS Linux tingkat rendah yang tidak aman jika dijalankan di atas shared host kernel kontainer.
• Persyaratan Isolasi Keamanan Ekstrim: Beban kerja dengan tingkat sensitivitas regulasi militer/finansial yang tinggi yang mengharuskan tingkat isolasi hardware fisik penuh (hard virtualization) di level hypervisor, bukan sekadar isolasi logis namespaces (soft virtualization).

Ringkasan #

• Container memvirtualisasikan sistem operasi (OS) menggunakan fitur bawaan Linux Namespaces (isolasi akses) dan Control Groups (pembatasan resource) secara efisien.
• Jauh lebih ringan dan cepat dibanding VM karena kontainer tidak menyertakan Guest OS tambahan dan saling berbagi kernel host yang sama.
• UnionFS membuat sistem layer image immutable — kita wajib memanfaatkan teknik multi-stage build untuk menghasilkan image produksi yang minimalis dan aman.
• Terapkan tag versi yang deterministik (seperti Semantic Versioning atau Git Commit SHA) di produksi, dan hindari penggunaan tag :latest yang dinamis.
• Kubernetes adalah dirigen orkestrasi kontainer skala besar yang menangani auto-scaling, penanganan kegagalan otomatis (self-healing), dan service discovery secara deklaratif.
• Managed Kubernetes (EKS/GKE) adalah pilihan terbaik daripada mengelola Control Plane sendiri karena menghemat waktu operasional dan biaya engineer secara signifikan.

← Sebelumnya: Virtual Machine   Berikutnya: Managed Compute →