Belajar Docker - Sejarah, Latar Belakang & Mengapa Membutuhkan Docker

#Pendahuluan

Setelah di episode 0 sebelumnya kita memastikan environment siap — skill dasar Linux CLI, Docker Engine terpasang, dan verifikasi bahwa docker version merespons tanpa sudo — pada episode kali ini kita mundur sejenak untuk menjawab pertanyaan yang jarang diajukan tapi sangat menentukan: dari mana Docker berasal, dan mengapa ia dibutuhkan?

Pertanyaan ini bukan trivia sejarah. Memahami latar belakang Docker menjawab tiga pertanyaan praktis yang akan menghantui kalian sepanjang karier: (1) mengapa aplikasi yang "berjalan di laptop saya" bisa gagal di server, (2) apa sebenarnya yang dibedakan virtual machine dan kontainer — dan kapan memilih yang mana, dan (3) mengapa teknologi kernel Linux seperti cgroups dan namespaces menjadi fondasi yang tak tergantikan. Seperti memahami sejarah sebuah bahasa pemrograman, memahami sejarah containerization membuat kalian tidak hanya bisa memakai Docker, tapi tahu mengapa ia ada — dan itu yang membedakan engineer yang mengetik perintah dari engineer yang memahami sistem.

Di episode ini kita akan menelusuri evolusi deployment aplikasi dari bare-metal hingga era kontainer, membedah akar masalah "dependency hell", menelusuri kelahiran Docker di PyCon 2013, membedah teknologi kernel yang menjadi fondasinya, dan menutup dengan perbandingan menyeluruh virtual machine versus kontainer.

#Evolusi Deployment Aplikasi

Cara manusia mendeploy aplikasi adalah cermin dari cara kita menyelesaikan masalah yang sama berulang-ulang: menjalankan kode di mesin yang bukan milik kita. Mari telusuri tiga era besar.

#Era Bare-metal

Pada era awal — tahun 1980-an sampai 2000-an — satu aplikasi berjalan langsung di atas satu mesin fisik (bare-metal). Server adalah "kotak besi" yang dibeli, dirakit, dan dicolokkan ke rack. Konsekuensinya:

• Satu mesin menjalankan satu aplikasi, karena menumpuk dua aplikasi berarti berisiko mereka saling mengganggu — versi library yang bentrok, satu aplikasi menghabiskan semua memori.
• Skala = beli mesin baru. Butuh aplikasi kedua? Beli server kedua. Butuh redundansi? Beli server ketiga.
• Utilisasi hardware buruk — server yang hanya melayani sedikit request tetap harus menyala 24 jam dengan CPU 90% menganggur.

Bayangkan setiap aplikasi punya rumah sendiri yang dibangun khusus — mewah, tapi mahal dan boros.

#Era Virtual Machine (Hypervisor)

Masalah utama bare-metal adalah biaya dan utilisasi. Pada awal 2000-an, hypervisor (VMware, KVM, Xen) memecah satu mesin fisik menjadi banyak mesin virtual. Setiap VM berisi:

• Guest OS lengkap — kernel sendiri (Linux, Windows, dll.)
• Aplikasi dan dependency-nya — seperti server bare-metal sendiri

Ini perubahan besar: satu server fisik kini bisa menjalankan lima, sepuluh, bahkan dua puluh "server" berbeda, masing-masing terisolasi penuh. Hardware termanfaatkan jauh lebih baik, dan "It works on my machine" mulai terpecahkan — VM yang sama persis bisa dipindahkan antar host.

Tapi ada harga yang harus dibayar: setiap VM menyalin seluruh sistem operasi, dengan kernel, driver, dan library yang lengkap. Bayangkan mengirim seluruh rumah — pondasi, atap, perabotan — padahal yang kalian butuhkan hanyalah mengirim isi satu lemari ke tetangga. Boot butuh menit, memakan ratusan MB hingga GB RAM, dan disk penuh dengan sistem operasi duplikat yang tidak pernah dipakai.

#Era Containerization

Di sinilah containerization menjawab: bagaimana cara mengisolasi aplikasi tanpa mengirim seluruh sistem operasi? Jawabannya adalah memanfaatkan kernel Linux yang sudah ada di host. Kontainer bukan mesin virtual — ia adalah sekumpulan proses Linux biasa yang diisolasi dan dibatasi oleh kernel. Yang dikirim bukan seluruh rumah, melainkan kontainer pengiriman: isi lemari, rak, dan barang bawaan yang dibutuhkan — dalam format standar yang bisa dimuat ke kapal mana pun.

#"It Works on My Machine!" dan Dependency Hell

Sebelum menutup evolusi, mari bedah masalah paling klasik di industri software. "It works on my machine!" bukan lelucon — ia adalah gejala dari akar masalah yang disebut dependency hell:

1. Aplikasi tidak pernah berjalan sendirian. Ia butuh runtime (Python 3.8, Node 18, JVM), library (OpenSSL versi 1.1 vs 3.0), tool system (curl, jq), dan file konfigurasi.
2. Dependency tersebut bergantung satu sama lain dengan aturan versi yang rumit — sering saling bentrok: Aplikasi A butuh OpenSSL 1.1, Aplikasi B butuh OpenSSL 3.0, dan keduanya tidak bisa hidup bersama di sistem yang sama.
3. Environment berbeda = hasil berbeda. Laptop pengembang (macOS, library terbaru), server staging (Ubuntu, versi menengah), server produksi (CentOS, versi lama) — satu versi dependency yang berbeda saja bisa memicu bug misterius.

Masalah ini semakin besar seiring aplikasi tumbuh. Satu script kecil dengan satu dependency mudah dikelola; aplikasi production dengan puluhan library yang saling bergantung adalah bom waktu. Docker memecahkan ini secara fundamental: dependency aplikasi di-kemas bersama aplikasi di dalam image, sehingga versi library "selalu sama" di setiap mesin — bukan "semoga sama".

#Sejarah Lahirnya Docker

#Dari DotCloud ke Docker

Kisah Docker dimulai dari DotCloud, perusahaan Platform-as-a-Service yang dibangun Solomon Hykes bersama rekan-rekannya. DotCloud menjual platform untuk mendeploy aplikasi multi-teknologi — dan untuk mengelola isolasi antar aplikasi pelanggan, mereka membangun alat internal berbasis LXC (Linux Containers), teknologi isolasi yang memanfaatkan cgroups dan namespaces.

Alat internal itu ternyata lebih berharga daripada produk utamanya. Pada Maret 2013, Hykes memperkenalkan proyek tersebut — yang kini bernama Docker — dalam sebuah demo terkenal di konferensi PyCon. Dalam waktu beberapa menit di panggung, ia menjalankan kontainer dan menunjukkan betapa sederhananya mengemas dan menjalankan aplikasi. Responsnya luar biasa: proyek open-source itu meledak dalam hitungan bulan, mengubah cara industri memandang deployment.

#Mengapa Docker Meledak?

Docker tidak menemukan teknologi isolasi — LXC, cgroups, dan namespaces sudah ada sejak lama. Yang Docker temukan adalah kemudahan dan portabilitas:

1. Antarmuka sederhana. Satu perintah docker run menggantikan puluhan langkah konfigurasi LXC manual.
2. Image sebagai artefak portabel. Aplikasi + lingkungan dikemas menjadi satu image yang bisa dipindah antar mesin, dibagikan, dan di-versi-kan — seperti .git untuk seluruh environment.
3. Layered architecture. Image disusun dari lapisan-lapisan yang bisa di-cache dan dibagikan — efisien dalam penyimpanan dan transfer.
4. Registry. Docker Hub menjadi "GitHub untuk image" — berbagi aplikasi jadi semudah docker pull.

Ekosistem inilah — bukan teknologi isolasinya — yang membuat Docker mengubah industri. Sebelum Docker, isolasi proses adalah topik kelas kernel yang jarang bersentuhan dengan developer aplikasi; setelah Docker, isolasi menjadi fitur yang dipakai jutaan developer setiap hari.

#Fondasi Kernel Linux di Balik Kontainer

Inilah bagian yang paling banyak disalahpahami. Kontainer bukan fitur baru di kernel — ia adalah kombinasi tiga teknologi Linux lama yang disatukan. Mari bedah satu per satu.

#cgroups (Control Groups)

cgroups adalah mekanisme kernel untuk membatasi dan mengukur penggunaan resource dari sekelompok proses: berapa maksimum CPU, berapa banyak memori, berapa besar I/O disk, bahkan berapa banyak proses (PIDs) yang boleh dibuat. Tanpa cgroups, satu proses yang "nakal" bisa menghabiskan seluruh memori host dan menjatuhkan aplikasi lain. Dengan cgroups, kalian bisa berkata: "kontainer ini maksimal memakai 512 MB RAM dan 1 CPU" — dan kernel menegakkannya secara keras.

Analogi: cgroups adalah pembatas ruangan — ia mengatur berapa banyak barang yang boleh masuk ke dalam satu ruangan, berapa berat maksimumnya, dan mencatat siapa yang memakai berapa.

#namespaces

namespaces adalah mekanisme kernel untuk mengisolasi pandangan sekelompok proses terhadap sistem. Setiap proses di Linux "melihat" sistem lewat perspektif yang ditentukan namespaces-nya. Namespace utama yang dipakai kontainer:

Bayangkan dua orang tinggal di kamar berbeda di rumah yang sama (kernel). Keduanya memakai "rumah" yang sama (CPU, memori, filesystem), tapi masing-masing hanya melihat isi kamarnya sendiri — pintu yang berbeda, jendela yang berbeda, alamat surat yang berbeda. Itulah namespaces: ilusi lingkungan terpisah yang dibangun di atas sumber daya bersama.

#chroot

chroot adalah teknologi paling tua dalam daftar ini — mengubah direktori root sebuah proses sehingga proses tersebut hanya bisa melihat filesystem di bawah direktori itu. Konsep ini adalah nenek moyang isolasi filesystem yang menjadi dasar ide "aplikasi membawa lingkungannya sendiri". chroot masih dipakai sampai sekarang, tapi namespaces Mount yang lebih modern (dan lebih aman) yang menjadi fondasi isolasi filesystem kontainer.

#Perbandingan Virtual Machine vs Container

Sekarang kita punya semua bahan untuk perbandingan yang jujur. Mesin virtual dan kontainer menjawab masalah yang sama dengan pendekatan berbeda:

Mari lihat perbandingan waktu boot dan resource secara konkret:

time virt-boot-vm --image ubuntu-server.img
real    0m45.812s          # VM: menit untuk boot OS lengkap
time docker run --rm ubuntu echo "boot!"
real    0m0.421s            # Kontainer: sepersekian detik

Perbedaan angka ini bukan sekadar trik — ia mencerminkan perbedaan fundamental. VM mem-boot seluruh sistem operasi (BIOS → kernel → init system → services), sementara kontainer hanya menciptakan proses Linux baru yang langsung memakai kernel host yang sudah berjalan. Tidak ada yang perlu di-boot.

$ ps aux | grep -c sleep
1
$ docker run -d alpine sleep 300
$ ps aux | grep "sleep 300"
root      12345  0.0  0.0   1528   1104 ?   Ss   12:00   0:00 sleep 300

Baris kedua contoh di atas adalah bukti konsep paling penting di episode ini: kontainer yang sedang berjalan muncul sebagai proses biasa di host (dengan PID di tabel proses host). Ia tidak menjalankan kernel atau init system sendiri — hanya sebuah proses yang diisolasi dan dibatasi kernel. Inilah mengapa seribu kontainer terasa jauh lebih ringan daripada seribu VM.

#Penutup

Pada episode 1 ini kita telah memahami perjalanan deployment aplikasi dari era bare-metal (satu aplikasi satu mesin, boros dan mahal), era virtual machine (isolasi kuat tapi menyalin seluruh OS), hingga era containerization yang mengisolasi proses dengan berbagi kernel host. Kita juga membedah akar masalah "It works on my machine!" — dependency hell yang membuat Docker lahir sebagai solusi mengemas aplikasi beserta lingkungannya. Sejarahnya dicatat di PyCon 2013: Solomon Hykes memperkenalkan Docker, yang meledak bukan karena menemukan teknologi isolasi (cgroups, namespaces, LXC sudah ada) melainkan karena membuatnya mudah dan portabel.

Inti yang harus kalian bawa:

• Deployment berevolusi dari bare-metal → VM → kontainer untuk mengejar efisiensi dan portabilitas.
• Docker tidak menemukan isolasi — ia mengemasnya dalam antarmuka yang mudah dan image yang portabel.
• Kontainer dibangun dari cgroups (batasi resource) + namespaces (isolasi pandangan) + chroot (akar filesystem).
• Kontainer berbagi kernel host — itulah kenapa ringan, cepat, dan hanya untuk OS yang sama.
• VM = kuat dan berat; kontainer = efisien dan ringan. Pilih sesuai kebutuhan, bukan tren.

Sekarang kalian tahu mengapa Docker ada. Di episode 2 selanjutnya kita akan membedah arsitektur dan konsep dasar Docker: bagaimana client, daemon (dockerd), dan registry bekerja sama, peran containerd dan runc serta standard OCI di balik layar, dan empat komponen inti — Image, Container, Volume, dan Network — yang akan menjadi bahasa keseharian kalian di semua episode berikutnya. Sampai jumpa di episode 2!