Chapter sebelumnya ditutup dengan pertanyaan yang hampir selalu diajukan pemula Docker: kalau container bukan mesin virtual, apakah sebenarnya container itu? Pertanyaan ini bukan sekadar rasa ingin tahu — jawabannya menentukan kapan kita memilih container, kapan memilih mesin virtual, dan kapan memakai keduanya sekaligus. Kita juga sudah melihat sekilas bahwa container berbagi kernel host, tetapi belum melihat mekanisme apa yang menggantikan peran hypervisor pada mesin virtual. Chapter ini membedah cara kerja keduanya, membandingkan sembilan aspek praktis, lalu menutup dengan pola kombinasi yang dipakai hampir seluruh infrastruktur cloud modern.

Cara Kerja Virtual Machine #

Mesin virtual adalah komputer utuh yang disimulasikan oleh perangkat lunak. Penyimulasinya disebut hypervisor, dan ada dua jenis: hypervisor tipe 1 berjalan langsung di atas perangkat keras fisik — contohnya VMware ESXi, Microsoft Hyper-V, dan KVM — sedangkan hypervisor tipe 2 berjalan sebagai aplikasi biasa di atas sistem operasi host, seperti VirtualBox atau VMware Workstation. Apa pun jenisnya, hypervisor membagi resource fisik menjadi perangkat keras virtual yang bisa dipakai banyak mesin tamu sekaligus.

Sebuah virtual machine membawa tumpukan yang benar-benar lengkap. Di dalamnya ada perangkat keras virtual, Guest OS dengan kernelnya sendiri, library sistem, dan baru di puncaknya aplikasi yang kita jalankan. Menyalakan sebuah VM berarti menyalakan seluruh sistem operasi tamu itu, dari boot loader sampai service sistem — proses yang memakan puluhan detik sampai menit. Konsekuensinya, satu image VM lazim berukuran gigabyte karena di dalamnya memang tersimpan sistem operasi utuh.

Cara Kerja Container #

Container mengambil jalan yang jauh lebih ringkas. Sebuah container tidak membawa sistem operasi tamu; container adalah proses biasa dari kernel host yang dibungkus mekanisme namespace dan cgroups sehingga proses tersebut seolah-olah memiliki dunia sendiri. Karena kernel tidak diduplikasi, image container hanya perlu membawa aplikasi beserta library dan runtime yang dipakainya — tidak ada Guest OS di dalamnya. Itulah alasan image alpine:3.20 hanya berukuran 7.8MB, sementara image virtual machine terkecil pun tetap dihitung dalam gigabyte.

Konsekuensi arsitektur ini penting dipahami dua arah. Pertama, container menyala dalam hitungan detik — sering kali kurang dari satu detik — karena tidak ada sistem operasi yang perlu di-boot; kernel host tinggal menyiapkan isolasi lalu memulai proses. Kedua, container Linux membutuhkan kernel Linux: pada Windows dan macOS, container berjalan di dalam VM Linux kecil yang dikelola Docker Desktop — topik yang kita bahas pada Chapter Docker Engine dan Docker Desktop.

Perbandingan Sembilan Aspek #

AspekVirtual MachineContainer
IsolasiKuat — kernel dan perangkat keras terpisah penuhTingkat proses — namespace dan cgroups pada kernel bersama
KernelSetiap VM membawa Guest OS dengan kernel sendiriBerbagi kernel host
OverheadBesar — virtualisasi perangkat keras plus boot OS utuhKecil — hanya proses terisolasi
Ukuran imageGigabyte hingga belasan gigabyteMegabyte — alpine:3.20 hanya 7.8MB
Waktu startPuluhan detik sampai menitDetik, sering kurang dari satu detik
Densitas per hostPuluhan VMRatusan hingga ribuan container
Snapshot dan salinanAda tetapi berat dan lambatRingan lewat layer image
Use case utamaMenjalankan OS berbeda, isolasi keras, aplikasi legacyAplikasi cloud-native, CI/CD, microservices
Contoh produkVirtualBox, VMware, Hyper-V, KVMDocker, Podman, LXC

Dua aspek yang paling menentukan perbedaan keduanya adalah kernel dan ukuran. Karena VM membawa kernel sendiri, VM dapat menjalankan sistem operasi yang berbeda dari host-nya — kekuatan yang tidak dimiliki container. Sebaliknya, justru karena container tidak membawa kernel, image container bisa sekecil beberapa megabyte dan prosesnya menyala secepat proses baru di Linux.

Kapan Memilih Virtual Machine #

Mesin virtual tetap mempunyai wilayahnya sendiri. Pilih VM ketika kita membutuhkan isolasi yang keras — misalnya menjalankan kode milik pelanggan yang tidak bisa dipercaya, atau memenuhi regulasi yang mensyaratkan pemisahan kernel. Pilih VM juga ketika aplikasi memang membutuhkan sistem operasi atau kernel yang berbeda dari host: aplikasi Windows lama di server Linux, atau beban kerja yang hanya berjalan pada kernel tertentu. Dalam skenario semacam itu, container yang berbagi kernel host justru tidak bisa membantu.

Kapan Memilih Container #

Container unggul pada hampir seluruh pekerjaan aplikasi modern. Aplikasi cloud-native, pipeline CI/CD yang menyalakan puluhan lingkungan uji setiap menit, dan arsitektur microservices yang mengepak ratusan service dalam satu host — semuanya adalah wilayah container. Lingkungan pengembangan tim seperti milik Budi dan Siti pada Chapter Masalah yang Diselesaikan Docker juga dijawab container: satu image untuk semua mesin. Aturan praktisnya sederhana — jika yang perlu dipindahkan adalah aplikasi, pilih container; jika yang perlu dipindahkan adalah sistem operasi utuh, pilih mesin virtual.

Menggabungkan Keduanya #

Dalam praktiknya, dunia nyata memakai keduanya sekaligus: container berjalan di dalam virtual machine. Penyedia cloud publik menyewakan VM sebagai unit infrastruktur, dan di dalam VM itulah pelanggan menjalankan container aplikasinya. Node klaster Kubernetes umumnya juga VM berisi container runtime, dan Docker Desktop — yang kita bahas pada Chapter Docker Engine dan Docker Desktop — menjalankan Docker Engine di dalam VM Linux internal: WSL 2 pada Windows, backend virtualisasi pada macOS, dan QEMU dengan KVM pada Linux. Pola pelapisan ini bukan redundansi, melainkan pembagian peran.

Dengan peta container versus virtual machine yang kini lengkap, saatnya kita membuka kap Docker itu sendiri: komponen apa saja yang bekerja di balik satu perintah docker run, dan bagaimana semuanya saling terhubung? Chapter Arsitektur Docker membedahnya lapis demi lapis, dari CLI di ujung jari kita sampai proses container di dalam kernel.

Referensi #