10 Tahun Kontainer Docker

 (cacm.acm.org)
11 poin oleh GN⁺ 2026-03-08 | 1 komentar | Bagikan ke WhatsApp
  • Makalah ACM ini menyoroti proses evolusi teknis Docker, yang sejak rilis pertamanya pada 2013 secara mendasar mengubah cara developer membangun, mendistribusikan, dan menjalankan aplikasi, sekaligus merangkum puluhan tahun riset sistem yang tersembunyi di balik CLI yang tampak sederhana
  • Fondasi teknis utama Docker adalah cara mencapai isolasi proses tanpa virtual machine dengan memanfaatkan namespace Linux, dengan menggabungkan 7 jenis namespace yang ditambahkan secara bertahap sejak 2001 untuk mewujudkan kontainer yang ringan
  • Untuk mendukung macOS dan Windows, Docker mengadopsi arsitektur yang tidak lazim dengan menanamkan library virtual machine monitor (HyperKit) di dalam aplikasi desktop, menjalankan Linux di dalam proses pengguna alih-alih memakai pendekatan hypervisor tradisional
  • Saat ini Docker mendukung perangkat keras heterogen seperti ARM·RISC-V serta workload AI, dan telah menjadi infrastruktur pengembangan standar di cloud, desktop, dan edge
  • Dengan naiknya workload AI, manajemen dependensi GPU muncul sebagai tantangan baru, dan evolusi Docker terus berlanjut lewat dukungan GPU melalui CDI (Container Device Interface) serta integrasi TEE (Trusted Execution Environment)

Asal-usul teknis

  • Pada awal 2000-an, memasang banyak dependensi secara manual di distribusi Linux serta mengompilasi dan mengonfigurasi perangkat lunak secara langsung adalah hal yang umum, dan kebangkitan cloud computing pada 2010 membuat proses ini makin kompleks
  • Docker menyederhanakannya dengan memungkinkan developer mengemas aplikasi dan seluruh dependensinya sebagai image filesystem ("container") sehingga dapat dijalankan di mesin mana pun yang hanya memasang Docker
  • Berbeda dari virtual machine, ini bisa dijalankan hanya dengan beberapa perintah tanpa harus memasang seluruh sistem operasi

Alur kerja umum

  • Saat developer menulis Dockerfile, mereka mendefinisikan proses build bertahap berbasis sintaks shell
    • Contoh situs web Python: dimulai dengan FROM python:3, lalu menjelaskan pemasangan dependensi, penyalinan kode, eksposur port, hingga perintah eksekusi dalam satu berkas
  • Membuat image container dengan docker build lalu mendorongnya ke Docker Hub dengan docker push
  • Menjalankannya sambil menentukan mount volume data dan eksposur port jaringan seperti docker run -v data:/app/data -p 80:80
  • Sejak 2013, CLI telah berkembang besar dan backend didesain ulang sepenuhnya, tetapi alur kerja dasar menulis Dockerfile → docker build → docker run tetap konsisten
  • Ditemukan lebih dari 3,4 juta Dockerfile yang berada di root repositori publik di GitHub

Cara kerja internal: namespace Linux

  • Kernel OS mengisolasi memori proses, tetapi banyak sumber daya sistem seperti filesystem, berkas konfigurasi, dan library dinamis tetap dibagikan
    • Sangat sulit memasang banyak aplikasi pada mesin yang sama jika memiliki kebutuhan library dinamis yang saling bertentangan
    • Juga bisa timbul interferensi yang tidak diinginkan antaraproses seperti bentrokan port jaringan
  • Menjalankan tiap aplikasi di dalam virtual machine (VM) terpisah bisa menyelesaikannya, tetapi menjadi sangat berat karena kernel, filesystem, cache, dan bridge network yang duplikatif
    • Karena tiap guest OS berjalan mandiri, deduplikasi storage dan memori juga sulit dilakukan
  • chroot() pada Unix v7 tahun 1978 memungkinkan root filesystem terpisah, tetapi tidak mendukung komposisi filesystem untuk banyak aplikasi
  • Nix dan Guix menyelesaikannya dengan repackaging direktori per aplikasi + dynamic linking, tetapi sulit diterapkan pada perangkat lunak proprietari dan tidak dapat menyelesaikan masalah bentrokan port jaringan
  • Docker memilih namespace Linux: tiap proses dapat mengontrol secara terpisah bagaimana ia mengakses sumber daya bersama seperti file dan direktori
    • Contoh: dua proses di namespace berbeda dapat menafsirkan /etc/passwd secara berbeda sebagai /alice/etc/passwd dan /bob/etc/passwd
    • Namespace hanya diterapkan saat membuka sumber daya, dan setelah itu file descriptor bekerja sebagai sumber daya kernel biasa tanpa overhead tambahan
  • Riwayat pengenalan namespace
    • 2001 Linux 2.5.2: mount namespace
    • 2006 Linux 2.6.19: IPC namespace
    • 2007 Linux 2.6.24: network stack namespace
    • Mendukung total 7 jenis namespace
  • Tidak seperti Plan 9, namespace tidak dirancang sejak awal melainkan ditambahkan secara bertahap, sehingga bersifat low-level dan sulit digunakan
  • Fitur serupa di FreeBSD dan Solaris juga tidak mencapai penggunaan luas
  • Kontribusi inti Docker pada 2013: menemukan titik keseimbangan praktis antara isolasi berat ala VM dan kemudahan penggunaan elemen dasar OS

Struktur eksekusi kontainer Linux di Docker

  • Docker menggunakan arsitektur client-server, terdiri dari daemon server (dockerd) yang berjalan di host dan klien CLI yang mengirim permintaan melalui RESTful API
  • Sekitar 2015, daemon monolitik dipecah dan disusun ulang menjadi komponen-komponen terspesialisasi
    • BuildKit: merakit image filesystem
    • containerd: menginstansiasi image menjadi container yang sedang berjalan serta mengelola sumber daya jaringan dan storage

Image container

  • Saat docker build dipanggil, dibuat image layered filesystem yang merepresentasikan executable dan data dari Dockerfile
    • Layer paling bawah: distribusi OS seperti Debian atau Alpine Linux (atau dirakit manual sebagai arsip tar)
    • Layer berikutnya: perbedaan filesystem yang dihasilkan dari eksekusi tiap perintah dalam Dockerfile
  • Disimpan dalam sistem storage content-addressed: dikelola dengan hash image filesystem sebagai kunci
    • Deduplikasi yang efisien, menjamin immutability, dan verifikasi manipulasi melalui hash
  • Pada 2016, Open Container Initiative (OCI) menstandarkan format image, dan kini ada banyak implementasi independen
  • Memanfaatkan filesystem Linux overlayfs, btrfs, ZFS untuk melakukan snapshot dan clone layer copy-on-write secara efisien
  • Mendukung lazy-pulling image melalui storage snapshotter stargz

Instans container

  • Saat docker run dipanggil, sumber daya sistem dialokasikan untuk membuat proses yang diisolasi oleh namespace ("container") dari image OCI
  • Tugas yang dijalankan containerd saat menyiapkan namespace yang dibutuhkan tiap container secara dinamis:
    • Mendefinisikan cgroups (control groups) proses untuk isolasi sumber daya dan pembatasan kecepatan I/O
    • Memetakan ulang port jaringan lokal di dalam container ke port yang diekspos ke luar pada antarmuka host
    • Menghubungkan volume storage mutable dari filesystem host untuk status aplikasi yang persisten
    • Mengisolasi pohon proses container dengan PID namespace
    • Dengan user namespace, memetakan UID lokal di dalam container ke UID lain di host (misalnya UID 1000 di dalam container → UID 12345 atau 23456 di host)
  • Ada sedikit overhead dalam konfigurasi namespace, tetapi jauh lebih rendah daripada memunculkan Linux VM penuh, dan pada umumnya kurang dari 1 detik
  • Kernel Linux melakukan garbage collection terhadap container yang telah berhenti seperti proses biasa

Melampaui Linux: dukungan macOS dan Windows

  • Berkat arsitektur client-server, CLI dapat mengirim perintah ke instance Docker jarak jauh melalui koneksi jaringan yang aman
  • Pada 2015, Docker telah diadopsi luas dalam pengembangan Linux, tetapi menghadapi hambatan kegunaan karena developer macOS/Windows tidak bisa menjalankan container Linux
    • Mayoritas developer menggunakan macOS/Windows sebagai lingkungan pengembangan utama, tetapi image filesystem Docker hanya dapat berjalan di kernel Linux
    • Dengan naiknya public cloud, Linux lebih disukai sebagai lingkungan deployment

Membangun aplikasi Docker for Mac

  • Kendala utama: harus berjalan tanpa konfigurasi tambahan bagi pengembang yang terbiasa dengan Docker versi Linux, dan harus bisa menjalankan image Docker yang sama
  • Pendekatan lama (menjalankan Linux secara terpisah di samping OS desktop) dibalik dengan menanamkan hypervisor di dalam aplikasi ruang pengguna macOS/Windows, lalu menjalankan Linux di sana
    • Terinspirasi dari riset unikernel: membuktikan bahwa komponen OS dapat ditanamkan secara fleksibel di dalam aplikasi yang lebih besar
  • HyperKit: library VMM yang menjalankan kernel Linux dalam proses pengguna biasa dengan memanfaatkan ekstensi virtualisasi perangkat keras pada CPU Intel
    • Kernel Linux tertanam menjalankan daemon Docker, yang lalu mengelola kontainer dan berperan sebagai endpoint server Docker biasa
    • Semua detail pengelolaan Linux disembunyikan di dalam aplikasi desktop → docker build dan docker run di desktop diteruskan ke instance Linux tertanam sehingga "langsung berfungsi"
  • Pendekatan ini kemudian diadopsi oleh sistem kontainer lain seperti Podman, dan menjadi cara standar menjalankan kontainer di macOS/Windows

LinuxKit: distribusi Linux kustom tertanam

  • Distribusi Linux kustom yang dirancang untuk ditanamkan sebagai komponen aplikasi lain, bukan dijalankan secara mandiri
  • Membangun ruang pengguna kustom yang hanya memuat komponen minimum yang diperlukan untuk menjalankan kontainer Docker demi meminimalkan waktu startup aplikasi
  • Menjalankan setiap komponen tunggal di dalam kontainer, sehingga tidak ada apa pun yang berjalan di root namespace yang dipakai saat boot
  • Memanfaatkan filesystem copy-on-write dan network namespace yang sama seperti yang digunakan kontainer Docker
  • Kombinasi LinuxKit + HyperKit memungkinkan proses Linux melakukan boot dengan kecepatan yang hampir sama dengan proses macOS native
  • Dirilis pada 2016 sebagai aplikasi Docker for Mac dan Windows

Masalah jaringan dan solusi SLIRP

  • Koneksi jaringan dari kontainer Linux tertanam ke macOS/Windows ternyata merupakan masalah yang tak terduga sulitnya
  • Metode Ethernet bridging yang ada memerlukan pengelolaan jaringan yang kompleks, dan firewall serta pemeriksa virus di desktop perusahaan mendeteksinya sebagai potensi trafik berbahaya, sehingga memicu ribuan laporan bug dari pengguna beta
  • Solusi SLIRP: alat yang pertama kali digunakan pada pertengahan 1990-an untuk menghubungkan Palm Pilot PDA ke internet
    • Saat TCP handshake dari kontainer terjadi, frame Ethernet dikirim ke host melalui memori bersama dengan protokol virtio
    • Memanfaatkan library unikernel dari MirageOS untuk mengubah permintaan jaringan Linux menjadi native socket call macOS/Windows
    • Stack TCP/IP ruang pengguna vpnkit yang ditulis dalam OCaml menerimanya di OS host lalu memanggil syscall macOS connect()
    • Dari sudut pandang kebijakan VPN, trafik keluar dikenali sebagai berasal dari aplikasi Docker, bukan dari mesin terpisah
  • Setelah vpnkit diterapkan dalam beta test 2016, laporan bug dari pengguna perusahaan turun lebih dari 99%
  • Pendekatan SLIRP kemudian juga diadopsi di bidang cloud serverless, menunjukkan bagaimana teknik jaringan dial-up lama dipakai untuk menyelesaikan masalah baru dalam pengelolaan kontainer

Menangani trafik jaringan masuk

  • Saat kontainer Linux mendengarkan port, port tersebut tidak otomatis terekspos ke internet kecuali diminta secara eksplisit di CLI (misalnya docker run -p 80:80 nginx)
  • Pengalaman pengguna yang ideal: port kontainer muncul langsung di IP desktop sehingga bisa diakses lewat browser di http://localhost:8080
    • Virtualisasi desktop lama seperti VMware Fusion mengekspos IP perantara sementara, bukan localhost
  • Memasang program eBPF kustom pada kernel LinuxKit → memicu pembuatan listening socket yang sesuai pada host desktop → mengaktifkan port forwarder
  • Hasilnya: saat menjalankan kontainer Linux di Mac, kontainer langsung bisa diakses lewat localhost, memberikan pengalaman pengembang yang sama seperti di mesin Linux native

Penyimpanan

  • Pengembang perlu mengedit kode secara lokal sambil menjalankan kode dan pengujian di dalam kontainer
  • Di Linux, akses file langsung dilakukan lewat bind mount dengan docker run -v /host:/container
  • macOS dan Windows memakai kernel yang berbeda, sehingga bind mount tidak berfungsi
    • Docker menggunakan protokol memori bersama virtio-fs yang berasal dari hypervisor KVM untuk meneruskan operasi filesystem ke host (dalam format permintaan FUSE)
    • Host menerima permintaan ini lalu memanggil syscall open, read, write yang sesuai
  • Kode dan data pengembang tetap berada di filesystem host sehingga bisa diakses oleh alat pencadangan dan pencarian seperti Apple Time Capsule atau Spotlight

Windows Services for Linux (WSL)

  • Pada 2017 Microsoft merilis WSL: menjalankan aplikasi Linux langsung di Windows
    • Versi pertamanya memakai pendekatan library OS yang mengubah secara dinamis system call biner Linux menjadi system call Windows, alih-alih virtualisasi
    • Berhasil untuk banyak aplikasi, tetapi system call yang didukung tidak cukup untuk menjalankan kontainer Docker
  • Pada 2018, WSL2 dirilis: didesain ulang agar serupa dengan Docker for Mac, yaitu menjalankan VM Linux penuh di latar belakang
    • Docker pada WSL2 menjalankan daemon dan kontainer pengguna di dalam distribusi LinuxKit WSL
    • Menangani Docker API dan port forwarding jaringan dari Windows sendiri serta dari distribusi Linux lain
  • Arsitektur kunci yang memungkinkan evolusi lintas platform kontainer Docker: pendekatan library OS yang mendaur ulang kode yang secara tradisional merupakan "kode khusus kernel" menjadi library ruang pengguna yang bisa ditanamkan ke aplikasi lain
  • Keberhasilan arsitektur ini terbukti dari sifatnya yang tak terlihat namun ada di mana-mana: jutaan pengembang memakai Docker setiap hari tanpa perlu memikirkan OS apa yang sedang menjalankannya

Alur kerja pengembang baru: arsitektur multi-CPU

  • Pada masa awal Docker, sebagian besar workload cloud berbasis arsitektur Intel
  • Situasi berubah dengan hadirnya prosesor Amazon Graviton ARM pada 2018 dan CPU Apple M1 ARM pada 2020
    • Menjalankan workload di ARM memungkinkan penghematan biaya dan peningkatan performa
  • Dibutuhkan dukungan multi-arsitektur CPU seperti Intel, ARM, POWER, dan RISC-V dalam image Docker yang sama
  • Di sisi server, format image OCI diperluas menjadi multiarch manifests
  • Untuk membangun image multi-arsitektur CPU pada satu host, digunakan fitur Linux binfmt_misc
    • QEMU memungkinkan translasi transparan antara biner ARM dan Intel
    • Overhead terutama muncul hanya pada tahap build, sementara image multi-arsitektur hasilnya dapat berjalan native di host mana pun
  • Apple memperkenalkan dukungan perangkat keras dan perangkat lunak untuk translasi instruction set CPU melalui Rosetta → mudah diintegrasikan ke arsitektur Docker
  • Kini menjalankan kontainer Intel dan ARM berdampingan telah menjadi alur kerja pengembang yang umum

Pengelolaan rahasia melalui Trusted Execution Environment (TEE)

  • Dalam lingkungan kontainer, pengelolaan rahasia (secrets) seperti kata sandi atau API key selalu menjadi tantangan
    • Harus disuntikkan secara dinamis tanpa di-bake ke image filesystem
  • Docker mendukung socket forwarding, sehingga domain socket lokal dapat di-mount ke kontainer
    • Untuk Docker for Mac/Windows, socket juga diteruskan hingga Linux VM
    • Sistem manajemen kunci seperti ssh-agent dapat digunakan di dalam kontainer tanpa mengekspos kunci secara langsung
  • Socket forwarding menyediakan tingkat perlindungan dasar, tetapi terhadap malware dalam rantai pasok perangkat lunak yang terus membesar, diperlukan lebih banyak lapisan pertahanan
  • Perlindungan hypervisor diterapkan langsung di dalam runtime kontainer untuk meningkatkan tingkat perlindungan lintas-kontainer
  • Trusted Execution Environment (TEE): fitur hardware pada CPU modern untuk membuat "confidential VMs" yang dapat melindungi data rahasia bahkan dari host OS
    • Pembatasan akses data dapat diterapkan melampaui batas aplikasi, kernel, dan hypervisor
    • Namun, konfigurasi dan penggunaan TEE memiliki kompleksitas pengelolaan yang mirip dengan virtualisasi OS
  • Kelompok kerja Confidential Containers sedang mengembangkan aplikasi yang berjalan di dalam TEE dan dikelola dengan Docker
    • Docker CLI meneruskan pesan terenkripsi dari TEE lokal di desktop, melewati host, hingga ke lingkungan TEE cloud jarak jauh
    • Developer dapat melakukan autentikasi ke lingkungan cloud sensitif tanpa harus datang ke lokasi, dan kredensial disimpan aman di enclave desktop

Dukungan GPGPU untuk workload AI

  • Munculnya workload AI menghadirkan tantangan yang sepenuhnya baru: sebagian besar workload machine learning berjalan di GPU
  • Masalah intinya: workload GPU memerlukan driver GPU kernel dan library user-space yang benar-benar cocok, sementara banyak kontainer berjalan di atas satu kernel bersama
    • Jika dua aplikasi memerlukan versi berbeda dari driver GPU kernel yang sama, akan muncul konflik mendasar yang sama seperti yang semula ingin diselesaikan Docker
  • Sejak Maret 2023, Docker mendukung CDI (Container Device Interface)
    • Mengustomisasi image filesystem pada saat kontainer dijalankan
    • Melakukan bind mount file device GPU dan dynamic library khusus GPU serta membangun ulang cache ld.so
  • CDI menjamin portabilitas image antar kelas atau vendor GPU tertentu, tetapi antar OS atau merek hardware yang berbeda masih belum sepenuhnya mulus
    • Dynamic library yang ditambahkan CDI mendefinisikan API yang berbeda-beda, sehingga tidak ada padanannya dengan ABI system call Linux yang stabil, yaitu antarmuka tradisional kontainer
    • Alasan aplikasi untuk GPU Nvidia sulit dijalankan di CPU Apple seri M: dukungan virtualisasi GPU di berbagai hardware belum cukup matang untuk menerjemahkan instruksi vektor
  • Bersama komunitas kontainer dan produsen GPU, sedang dikembangkan cara yang lebih fleksibel dan aman untuk mengelola dependensi terkait GPU
  • Diharapkan inisiatif portable interface dapat mencapai konsensus

Kesimpulan

  • Docker dimulai pada 2013 dengan tujuan membantu developer membangun, membagikan, dan menjalankan aplikasi dengan lebih mudah
  • Kini Docker telah terintegrasi dalam workflow pengembangan cloud dan desktop standar, digunakan setiap hari oleh jutaan developer di seluruh dunia, dan menangani miliaran request per bulan
  • Tujuan yang konsisten adalah mempertahankan komunitas open source yang aktif dan beragam yang membangun standar untuk interoperabilitas
    • CNCF (Cloud Native Computing Foundation) berperan sebagai pengelola berbagai komponen inti
    • Open Container Initiative (bagian dari Linux Foundation) berperan sebagai pengelola format image
  • Saat ini banyak implementasi dari elemen-elemen tersebut yang aktif, dan deployment terus meningkat di cloud, desktop, serta lingkungan edge seperti otomotif, mobile, dan wahana antariksa
  • Pada 2025, workflow developer pada umumnya mengintegrasikan pengujian dan deployment berkelanjutan, language server IDE, serta bantuan AI melalui agentic coding
  • Dari sudut pandang Docker, workflow inti "build and run" masih sangat mirip dengan 10 tahun lalu, tetapi dukungan sistem untuk mengurangi friksi di berbagai lingkungan telah diperkuat secara signifikan
  • Tujuannya adalah menjadikan Docker sebagai pendamping tak terlihat yang membantu developer men-deploy kode lebih cepat, serta dirancang agar dapat diskalakan untuk workflow coding AI modern

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-08
Komentar Hacker News

  • Saat Docker pertama kali muncul, saya sudah muak dengan klaim "inovasi" yang muncul lagi
    Saya tidak suka NoSQL yang setengah matang, microservices yang dipaksakan, dan tren mengubah setiap pemanggilan fungsi menjadi RPC
    Tapi sekarang saya cukup sering memakainya justru karena kesederhanaannya
    Meski begitu, container buatan orang lain tetap terasa seperti neraka. Saya setidaknya berusaha menjaganya tetap sederhana, tetapi ada orang yang memasukkan terlalu banyak hal sampai terkesan mereka sendiri pun tidak paham proses deploy-nya
    Sekarang rasanya kita hidup di zaman ketika kode yang bahkan belum pernah dilihat langsung oleh developernya sendiri membanjir berkat LLM

    • Melihat tim DevOps melakukan Zoom call tanpa akhir setiap dini hari untuk memperbaiki masalah container, saya jadi yakin tidak ada yang benar-benar tahu apa yang sedang terjadi

  • Sudah ada banyak percobaan, tetapi alasan Dockerfile bertahan pada akhirnya adalah karena fleksibilitasnya
    Strukturnya terasa familier karena seperti cara kerja lama: menyalin file dan menjalankan perintah
    Kelihatannya memang agak kasar, tetapi fleksibilitas sederhana inilah yang tampaknya akan tetap dominan ke depan

    • Karena tidak ada alat build yang netral terhadap bahasa, pada akhirnya kita menjalankan perintah arbitrer yang memanggil package manager masing-masing bahasa
      Kalau semua orang memakai Nix atau Bazel, mungkin docker build sudah jadi bahan tertawaan
    • Ada hambatan yang menghalangi build yang reproducible
      Jika hash berbeda antar-build, hasilnya tidak bisa dipercaya, jadi selama hal seperti waktu modifikasi file ikut masuk ke hash, konsistensi penuh akan sulit dicapai
    • Tidak adanya repositori terpusat seperti Docker registry adalah titik bottleneck bagi solusi alternatif
      Secara pribadi saya suka mkosi, tetapi tidak semua orang ingin memulai dari template OS kosong
    • Nix sangat unggul untuk membuat container Docker
    • Saya merasa integrasinya dengan registry seharusnya lebih kuat
      Dalam kebanyakan kasus, orang hanya pull dari public registry dan push ke private registry, jadi image lokal hampir tidak pernah dipakai
      Agak tidak efisien, tetapi tampaknya belum cukup merepotkan untuk diubah

  • Saya ingat Docker pertama kali diperkenalkan pada PyCon US Santa Clara 2013
    Kalau melihat video presentasi di YouTube saat itu, itu benar-benar momen bersejarah
    Sepertinya ada kebingungan karena waktu publikasi paper dan waktu presentasi aslinya berbeda, tetapi kurang lebih ini cerita dari 13 tahun lalu

    • Judulnya sekadar dimaksudkan sebagai "melihat kembali ke masa lalu"
      "Twelve years of Docker containers" terasa kurang natural dibanding "A decade of Docker"
    • Sebenarnya 2014 yang benar
      Saya ingat posting pengumuman awal di HN
      Saat itu saya sudah lelah dengan alternatif seperti LXC atau Vagrant, dan Docker benar-benar terasa seperti penyelamat

  • Menarik bahwa Docker mendaur ulang alat dial-up tahun 1990-an bernama SLIRP untuk melewati firewall

    • Podman juga sempat memakai slirp4netns, tetapi belakangan beralih ke Pasta
    • SLIRP bukan alat untuk Palm Pilot, melainkan utilitas yang dibuat agar pengguna akun shell yang tidak bisa memakai SLIP/PPP dapat meniru koneksi internet
      Koneksi masuk memang tidak didukung, tetapi konsepnya seperti pendahulu NAT
    • Memakai alat untuk Palm Pilot guna menembus firewall adalah ide yang gila, tetapi kepepet seperti itulah yang melahirkan hack infrastruktur terbaik
    • SLIRP digunakan untuk network namespace 'rootless', yaitu cara menghubungkan container ke jaringan host tanpa hak root

  • Saya ingin memakai Docker, tetapi setiap kali mencobanya selalu ada fitur yang saya butuhkan namun tidak tersedia
    Mungkin karena saya menggunakan tech stack yang tidak umum

  • Kehebatan Docker adalah menjadikan "berjalan di komputer saya" sebagai standar industri
    Sekarang kita hidup di era ketika komputer itu sendiri bisa "dikirim" ke production

    • Sebagai salah satu penulis, sebelum Docker saya bekerja dengan Xen, dan Docker adalah peristiwa yang mengubah budaya IT itu sendiri
      Dulu deployment adalah prosedur besar, tetapi sekarang kita bisa langsung mendeploy filesystem
      Revolusi coding agent saat ini juga terasa seperti perubahan budaya yang serupa
    • Inti Docker adalah membuat build bisa ditangkap sebagai proses yang bisa diulang
      Jika lingkungan bisa direproduksi dengan skrip 10 baris, maka "mendeploy mesin" juga bukan ide yang buruk
    • Docker adalah semacam static linking yang ekstrem
      Kita perlu bertanya pada diri sendiri mengapa pendekatan seperti ini terasa begitu menarik
    • Rasanya "jalan di laptop" sekarang berubah menjadi "jadikan laptop itu container lalu masukkan ke pipeline"
      Abstraksi selalu menang karena memperbaiki masalah mendasarnya terlalu sulit
    • Melihat container buruk mencoba mengelola service sampai lewat Dockerfile, alih-alih memakai sistem packaging yang layak, benar-benar melelahkan

  • Saya tidak terlalu paham networking, tetapi saya ingin container di Mac punya alamat IP terpisah
    Saya ingin mengaksesnya lewat container_ip:80 tanpa port mapping
    Di Linux ini memungkinkan, tetapi di Mac harus lewat VM sehingga jadi rumit
    Saya pernah mencoba metode berbasis WireGuard, tetapi selalu rusak setiap kali Docker di-update
    Akan bagus kalau ada cara yang didukung resmi

    • Sebagai engineer Docker, saya sarankan mencoba ekstensi Tailscale
      Tailscale Docker Extension menangani konfigurasi secara otomatis
      Kalau alasan ingin menghindari port mapping adalah karena port dinamis, coba gunakan opsi --net=host dan aktifkan Host Networking
    • Saya tidak punya Mac, tetapi sebagai alternatif open source saya merekomendasikan proyek Colima

  • Tahun 2013 adalah tahun panen besar untuk packaging ketika Docker, Guix, dan NixOS sama-sama muncul
    Saya menemukan hal ini saat menulis paper terkait
    Saya jadi penasaran apakah setelah itu pernah ada lagi satu tahun dengan begitu banyak proyek hebat yang lahir bersamaan

    • hg dan git lahir dengan selisih hanya beberapa minggu, lalu fossil menyusul tak lama kemudian
    • Sejujurnya saya merasa hanya Docker yang benar-benar berhasil populer secara luas
      Guix dan Nix masih tetap berada di kalangan pengguna terbatas

  • Dengan ML dan AI masuk ke mana-mana, ukuran image membesar secara eksponensial
    Hanya torch saja sudah bisa memakan beberapa GB
    Saya rindu image lama yang ukurannya 30MB

    • Saya bahkan pernah melihat image yang memasang TensorFlow dua kali
      File tidak bisa dibagi antar-layer, jadi pemborosannya besar
      Karena itu saya sedang membuat sendiri registry alternatif yang mendukung dedupe per file
    • Saya sendiri memakai beberapa container Ruby dan PHP di atas Alpine Linux immutable berbasis ISO, dan totalnya sekitar 750MB

  • Fakta bahwa Docker menyamarkan diri seperti VPN untuk mengecoh software keamanan enterprise benar-benar sangat menarik
    Sebagai sejarah teknis pun ini contoh yang menyenangkan