Server uji Siti pada akhir chapter sebelumnya dipenuhi puluhan image sekaligus — dan itu baru dari satu repositori. Semakin jauh kita menjelajah Course ini, semakin besar pula tumpukan image di penyimpanan lokal: image latihan, image proyek, sampai image lama yang bahkan sudah terlupakan. Docker menyediakan docker images sebagai jendela ke penyimpanan lokal tersebut: siapa saja yang tinggal di dalamnya, seberapa besar masing-masing, dan sejak kapan dibangun. Chapter ini mengajarkan cara membaca tabelnya, menyaring dan memformat hasilnya untuk kebutuhan sehari-hari, sekaligus membedah dua kolom yang paling sering menipu pembacanya — IMAGE ID dan SIZE.

Membaca docker images #

Perintah docker images menampilkan seluruh image yang tersimpan pada penyimpanan lokal milik daemon. Tanpa argumen, hasilnya berupa tabel berisi lima kolom. Sebagai contoh, berikut tampilan pada sebuah mesin latihan yang hanya menyimpan tiga image populer:

bash 
$ docker images

Output yang Dihasilkan:

text 
REPOSITORY    TAG      IMAGE ID       CREATED       SIZE
nginx         latest   613f27b0341a   3 days ago    187MB
alpine        3.20     2676beef0bef   2 weeks ago   7.8MB
hello-world   latest   e6590340b2f4   2 years ago   13.3kB

Mari kita telaah kelima kolomnya:

  1. REPOSITORY — nama repositori image; prefiks registry dan namespace disingkat: baris nginx sebenarnya merujuk docker.io/library/nginx.
  2. TAG — penunjuk versi yang menempel pada repositori; latest di sini hanyalah tag bawaan, bukan janji versi termutakhir — kita bedah tuntas pada Chapter Memahami Image Tag.
  3. IMAGE ID — 12 karakter pertama dari ID image 64 karakter; perannya sebagai identitas lokal image, dan cara membacanya kita bedah di bagian bawah.
  4. CREATED — waktu image dibangun oleh penerbitnya, bukan waktu kita menariknya: hello-world berumur dua tahun karena memang tidak pernah diperbarui di sisi Docker Hub, sementara nginx dibangun ulang tiga hari lalu.
  5. SIZE — total ukuran seluruh layer image dalam kondisi terpasang (tidak terkompresi); cara membacanya juga menyimpan jebakan yang kita bedah di bagian bawah.

docker image ls — Padanan Modern #

docker images adalah bentuk alias dari perintah modern docker image ls — anggota keluarga management command docker image, sejajar dengan docker image pull dan docker image inspect yang akan kita temui terus sepanjang Course. Keduanya menghasilkan tabel yang persis identik. Bentuk docker image ls lebih konsisten dipakai pada dokumentasi dan skrip modern karena strukturnya paralel dengan subperintah lain:

bash 
$ docker image ls

Output yang Dihasilkan:

text 
REPOSITORY    TAG      IMAGE ID       CREATED       SIZE
nginx         latest   613f27b0341a   3 days ago    187MB
alpine        3.20     2676beef0bef   2 weeks ago   7.8MB
hello-world   latest   e6590340b2f4   2 years ago   13.3kB

Menyaring Daftar dengan –filter #

Pada mesin yang sibuk, daftar image bisa memanjang puluhan baris. Flag --filter memangkas daftar sesuai kriteria; dua kriteria yang paling sering dipakai adalah image yang kehilangan nama (dangling) dan image yang cocok dengan pola nama tertentu.

Menemukan Image Dangling #

Image dangling lahir dari skenario yang sangat umum: membangun ulang image dengan tag yang sama. Katakanlah Budi membangun image aplikasinya dengan tag myapp:dev, lalu lima hari kemudian membangun ulang setelah memperbaiki kode — materi Section Dockerfile. Build baru mengambil alih tag myapp:dev; image lama kehilangan seluruh nama yang bisa dirujuk, tetapi berkas-berkasnya tetap utuh dan tetap memakan ruang disk. Docker menampilkan image semacam itu dengan nama dan tag <none>:

bash 
$ docker images --filter dangling=true

Output yang Dihasilkan:

text 
REPOSITORY   TAG      IMAGE ID       CREATED      SIZE
<none>       <none>   105c9de1d398   5 days ago   212MB

Mari kita telaah baris tunggal di atas:

  1. REPOSITORY dan TAG <none> — image ini sudah tidak memiliki nama; satu-satunya cara merujuknya adalah lewat IMAGE ID.
  2. IMAGE ID 105c9de1d398 — ID image lama milik Budi sebelum dibangun ulang; isinya masih bisa dipulihkan dengan menempelkan tag baru lewat docker image tag.
  3. CREATED dan SIZE — lima hari telah berlalu sejak image lama itu dibangun, dan 212MB ruang disk masih dikuasainya tanpa memberi manfaat apa pun.

Image dangling adalah kandidat utama pembersihan: tanpa nama, image seperti ini tidak akan pernah dipakai lagi kecuali dipulihkan dengan sengaja. Cara menghapusnya — baik satu per satu maupun massal dengan docker image prune — kita bahas pada Chapter Menghapus Image dan Membersihkan Resource Image.

Menyaring Berdasarkan Nama dengan reference #

Filter kedua memilih image berdasarkan pola namanya melalui reference. Nilainya berupa pola glob yang dicocokkan ke kombinasi repositori dan tag. Pola nginx* mencocokkan seluruh image yang repositorinya diawali kata nginx:

bash 
$ docker images --filter reference='nginx*'

Output yang Dihasilkan:

text 
REPOSITORY   TAG      IMAGE ID       CREATED      SIZE
nginx        latest   613f27b0341a   3 days ago   187MB

Dari tiga image pada mesin contoh, hanya nginx yang lolos — alpine dan hello-world tersaring keluar karena namanya tidak cocok dengan pola. Pola yang lebih spesifik juga sah: 'nginx:1.29*' menampilkan seluruh tag rilis 1.29, dan pola bisa digabung dengan pemfilteran dangling untuk berburu sisa build lama milik proyek tertentu.

Mengubah Bentuk Keluaran dengan –format #

Untuk dibaca manusia, tabel bawaan sudah pas; untuk skrip, bentuk keluarannya perlu kita kendalikan sendiri. Flag --format menerima template dengan field yang sudah disediakan — {{.Repository}}, {{.Tag}}, {{.ID}}, {{.CreatedSince}}, dan {{.Size}} — lalu menyusunnya sesuka kita. Berikut tiga bentuk yang paling sering dipakai:

bash 
$ docker images --format '{{.Repository}}:{{.Tag}}'

Output yang Dihasilkan:

text 
nginx:latest
alpine:3.20
hello-world:latest
bash 
$ docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'

Output yang Dihasilkan:

text 
REPOSITORY    TAG      SIZE
nginx         latest   187MB
alpine        3.20     7.8MB
hello-world   latest   13.3kB
bash 
$ docker images --quiet

Output yang Dihasilkan:

text 
613f27b0341a
2676beef0bef
e6590340b2f4

Mari kita telaah ketiga bentuk di atas:

  1. Format {{.Repository}}:{{.Tag}} — menghasilkan satu referensi image per baris; bentuk ini paling nyaman untuk di-loop di skrip shell atau ditempel ke perintah lain satu per satu.
  2. Kata table dan \t — prefiks table menambahkan baris judul kolom, sementara \t memisahkan kolom dengan karakter tab; hasilnya tabel rapi yang hanya memuat kolom pilihan kita.
  3. --quiet (alias -q) — hanya mencetak IMAGE ID, satu per baris; pola klasik pemakaiannya adalah menggabungkannya ke perintah lain, misalnya docker rmi $(docker images -q) untuk menghapus banyak image sekaligus — pola destruktif yang kita bahas dengan aman pada Chapter Menghapus Image.

Membaca IMAGE ID dan SIZE dengan Hati-hati #

IMAGE ID sering disalahpahami sebagai hash dari isi image. Sebenarnya, ID tersebut adalah hash dari berkas konfigurasi image — metadata yang menyusun daftar layer beserta environment variable, perintah bawaan, dan deklarasi volume. Dua image yang mengandung layer sama tetap memiliki ID berbeda bila konfigurasinya berbeda; sebaliknya, dua tag yang menunjuk image yang sama justru berbagi satu ID — buktinya akan kita lihat langsung pada Chapter Memahami Image Tag. Karena ID dihitung dari konfigurasi, ia tidak bisa dipakai menilai besar maupun isi image; untuk itu tersedia SIZE.

SIZE adalah penjumlahan ukuran seluruh layer dalam kondisi terpasang — namun dengan satu kekeliruan sistematis: layer yang dibagikan dihitung ulang pada setiap image yang memuatnya. Sebuah mesin yang menyimpan nginx:latest (187MB) dan nginx:1.29-perl (misalnya 246MB) menampilkan total 433MB pada dua barisnya, padahal layer-layer Debian di bagian bawah hanya tersimpan sekali sehingga pemakaian disk aktual lebih kecil dari angka itu. Semakin banyak image saling berbagi layer, semakin lebar pula jurang antara penjumlahan SIZE dan kenyataan disk. Ukuran pemakaian disk yang jujur harus dibaca dari docker system df.

Ringkasan Pemakaian Disk dengan docker system df #

bash 
$ docker system df

Output yang Dihasilkan:

text 
TYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLE
Images          3       1        194.9MB   7.8MB (4%)
Containers      1       1        6.9MB     0B (0%)
Local Volumes   0       0        0B        0B
Build cache     0       0        0B        0B

Mari kita telaah tabel di atas, dengan asumsi satu container nginx sedang berjalan di mesin contoh:

  1. TYPE dan TOTAL — pemakaian dikelompokkan per jenis objek: image, container, volume lokal, dan build cache; mesin contoh menyimpan 3 image.
  2. ACTIVE — jumlah objek yang sedang dipakai: tepat satu image dipakai oleh satu container yang berjalan.
  3. SIZE — total pemakaian disk seluruh image, yakni 194.9MB; angka ini mendekati penjumlahan SIZE ketiga image karena ketiganya memang tidak berbagi layer.
  4. RECLAIMABLE — ruang yang bisa dibersihkan: dua image tak terpakai (alpine dan hello-world) menyumbang 7.8MB atau 4% — persentase dihitung terhadap kolom SIZE.

Kelima kolom docker images kini kita baca dengan kritis: REPOSITORY dan TAG menunjuk identitas, CREATED milik penerbit, IMAGE ID hash konfigurasi, dan SIZE penjumlahan yang bisa menggelembih. Justru karena nama dan tag begitu sentral dalam tabel itulah kita perlu membedahnya sampai tuntas: dari mana asal aturan penamaan docker.io/library/nginx:latest, mengapa satu tag bisa berpindah image, dan apa bedanya tag dari digest. Chapter Memahami Image Tag menjawab semuanya.

Referensi #