Mengenal teknologi container untuk siapa aja dah

Pada suatu hari, developer baru di perusahaan Acme Inc mendapatkan perintah untuk memasang sebuah aplikasi bernama Docker di saat onboarding di hari pertamanya. Ketika ditanya "untuk apa install aplikasi ikan paus ini?" sang developer senior menjawabnya dengan "untuk menjalankan aplikasi".

Dari zaman dahulu kala ketika komputer ditemukan, satu-satunya tugas yang dilakukan oleh sesuatu bernama komputer ini adalah menjalankan aplikasi. Menjalankan program. Menjalankan kumpulan instruksi.

Tanpa perlu memiliki program berlogo ikan paus di komputer kita.

Ini adalah salah satu program bernama ed(1) yang mana sebuah penyunting teks "berorientasi garis" yang hanya berukuran 230K dan hampir terpasang di setiap komputer yang menggunakan sistem operasi UNIX-like seperti GNU/Linux dan Mac OS.

Program ed(1) rilis pertama kali di tahun 1973, dan di tahun ketika tulisan ini diterbitkan (2022) program tersebut masih berjalan sebagaimana seharusnya. Tanpa perlu memasang program berlogo ikan paus.

Tapi tadi kita menggunakan perspektif sebagai pengguna komputer. Sekarang, mari kita menggunakan perspektif pengembang program sebentar yang nantinya program kita akan dijalankan oleh si pengguna komputer.

Mari kita mulai dengan membuat sebuah program sederhana yang menampilkan tulisan di "layar". Berikut kode nya:

package main

import "fmt"

func main() {
  fmt.Println("hello world")
}

Lalu kita compile kode tersebut:

go build -o hello-world main.go

Daan terbuatlah!

Biasanya untuk menjalankan sebuah program kita—sebagai pengguna—tinggal mengklik 2x program tersebut dan seharusnya program yang sudah kita buat akan berjalan. So, let's try, I guess?

Disitu terlihat bahwa komputer gue membuka sebuah program bernama Terminal dan lalu tulisan "hello world" muncul di program tersebut.

Sejarah mengapa program tersebut berjalan di "terminal" cukup panjang, mungkin bisa baca singkat tentang Pseudoterminal untuk yang penasaran.

Tidak ada yang spesial dari program yang tadi dibuat selain hanya menampilkan tulisan untuk menyapa dunia yang fana ini.

Isolasi File System

Mari kita buat menjadi sedikit menarik. Gue ingin program ini menampilkan daftar berkas yang ada di direktori home gue. Anggap kita ingin buat the next Finder ataupun drop-in replacement nya ls(1) yang hanya bisa menampilkan berkas di direktori home.

package main

import (
  "fmt"
  "io/ioutil"
  "os"
)

func main() {
  home, err := os.UserHomeDir()

  if err != nil {
    panic(err)
  }

  files, err := ioutil.ReadDir(home)

  if err != nil {
    panic(err)
  }

  for _, file := range files {
    fmt.Println(file.Name())
  }
}

Dan ketika dijalankan, berikut tampilannya:

Wow, kita dapat mengakses direktori home si pengguna berikut melihat daftar berkas yang ada disana!

Sekarang bagaimana jika kita ingin melihat apa yang ada di direktori Downloads nya?

package main

import (
  "fmt"
  "io/ioutil"
  "os"
)

func main() {
  home, err := os.UserHomeDir()

  if err != nil {
    panic(err)
  }

  downloads := home + string(os.PathSeparator) + "Downloads"

  files, err := ioutil.ReadDir(downloads)

  if err != nil {
    panic(err)
  }

  for _, file := range files {
    fmt.Println(file.Name())
  }
}

Dan ini ketika dijalankan:

Hahay kita bisa melihat isi dari direktori Downloads nya!

Jika kita bisa mengakses isi direktori tersebut, berarti secara teknis kita bisa melakukan apapun yang kita inginkan dengan itu selagi program yang dijalankan memiliki permission yang sama.

Termasuk bila gue ingin mengubah isi kontennya dengan melakukan enkripsi menggunakan kunci dekripsi yang hanya gue ketahui sehingga gue berhasil membuat ransomware program yang berguna untuk melakukan encryption at rest.

Dari segi pengguna program, tentu ini sedikit membahayakan. Baik dari sisi keamanan ataupun privasi. Di Mac OS, terdapat opsi untuk mengizinkan/melarang "program X melakukan Y" yang salah satunya adalah di permission untuk mengakses direktori Downloads yang dimiliki pengguna.

Ketika kita cabut aksesnya dan menjalankan kembali program tersebut, berikut yang gue dapatkan:

Dan ini intended karena gue tidak memberikan permission untuk mengakses direktori Downloads ke program tersebut. Sayangnya, program tersebut berjalan diatas program lain bernama Terminal. Yang berarti, permission nya gue atur di level program tersebut (Terminal). Yang berarti juga, program lain (seperti ed(1) misalnya) yang dijalankan diatas program Terminal tersebut tidak bisa mengakses direktori Downloads juga.

Sebagai pengguna yang aware dengan masalah ini, kita harus mencari cara agar bisa membatasi apa yang sebuah program dapat lakukan tanpa menganggu program/proses lain. Yang mana ini disebut dengan isolasi.

Dalam teknik isolasi, ada sebuah konsep bernama Sandbox. Program dikurung dalam sebuah program, dan tingkah lakunya diatur oleh si program pengurung tersebut.

Dan salah satu program nya yang membuat pengurungan tersebut dapat terjadi adalah... Docker. Dengan menggunakan kode yang sama, berikut hasil keluarannya:

Ini masih basic, mengingat di "container" kita tidak memiliki direktori "Downloads" dan plus kita tidak handle kesalahan tersebut, by purpose.

Sekarang mari kita buat direktori Downloads tersebut ada dengan menggunakan opsi volume nya Docker.

Di komputer gue yang Linux mengaktifkan SELinux, sehingga error ini intended. Mari kita buat si program ini berhenti panic dengan memberikan opsi :z yang mana do at your own risk™.

Alih-alih memberikan direktori Downloads gue yang "beneran" ke tempat program finter tersebut dijalankan, gue bisa "memalsukan" direktori tersebut sehingga direktori Downloads gue yang "asli" tetap aman.

Disitu terlihat bahwa direktori Downloads yang diakses oleh si program finter tersebut bukanlah direktori Downloads yang ada di OS beneran gue. Tentu kita tidak perlu menggunakan Docker hanya untuk melakukan ini, ada chroot(1) yang sudah berada di sistem operasi UNIX-based sejak 1979, 6 tahun setelah ed(1) rilis.

Benefit dari konsep container in general ini bukan hanya isolasi di file system, salah satu benefit lainnya adalah di isolasi jaringan juga.

Isolasi Jaringan

Let's be quick. Misal kita membuat program lain, let's say kalkulator penghitung dosa. Satu-satunya tugas utama dari program kalkulator adalah menghitung, dan seharusnya kurang make sense jika program tersebut somehow mengakses komputer lain via jaringan internet.

Mari kita buat si program kalkulator tersebut mengirim paket ICMP menggunakan program ping(8) yang ada di komputer si pengguna ke komputer yang memiliki alamat IP 1.1.1.1 di jaringan internet.

package main

import (
  "fmt"
  "os/exec"
)

func main() {
  ping, err := exec.Command("ping", "-c2", "1.1.1.1").Output()

  if err != nil {
    panic(err)
  }

  output := string(ping)

  fmt.Println(output)
  fmt.Println(1 + 2)
}

Jika program tersebut dijalankan, berikut tampilannya:

Setahu gue, tidak ada cara di Mac OS untuk restrict outbound connections selain menyentuh pf(4) dengan tangan sendiri. Tapi gue memiliki program bernama TripMode, yang bisa melakukan "blokir outbound connections" tanpa perlu menyentuh pf.conf(5) ataupun pfctl(8) dengan tangan sendiri.

Tapi sekali lagi, yang gue restrict tersebut adalah program Terminal dan spesifiknya program /sbin/ping tempat dimana si ping(1) dipanggil.

Sekarang gue akan mencoba untuk menjalankan program tersebut berjalan sebagai container. Disini gue akan menggunakan Alpine Linux sebagai base OS nya (contoh sebelumnya scratch)

Menggunakan Alpine sebagai base OS gue pilih agar si program k masih bisa memanggil program ping(8), dan bila menggunakan busybox, kita harus berurusan dengan CAP_NET_RAW ataupun setuid(2) something yang intinya si container harus bejalan dalam mode privileged.

Anyway, karena kita tahu bahwa si program k ini tidak perlu akses internet, kita bisa restrict si program ini untuk tidak bisa mengakses ke jaringan.

Dan sekarang si program panik karena, well, command dari ping(8) yang dijalankan si program k gagal dijalankan (exit code nya bukan 0). Jika di kasus sebelumnya kita melakukan mapping untuk direktori Downloads, sekarang bagaimana bila yang kita map adalah alamat IP dari si 1.1.1.1 yang dipanggil oleh program tersebut?

Sekarang program dapat berjalan tanpa perlu phoning 1.1.1.1 via mengirim paket ICMP. Alternatifnya tentu saja dengan "membawa" program ping kita sendiri yg selalu memberikan exit code 0, tapi karena di kasus ini adalah isolasi jaringan, jadi sepertinya contoh yang lebih relevan adalah seperti yang diatas.

Di contoh diatas kita membuat subnet ip dengan range 1.1.1.0/30, yang intinya hanya ada 2 alamat IP yang bisa digunakan oleh jaringan tersebut (1.1.1.1 dan 1.1.1.2). Container tempat menjalankan program k pasti memiliki alamat IP 1.1.1.2 karena IP 1.1.1.1 digunakan oleh si bridge interface.

Yang intinya, ketika si program tersebut menjalankan ping(8) ke 1.1.1.1, pada dasarnya yang dia ping adalah si bridge interface, bukan komputer yang berada di internet dengan alamat IP 1.1.1.1 alias packet ICMP tersebut tidak keluar dari tempat si container tersebut berjalan.

Kita perlu --privileged diatas untuk menjalankan traceroute(8) untuk keperluan contoh ;)

Application packaging

Jika kita bertanya siapa yang menjalankan sebuah program? jawabannya besar kemungkinan adalah mesin. Banyak yang berkata bila mesin hanya mengerti "bahasa mesin", sedangkan program yang kita buat ditulis dengan sesuatu bernama bahasa pemrograman, sebuah bahasa yang cukup mudah dimengerti oleh manusia sebagai salah satu penulis program.

Sayangnya, mesin tidak mengerti bahasa tersebut karena, well, mesin hanya mengerti bahasa mesin. Banyak yang berkata juga bila bahasa mesin adalah "binary", sebuah sistem angka yang hanya terdiri dari 0 dan 1.

Dari kumpulan angka-angka tersebut mesin bisa mengerti apakah harus menampilkan "hello world" ke layar, mengecilkan volume, ataupun harus membuka pintu kulkas.

Yang menerjemahkan "kode program" yang ditulis oleh pemrogram tersebut adalah... tergantung. Dalam bahasa pemrograman setidaknya ada 2 jenis: compiled dan interpreted. Daripada kita jauh-jauh membahas hal tersebut, intinya, ada sebuah lapisan untuk dapat menjalankan program tersebut.

Kita ambil contoh 2 program sebelumnya yang kita tulis menggunakan bahasa Go. Go adalah compiled language, kode harus dikompilasi terlebih dahulu sebelum dapat dijalankan.

Apa yang dilakukan ketika kompilasi? Itu cerita lain. Jika proses kompilasi berhasil, maka akan terbuat 1 file baru yang biasa disebut dengan "executable {code|file|program}" ataupun "binary program", yang gampangnya, hasil dari kode yang sudah kita buat.

Umumnya ketika melakukan kompilasi, si compiler mengasumsikan bahwa program yang akan dibuat adalah untuk sistem operasi dan arsitektur yang digunakan. Dalam contoh gue, berarti sistem operasi Mac OS dengan arsitektur aarch64 alias arm64.

Jika dijalankan menggunakan sistem operasi berbeda, meskipun dengan arsitektur yang sama, maka akan terjadi error:

Terlebih bila dikompilasi untuk sistem operasi yang sama namun untuk arsitektur yang berbeda (misal untuk x86/amd64):

Jika dijalankan oleh sistem operasi berbeda dan untuk arsitektur berbeda? Sudah jelas chaos.

Solusinya, untuk yang menyediakan prebuilt binary, biasanya menambahkan suffix sistem operasi + arsitektur di nama prebuilt binary tersebut, ini contoh dari program dnsproxy nya AdGuard.

Disitu terlihat bahwa ada untuk sistem operasi Mac OS (darwin), linux, freebsd, dsb plus untuk arsitektur yang digunakan (arm64, amd64, 386, dll).

Tapi tidak semua pemrogram/pengembang menulis program menggunakan compiled language, sebagian lainnya menulis program menggunakan interpreted languages seperti Python; Ruby, PHP, JavaScript, dll karena alasan tertentu. Hal umum yang ditemukan dalam menggunakan interpreted languages adalah sumber kode pasti akan berada disana, karena, well, apalagi yang dibutuhkan oleh si interpreter?

Ambil contoh program Firefly III, yakni sebuah program pengatur keuangan pribadi. Firefly III adalah aplikasi berbasis web dan dibuat menggunakan PHP, syarat utama untuk menjalankan program Firefly III tersebut adalah runtime PHP sudah terpasang di perangkat pengguna.

...berikut dengan ekstensi lain yang dibutuhkan

Syarat kedua adalah mengambil sumber kode nya. Beberapa pengembang mendistribusikannya sebagai berkas arsip untuk alasan efisiensi atau bahkan langsung repositori git nya untuk alasan efektivitas. Di interpreted languages, umumnya yang menjadi sentral utama adalah Package/Dependency Manager, dan hampir setiap bahasa pemrograman yang interpreted memilikinya. Dewasa ini package manager tidak hanya tok bertindak untuk melakukan Package Management melainkan menjadi "task runner" juga, tapi itu cerita lain.

Lalu masalah nyata mulai muncul. Pertama, versi PHP yang dimiliki. Kedua, ekstensi PHP yang digunakan. Ketiga, dependensi kepada native module.

Beberapa masalah tersebut tentu dapat diselesaikan dengan "version manager". Goals utama dari version manager ini adalah membuat "virtual environment", yang gampangnya, setiap project memiliki environment tersendiri yang terisolasi.

Seperti, jika Firefly III membutuhkan ext-curl di PHP7 sedangkan program lain membutuhkan ext-curl di PHP8 karena suatu alasan, dengan menggunakan virtual environment konflik tersebut dapat terhindar karena dalam sebuah virtual environment umumnya sudah tidak menggunakan scope yang global lagi, dan setiap dependensi pasti merujuk ke scope lokal yang mengarah ke namespace (project) tersebut.

Tapi virtual environment dimaksudkan untuk lingkungan development. Pada zaman dahulu kala, ada sebuah mitos bernama "it works on my machine" yang mana program dapat berjalan di komputer X tapi somehow tidak bisa berjalan di komputer Y.

Alasannya? Who knows. Ada banyak kemungkinan jika ingin dipikirkan.

Lalu ada sebuah ide seperti bagaimana bila setiap pengembang/pemrogram menggunakan mesin yang sama untuk lingkungan development dan production, termasuk di bagian dependensi, users, dan konfigurasinya juga?

Tools yang populer digunakan adalah Vagrant, terlepas sistem operasi apa yang digunakan pengembang, jika sistem operasi yang digunakan mendukung virtualisasi, berarit bisa menggunakan Vagrant.

Dengan Vagrant, kita bisa menentukan, jika misalnya lingkungan production kita menggunakan spesifikasi minimum:

• Sistem operasi Ubuntu
• 2 vCPU
• 4 GB memory

Maka kita bisa mendefinisikan spesifikasi tersebut di lingkungan pengembangan kita juga. Lalu misalnya bila aplikasi kita membutuhkan:

• PHP versi 7.4
• Python versi 3.7
• Composer versi 2.4

Maka kita bisa mendefinisikan spesifikasi tersebut di lingkungan pengembangan kita juga. Jika terdapat dependensi tambahan diluar dependensi aplikasi? Tinggal tambahkan di Vagrantfile dan make sure perubahan tersebut terlacak di VCS yang digunakan seperti git(1).

Tapi VM terlalu berat dan tidak cukup aGiLE. Jika menerapkan CI/CD, bayangkan bila setiap push commit ke remote repository harus membuat OS image baru (bila memang harus), menjalankan test di VM yang menggunakan versi OS image tersebut, dan semoga beruntung tidak ada flaky.

Salah satu yang membuat VM terlihat berat adalah adanya Guest OS. Jika sistem operasi yang digunakan (Host OS) adalah Ubuntu dan sistem operasi di VM yang akan dibuat (Guest OS) adalah Ubuntu juga, maka lo ada 2 OS yang sama di satu mesin yang sama, tapi terisolasi.

Lalu pada suatu hari ada sebuah ide untuk membuat "versi VM yang lebih ringan", in fact, ide tersebut sudah ada sejak tahun 2000 di sistem operasi setan merah dan fondasi utama dari ide tersebut sudah ada sejak 1979, yang mana adalah konsep container.

Topik utama dari tulisan ini.

Kunci utama dari container adalah: segala sesuatu menggunakan kernel yang sama yang digunakan oleh Host.

Apapun "sistem operasi" yang digunakan, pasti menggunakan kernel yang sama dengan yang ada di host, sekalipun memiliki struktur direktori root yang berbeda-beda.

Jika dalam konsep VM bagian "magic" nya adalah Hypervisor, bagian magic dari container adalah layer "container runtime" nya, yang besar kemungkinan yang dimaksud adalah containerd (atau CRI-O klo lo fans berat Red Hat).

Oke kita sudah sejauh ini, lalu timbul pertanyaan: Mengapa menggunakan teknologi container alih-alih VM?

Apa yang membedakan secara teknis antara VM dan container?

Mengapa kita disini?

Ada setidakya 3 sistem operasi yang salah satunya digunakan oleh pengembang/pemrogram: Windows, GNU/Linux dan Mac OS (atau *BSD).

Setiap sistem operasi pasti memiliki hypervisor nya sendiri: Hyper-V untuk Windows, Hypervisor.Framework (atau xhyve) untuk Mac OS, bhyve untuk *BSD dan QEMU untuk GNU/Linux.

Tapi sekarang kita sedang membahas tentang container, dan teknologi container sangat berbeda jauh dengan virtualisasi. Karena bagian magic dari container adalah Container runtime nya, pertanyaannya adalah: apakah container runtime tersebut dapat berjalan di komputer saya?

containerd pada saat tulisan ini dibuat hanya bisa berjalan di Linux dan Windows. Gue personally tidak berani banyak bahas tentang Windows karena gue tidak menggunakan sistem operasi tersebut. Anyway, karena hal itu, bagaimana cara menjalankan "container" di sistem operasi seperti Mac OS?

Well, pada dasarnya, jawabannya adalah "kurang memungkinan", jika jawaban "mustahil" terdengar terlalu pesimis. Jika memasang Docker Desktop di Mac OS pada dasarnya kita dapat menjalankan container, dan gue ga bisa banyak bahas tentang Docker Desktop mengingat gue tidak menggunakannya.

Dan ketika berbicara tentang "menjalankan container" besar kemungkinan yang dimaksud adalah "menjalankan OCI image oleh OCI runtime via CRI"

Gue yakin Docker Desktop di Mac OS akan menjalankan linux-based VM (remember boot2docker?) dan si Docker (a.k.a Docker Engine) berinteraksi dengan VM tersebut.

Personally gue pakai colima di Mac OS yang mana dia membuat linux-based VM yakni Alpine Linux yang menjalankan CRI (the CRI daemon, gue menggunakan containerd langsung) disana (VM).

Kunci utama kedua dari teknologi container ini adalah OCI image, yang umumnya didefinisikan melalui sebuah berkas bernama Dockerfile.

Di berkas tersebut didefinisikan dari bagaimana si aplikasi tersebut dapat berjalan sampai ke bagaimana si aplikasi tersebut berjalan. Seperti, jika aplikasi tersebut dapat berjalan setelah melakukan instalasi via npm install, maka di Dockerfile kita perlu mendefinisikan instruksi tersebut.

Jika aplikasi tersebut berjalan dengan menggunakan pm2, maka di Dockerfile kita perlu mendefinisikan instruksi tersebut.

Ketika membuat Dockerfile, kita perlu mendefinisikan base os yang akan digunakan. Ini menurut gue tidak terlalu penting (dan tidak mandatory anyway), bagian penting di definsi base os ini hanyalah di bagian "package manager yang digunakan" dan "dependensi ke kernel". Misal, base os yang umum digunakan adalah Alpine dan Ubuntu/Debian.

Alpine menggunakan musl dan sedangkan Ubuntu/Debian menggunakan glibc dalam penggunaan libc. Namun di banyak kasus (khususnya bila tidak berinteraksi langsung dengan C library ataupun bergantung dengan "native module") besar kemungkinan kita tidak perlu memusingkan "implementasi libc" mana yang bisa membuat aplikasi kita berjalan.

Default gue selalu menggunakan Alpine jika scratch tidak memungkinkan. Jika memang ada satu kebutuhan yang tidak bisa menggunakan Alpine sebagai base OS, gue akan pertimbangkan menggunakan base OS lain sekalipun itu busybox ataupun amazonlinux.

Manfaat teknologi container untuk developer

Di kebanyakan kasus, langkah "mengetahui cara membuat OCI image" saja gue rasa sudah cukup untuk pengembang program.

Tidak akan ada lagi "it works on my machine" apalagi "it works on my docker" unless lo adalah orang terpilih yang terkena kesialan tersebut, mungkin karena karma.

Dewasa ini penggunaan container pun tidak hanya di lingkungan production, melainkan terlibat di development environment juga. Biasanya bila aplikasi yang dibuat bergantung dengan sistem eksternal yg let's say dengan Redis, PostgreSQL, MongoDB, NFS, ataupun FTP server.

Tidak jarang gue mendapatkan pertanyaan dari "gimana cara nyambung ke postgres di container X?", "kenapa pakai IP 172.17.0.1?", "kenapa ga bisa diakses via localhost?" dsb.

Ketika pertama kali mempelajari Docker, dan ekosistem "isolated environment" belum seperti sekarang, gue masih nyaman dengan Vagrant. Box di Vagrant yang gue gunakan di lingkungan development sama persis dengan apa yang akan ada di lingkungan production. Dan gue selalu yakin bahwa 127.0.0.1:5432 selalu mengarah ke postgres yang gue butuhkan.

Pada saat itu hal possible yang bisa gue lakukan adalah dengan menyewa VPS yang provide custom image untuk bisa menjalankan aplikasi yang gue kembangkan didalam Vagrant tersebut, meskipun bisa saja gue lakukan secara imperatif.

Lalu PaaS mulai bermunculan. Heroku menjual git push heroku master sebagai keunggulan utamanya dan it somewhat works. File legend yang ada di project/repository yang menggunakan Heroku adalah Procfile untuk memberitahu Heroku apa yang doi harus lakukan terhadap aplikasi tersebut untuk bisa nyala dan jalan.

Setelah itu muncul Flynn dan Dokku, yang menawarkan Heroku-like experience, tapi self-hosted. Flynn dan Dokku menggunakan Docker dan gue rasa ini juga cikal bakal populernya Buildpacks, dan jangan tanya gue kenapa tidak membahas Cloud Foundry.

Seiring berjalan waktu, container menjadi platform. PaaS sudah bukan lagi tentang "Node.js hosting", "Ruby on Rails hosting", "PHP hosting" dan lain sebagainya. Melainkan, menjadi "OCI compliant image hosting". Baik dukungan out of the box (yang biasanya pakai buildpacks) ataupun membawa OCI image (container image) nya sendiri.

Cara pengembang/pemrogram membuat aplikasi pun jadi berubah. Dari penerapan 12 factor sampai ke praktik untuk membuat aplikasi yang cLoUD nAtiVE.

Dan fondasinya, somehow adalah container, setidaknya untuk saat ini. Pengembang dituntut untuk membuat aplikasi untuk berjalan di container runtime, yang besar kemungkinan container runtime yang dimaksud adalah Docker (they did great marketing by the way).

Penutup

Jika penerapan teknologi container digunakan karena alasan "keamanan", big no. Isolasi memang bisa membantu sedikit dalam perihal keamanan, tapi jangan lupa, program yang berjalan dalam container berada diatas kernel yang sama.

Jika penerapan teknologi container digunakan karena alasan untuk mempermudah dalam distribusi dan menjalankan aplikasi, gue personally cukup setuju.

Dan baik untuk diketahui bahwa container tidak selamanya selalu tentang Docker. Teknologi container != Docker. Docker (Docker Engine ataupun Docker Desktop) hanyalah tools untuk mempermudah pengembang yang tidak ingin tahu menahu tentang teknologi container untuk membuat dan menjalankan container. Dan gue rasa perlu diapresiasi bahwa Moby (ataupun dotCloud) berhasil mempopulerkan teknologi container meskipun Jails nya FreeBSD dan LXC/LXD sudah ada sebelum Docker menjadi sesuatu.

Bagian menarik yang menjadi salah satu alasan gue menulis ini adalah tentang pertanyaan "mengapa lo menggunakan Docker?".

Beberapa mungkin menjawab dengan "kita menggunakan Docker karena... kita menggunakan Docker", dan semoga tulisan ini dapat membantu memberikan jawaban alternatif yang sedikit rasional.

;)