Pengenalan Docker

Container sudah menjadi bagian standar dalam workflow modern, mulai dari menjalankan satu aplikasi web sederhana di laptop Developer sampai mengoperasikan sistem berskala besar yang terdiri dari puluhan service di production. Bab ini menjadi titik berangkat untuk memahami Docker, platform yang mempopulerkan cara kerja tersebut: apa sebenarnya container itu, bagaimana teknologi ini berkembang dari fitur isolasi proses di kernel Linux menjadi standar industri, apa yang membedakannya dari virtual machine, dan di skenario seperti apa Docker benar-benar memberi manfaat nyata bagi Developer maupun Sysadmin/DevOps Engineer.

1.1 Apa Itu Docker dan Mengapa Penting

Docker adalah platform open source untuk mengembangkan, mengemas, dan menjalankan aplikasi di dalam container. Docker memisahkan aplikasi dari infrastruktur tempatnya berjalan, sehingga kita bisa mengirimkan software lebih cepat dan konsisten, baik di laptop development, server staging, maupun production. Ide intinya sederhana: sekali sebuah aplikasi dikemas menjadi image Docker, image itu akan berjalan dengan cara yang sama di mesin mana pun yang punya Docker terpasang, tanpa peduli perbedaan sistem operasi host, versi library, atau konfigurasi environment.

Persoalan yang coba dijawab Docker sebenarnya sudah lama akrab bagi Developer maupun Sysadmin/DevOps Engineer: aplikasi yang berjalan mulus di komputer seorang Developer, tapi error begitu dipindah ke server production. Penyebabnya beragam, mulai dari versi runtime yang berbeda, dependency yang belum terpasang, sampai konfigurasi environment variable yang lupa disamakan. Docker mengatasi masalah "it works on my machine" ini dengan cara membungkus aplikasi beserta seluruh dependency-nya (runtime, library, tool, file konfigurasi) menjadi satu paket portable bernama image. Image inilah yang kemudian dijalankan menjadi container, yaitu proses terisolasi yang berjalan langsung di atas kernel sistem operasi host.

Docker penting karena mengubah cara tim mengelola infrastruktur menjadi setara dengan cara tim mengelola kode aplikasi. Konfigurasi container bisa ditulis dalam file teks (Dockerfile), disimpan di version control, di-review lewat pull request, dan dijalankan ulang secara identik kapan saja. Bagi Developer, ini berarti environment development bisa direplikasi persis sama oleh seluruh anggota tim hanya dengan satu perintah. Bagi Sysadmin/DevOps Engineer, ini berarti proses deployment jadi lebih dapat diprediksi karena unit yang di-deploy ke production adalah unit yang sama persis dengan yang sudah diuji di tahap development dan testing.

1.2 Sejarah dan Evolusi Containerization

Konsep isolasi proses di Linux sebenarnya sudah ada jauh sebelum Docker dirilis. Fondasinya adalah dua fitur kernel Linux: namespaces dan control groups (cgroups). Namespace membuat sekumpulan proses hanya bisa melihat resource dalam "ruangannya" sendiri, seperti process ID, network interface, atau filesystem, sehingga proses di satu namespace tidak bisa melihat atau mengganggu proses di namespace lain. Cgroups mengatur berapa banyak CPU, memori, dan I/O yang boleh dipakai oleh sekumpulan proses tersebut. Kombinasi keduanya adalah dasar teknis dari apa yang sekarang kita sebut container. Sebelum era container modern, teknologi isolasi proses berkembang bertahap: dimulai dari chroot pada sistem Unix yang mengisolasi filesystem, dilanjutkan FreeBSD Jails dan Solaris Zones yang memperluas isolasi ke level sistem operasi, hingga Linux Containers (LXC) yang menjadi implementasi container pertama di Linux dengan memanfaatkan langsung namespaces dan cgroups.

Docker awalnya dikembangkan oleh Solomon Hykes di dalam dotCloud, sebuah perusahaan platform-as-a-service, dan dirilis sebagai proyek open source pada Maret 2013. Perusahaan di baliknya kemudian berganti nama menjadi Docker, Inc. pada September tahun yang sama, mengikuti besarnya minat komunitas terhadap proyek ini. Pada versi-versi awalnya, Docker sebenarnya dibangun di atas LXC sebagai execution driver. Yang membuat Docker berbeda dari LXC bukan teknologi isolasinya, melainkan pengalaman penggunanya: Docker memperkenalkan format image yang portable, mekanisme layer yang bisa di-cache dan digunakan ulang antar image, serta command line interface yang jauh lebih sederhana dibanding mengelola LXC secara manual. Docker juga membangun Docker Hub sebagai registry publik, sehingga image bisa dengan mudah dibagikan dan diunduh oleh siapa pun. Kombinasi kemudahan pakai dan ekosistem inilah yang membuat container, yang sebelumnya adalah teknologi niche di kalangan spesialis Linux, berubah menjadi standar industri untuk mengemas dan menjalankan aplikasi.

Seiring adopsi Docker meluas, komunitas dan industri mendorong standardisasi format image dan runtime container agar tidak terkunci pada satu vendor. Pada Juni 2015, Docker bersama sejumlah perusahaan lain seperti CoreOS mendirikan Open Container Initiative (OCI) di bawah naungan Linux Foundation, yang mendefinisikan spesifikasi terbuka untuk format image dan runtime container. Docker turut menyumbangkan draf spesifikasi serta sebagian besar kode format image dan container runtime miliknya sebagai fondasi awal OCI. Dua tahun setelahnya, pada 2017, Docker mendonasikan containerd, komponen container runtime miliknya, ke Cloud Native Computing Foundation (CNCF). Hingga sekarang, containerd itulah yang dipakai Docker Engine untuk menjalankan container, dan runtime yang sama juga dipakai oleh banyak platform container lain karena comply terhadap spesifikasi OCI. Artinya, image yang dibuat dengan Docker pada dasarnya bisa dijalankan oleh runtime lain yang juga comply terhadap OCI, dan sebaliknya. Standardisasi ini menjadi salah satu alasan mengapa container, alih-alih hanya menjadi fitur satu tool, berkembang menjadi ekosistem dengan banyak tool orchestration seperti Kubernetes yang dibangun mengelilinginya.

1.3 Docker vs Virtual Machine

Baik container maupun virtual machine (VM) sama-sama bertujuan mengisolasi aplikasi dari sistem lain di mesin yang sama, tapi keduanya mencapai isolasi itu dengan pendekatan arsitektur yang berbeda secara fundamental. VM menjalankan hypervisor yang mengemulasi hardware, lalu di atas hardware virtual itu terpasang sistem operasi tamu (guest OS) yang lengkap, termasuk kernelnya sendiri. Container, sebaliknya, adalah proses yang terisolasi lewat namespaces dan cgroups, dan seluruh container di satu host berbagi kernel yang sama dengan sistem operasi host.

Perbedaan arsitektur ini berimbas langsung ke penggunaan resource dan kecepatan. Karena tidak perlu boot sistem operasi lengkap, container biasanya menyala dalam hitungan detik atau bahkan kurang, sementara VM butuh waktu boot yang jauh lebih lama karena harus menginisialisasi kernel dan seluruh proses sistem operasinya sendiri. Dari sisi ukuran, image Docker pada umumnya jauh lebih kecil dibanding image VM karena tidak membawa kernel dan seluruh sistem operasi, hanya aplikasi beserta dependency yang benar-benar dibutuhkan. Karena lebih ringan, satu mesin fisik atau VM yang sama bisa menjalankan container dalam jumlah jauh lebih banyak dibanding menjalankan VM penuh, sehingga pemanfaatan resource server jadi lebih efisien.

Trade-off-nya ada di sisi isolasi. Karena berbagi kernel host, batas isolasi container secara teori tidak seketat VM yang benar-benar terpisah di level hardware virtual; sebuah container escape yang berhasil mengeksploitasi celah di kernel host berpotensi berdampak ke host atau container lain, sesuatu yang jauh lebih sulit dilakukan Attacker terhadap VM karena tiap VM punya kernelnya sendiri. Di lapangan, kedua teknologi ini juga lazim dipakai berdampingan, bukan saling menggantikan: banyak provider cloud menjalankan container Docker di dalam VM, sehingga tim mendapat efisiensi resource dari container sekaligus lapisan isolasi tambahan dari VM di baliknya.

1.4 Use Case dan Benefit Docker

Di lingkungan development sehari-hari, Docker paling terasa manfaatnya untuk menyamakan environment antar anggota tim. Developer cukup menjalankan satu perintah untuk menghidupkan seluruh dependency yang dibutuhkan aplikasi, misalnya database, cache, dan message broker, tanpa perlu memasang masing-masing tool tersebut langsung di sistem operasi lokal. Ini juga mempermudah onboarding anggota tim baru, karena environment development yang biasanya butuh dokumentasi panjang dan setup manual berjam-jam bisa digantikan dengan proses yang konsisten dan terulang.

Di sisi operasional, Sysadmin/DevOps Engineer memanfaatkan Docker untuk membuat proses deployment lebih dapat diprediksi. Karena unit yang di-deploy ke production adalah image yang sama persis dengan yang sudah diuji sebelumnya, risiko munculnya perilaku baru yang tidak terduga akibat perbedaan environment jadi jauh berkurang. Docker juga memudahkan penerapan pola microservices, di mana tiap service aplikasi dikemas dan dijalankan sebagai container yang terpisah, sehingga masing-masing service bisa di-deploy, di-scale, dan dipelihara secara independen tanpa saling mengganggu.

Beberapa benefit lain yang lazim dirasakan tim yang sudah mengadopsi Docker secara konsisten:

• Portabilitas. Image yang sama bisa dijalankan di laptop Developer, server on-premise, maupun berbagai layanan cloud, selama Docker atau runtime yang comply dengan OCI terpasang di sana.
• Efisiensi resource. Karena container jauh lebih ringan dibanding VM, satu server bisa menjalankan lebih banyak workload dengan spesifikasi hardware yang sama.
• Kecepatan iterasi. Waktu startup container yang singkat membuat siklus testing dan debugging jadi jauh lebih cepat dibanding menunggu boot VM.
• Reproducibility. Konfigurasi yang tertulis di Dockerfile dan file Compose membuat environment bisa dibangun ulang secara identik kapan pun dibutuhkan, mengurangi masalah environment drift.
• Ekosistem image siap pakai. Docker Hub menyediakan image resmi untuk berbagai sistem operasi, database, hingga bahasa pemrograman, sehingga tim tidak perlu membangun environment dasar dari nol.

Meski begitu, Docker bukan solusi untuk semua kasus. Aplikasi yang butuh akses sangat dekat ke hardware tertentu, atau workload yang mensyaratkan isolasi kernel penuh karena alasan keamanan yang sangat ketat, biasanya tetap lebih cocok dijalankan di VM atau bare metal. Memahami kapan Docker jadi pilihan tepat, dan kapan bukan, adalah salah satu bentuk kematangan yang membedakan penggunaan container yang asal jalan dengan penggunaan yang benar-benar sesuai kebutuhan sistem.