Driver jaringan pada Chapter Network Driver mengatur lalu lintas, sementara di lapisan paling bawah Docker selalu sibuk dengan pekerjaan lain: menyusun layer image menjadi rootfs dan menampung tulisan container. Pekerjaan itu dikerjakan oleh storage driver — atau, pada Engine modern, oleh pasangan containerd image store dan snapshotter-nya — dan pilihan keduanya menentukan apakah copy-on-write bekerja, seberapa cepat container menyala, dan berapa banyak ruang disk yang terpakai. Terminologinya sering tertukar karena transisi teknologi ini masih berlangsung: instalasi lama bertahan pada driver lawas, instalasi baru Engine 29 memakai snapshotter, dan keduanya muncul di tempat yang sama pada output docker info. Chapter ini memisahkan kedua keluarga itu dalam dua tabel rujukan.

Enam Storage Driver Lawas #

Storage driver lawas bekerja di dalam daemon dockerd dan bertugas menyusun layer menjadi rootfs. Enam driver berikut pernah atau masih menjadi pilihan di lingkungan produksi — status pada kolom ketiga adalah kedudukannya pada Docker modern:

DriverFilesystemStatus
overlay2ext4 atau xfs lewat OverlayFSDefault pra-containerd; masih dipakai instalasi lama yang di-upgrade
aufs—Dihapus dari Docker modern — warisan era awal
btrfsBtrfsDidukung bila host memakai filesystem Btrfs
zfsZFSDidukung bila host memakai filesystem ZFS
vfssemua filesystemTanpa copy-on-write — setiap layer disalin penuh; lambat, untuk kasus khusus
devicemapper—Deprecated — warisan era lama, jangan dipilih untuk instalasi baru

Enam baris tersebut bisa dibaca sebagai satu riwayat penyempurnaan: aufs dan devicemapper adalah percobaan generasi pertama yang kini pensiun, btrfs dan zfs adalah jalur khusus bagi host dengan filesystem tersebut, vfs adalah jaring pengaman tanpa copy-on-write, dan overlay2 adalah pemenang praktis yang menjadi default pada seluruh instalasi sebelum era containerd. Mekanisme tumpukan layer dan copy-on-write yang mereka kerjakan tidak berubah oleh siapa pun yang mengerjakannya — model yang kita bedah pada Chapter Konsep Image Layer dan Writable Container Layer berlaku sama di atas driver mana pun.

Empat Snapshotter containerd #

Pada instalasi baru Docker Engine 29, penyimpanan image berpindah ke containerd image store, dan pekerjaan menyusun layer diambil alih oleh snapshotter — komponen containerd yang sudah kita temui pada rantai eksekusi di Chapter containerd dan runc. Empat snapshotter berikut adalah yang paling relevan:

SnapshotterCara kerjaStatus
overlayfsMenyusun layer lewat OverlayFS dengan copy-on-writeBawaan Engine 29 pada instalasi baru
nativeMenyalin setiap layer penuh ke direktori terpisahTanpa copy-on-write — untuk pengujian dan kasus khusus
btrfsSubvolume dan snapshot BtrfsUntuk host dengan filesystem Btrfs
zfsDataset dan snapshot ZFSUntuk host dengan filesystem ZFS

Membaca Driver Aktif lewat docker info #

Kedudukan penyimpanan sebuah host terbaca langsung dari output docker info — panel instrumen yang kita bedah pada Chapter docker help dan docker version. Instalasi baru Engine 29 menampilkan potongan berikut:

bash 
$ docker info

Output yang Dihasilkan:

text 
Server:
 Containers: 12
  Running: 5
  ...
 Storage Driver: overlayfs
  driver-type: containerd.io
 Logging Driver: json-file
...

Sedangkan instalasi lama yang masih memakai storage driver lawas menampilkan wajah yang serupa dengan struktur berbeda:

text 
Server:
 Containers: 9
  ...
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
...

Mari kita telaah perbedaan kedua potongan tersebut:

  1. Storage Driver: overlayfs dengan driver-type: containerd.io — tanda containerd image store aktif; snapshotter overlayfs yang menyusun layer, persis konfigurasi bawaan instalasi baru.
  2. Storage Driver: overlay2 dengan Backing Filesystem: extfs — wajah penyimpanan lawas; driver bekerja di dalam daemon dan menyebut filesystem pendukungnya secara langsung.
  3. Keduanya OverlayFS di dalamnya — nama yang berbeda menandakan lapisan yang mengerjakan, bukan mekanisme yang berbeda; model layer, copy-on-write, dan whiteout tetap sama di keduanya.

Writable Layer dan Volume di Balik Driver #

Apa pun driver atau snapshotter yang aktif, satu pembagian kerja tidak pernah berubah: seluruh tulisan proses di dalam container mendarat pada writable layer yang hidup selama container itu hidup dan lenyap bersama docker rm, sedangkan data yang harus bertahan menempatkan diri pada named volume di /var/lib/docker/volumes — direktori yang dikelola daemon di luar layer sama sekali, materi Chapter Volume. Itulah alasan pergantian storage driver tidak pernah memindahkan data volume: volume memang tidak tinggal di wilayah driver.

Akibat praktisnya dua arah. Pertama, menjalankan container di atas snapshotter overlayfs atau driver overlay2 tidak mengubah apa pun bagi aplikasi kita — copy-on-write tetap menyalin berkas sebelum ditulis, docker diff tetap melaporkan perubahan, dan docker history tetap membedah layer. Kedua, ketika hal-hal aneh terjadi pada penyimpanan — image membesar tak wajar, layer bocor, ruang disk habis — alat diagnosisnya tetap sama: docker system df untuk mengukur, docker diff untuk melihat tulisan container, dan docker volume inspect untuk memastikan mountpoint volume, persis alur kerja Chapter Debugging Storage.

Penyimpanan menyangkut tempat data tinggal, tetapi aplikasi membaca perilakunya dari tempat lain: variabel-variabel kecil yang disuntikkan ke environment container. Chapter berikutnya, Environment Variable, menghimpun variabel image resmi, Docker CLI, dan Compose ke dalam tiga tabel rujukan.

Referensi #