Chapter sebelumnya memperkenalkan dua cara mendapatkan Docker di mesin kita: Docker Engine dan Docker Desktop. Sebelum benar-benar memasang salah satunya, ada tiga istilah inti yang harus kita kuasai lebih dulu karena muncul di hampir setiap perintah: image, container, dan registry. Ketiganya membentuk satu siklus hidup yang utuh — image ditarik dari registry, dijalankan sebagai container, lalu container dibuang sementara image tinggal menunggu dipakai lagi. Chapter ini membedah ketiganya satu per satu, lalu menutup dengan demo nginx yang mempraktikkan seluruh siklus tersebut dalam empat perintah.
Image sebagai Tumpukan Layer Read-Only #
Image adalah template read-only untuk membuat container: di dalamnya tersimpan aplikasi, library, runtime, dan berkas konfigurasi yang dibutuhkan aplikasi tersebut. Sebuah image dibangun dari Dockerfile — berkas berisi daftar instruksi build — dan setiap instruksi menghasilkan satu layer. Docker menyimpan layer-layer itu secara terpisah, sehingga dua image yang berbagi fondasi sama cukup menyimpan layer bersamanya sekali: unduhan lebih hemat dan ruang disk lebih irit. Image juga bersifat immutable; setelah dibangun, isi image tidak bisa diutak-atik, dan setiap perubahan menghasilkan image baru dengan tag baru.
Image diidentifikasi lewat nama dan tag, misalnya nginx:alpine. Nama dan tag adalah label yang mudah digeser-geser, sehingga untuk keperluan ketat image juga memiliki ID 64 karakter heksadesimal serta digest sha256: sebagai sidik jari permanennya. Perjalanan lengkap penamaan ini kita bedah pada Section Docker Image, khususnya Chapter Konsep Image Layer dan Memahami Image Tag.
Container sebagai Writable Layer di Atas Image #
Perintah docker run mengambil sebuah image, menumpuk seluruh layer read-only miliknya, lalu menambahkan satu layer tipis yang bisa ditulis — writable layer — di puncak tumpukan. Proses di dalam container membaca dari layer image dan menulis ke writable layer: berkas baru, perubahan berkas, sampai log aplikasi semuanya mendarat di layer teratas tersebut. Bersama proses yang menjalankannya, inilah definisi lengkap sebuah container: image ditambah writable layer ditambah proses.
Konsekuensi desain ini penting untuk dicamkan. Ketika container dihapus, writable layer ikut terhapus tanpa menyentuh image asalnya — image tetap utuh dan siap membuat container baru yang bersih, persis seperti kondisi pertama kali dijalankan. Perilaku ini cocok untuk eksperimen dan beban kerja sekali-jalan, tetapi data yang memang harus bertahan memerlukan mekanisme lain bernama volume dan bind mount; pembahasannya menunggu Section Penyimpanan Data yang dibuka Chapter Writable Container Layer.
Registry sebagai Gudang Distribusi #
Registry adalah layanan yang menyimpan dan mendistribusikan image. Registry default Docker adalah Docker Hub dengan alamat docker.io: setiap kali kita menarik image tanpa menyebut alamat registry, Docker mengarahkannya ke sana. Nama lengkap image nginx sebenarnya adalah docker.io/library/nginx — segmen library/ adalah namespace khusus untuk image resmi yang dipelihara Docker. Selain Docker Hub tersedia pula private registry yang dapat dijalankan sendiri di dalam jaringan perusahaan, topik yang kita bedah pada Section Registry dan Distribusi.
Rate Limit Docker Hub #
Docker Hub memberlakukan batas jumlah tarik image — rate limit — agar layanan publiknya tetap sehat. Pengguna anonim dibatasi 100 pull per 6 jam per alamat IPv4, atau per blok /64 untuk IPv6. Pemilik akun dengan plan Personal yang gratis mendapat 200 pull per 6 jam plus satu repositori privat, sementara plan Pro, Team, dan Business menikmati kuota fair-use tanpa batas keras. Ketika batas terlampaui, tarik image berikutnya ditolak dengan galat toomanyrequests dan kode HTTP 429.
Analogi Class dan Instansi #
Sebagai alat bantu pemahaman, image sering dianalogikan sebagai class dan container sebagai instansi dari class tersebut: docker run berperan sebagai proses instansiasi, dan satu image memang bisa menghasilkan banyak container sekaligus, persis seperti satu class menghasilkan banyak objek. Analogi ini nyaman dipakai untuk memahami hubungan image-container secara cepat. Namun analogi ini punya batas yang perlu kita pegang sejak awal.
Batas pertama: setiap objek dari sebuah class menyimpan salinan state-nya sendiri, sedangkan container-container yang lahir dari satu image yang sama justru berbagi layer read-only yang sama di disk — yang dimiliki masing-masing container hanyalah writable layer tipis di puncak tumpukan. Menjalankan seratus container dari satu image tidak menyalin image itu seratus kali; layer read-only tetap satu dan di-share. Batas kedua: image bersifat immutable sehingga container yang sedang berjalan tidak pernah mengubah image asalnya, sedangkan objek memodifikasi state miliknya sendiri tanpa menyentuh class. Perlakukan analogi class-instansi sebagai jembatan pemahaman, bukan kesetaraan teknis.
Siklus Hidup Image dan Container #
Ketiga istilah bertemu dalam satu siklus yang akan kita ulangi terus sepanjang Course ini. docker pull mengambil layer image dari registry dan menyusunnya menjadi image read-only di penyimpanan lokal; docker run menambahkan writable layer di atas image tersebut dan menghidupkan container; docker rm membuang container beserta writable layer-nya, sementara image tetap berdiri dan siap dipakai lagi. Perintah docker rmi baru menghapus image dari penyimpanan lokal ketika image memang tidak lagi dibutuhkan. Perhatikan bahwa registry berada di luar mesin kita: registry hanya disentuh pada saat pull dan push.
Demo Menjalankan nginx #
Sekarang kita praktikkan seluruh siklus itu dengan image nginx. Tag nginx:alpine adalah varian kecil berbasis Alpine yang pada saat riset Course ini menunjuk varian 1.29-alpine dengan ukuran 47.9MB. Langkah pertama, tarik image tersebut ke penyimpanan lokal:
$ docker pull nginx:alpineOutput yang Dihasilkan:
alpine: Pulling from library/nginx
b97706ca828b: Pull complete
9c0f9a52d13d: Pull complete
6b8d4e7f2a9c: Pull complete
...
Digest: sha256:348334896a6815a9c39de3ae8b7c3a37d64efbeac71edc6a2f83ee6e0f77a0d5
Status: Downloaded newer image for nginx:alpine
docker.io/library/nginx:alpineBaris layer di tengah output dipotong agar ringkas; nginx:alpine tersusun dari beberapa layer. Mari kita telaah baris-baris yang tampil:
alpine: Pulling from library/nginx— Docker menyebut tag yang diminta beserta repositorinya; nginx tanpa prefiks berarti image resmi di namespacelibrary/.- Baris-baris layer — setiap layer diunduh satu per satu; layer yang sudah dimiliki dari image lain akan dilewati karena layer memang di-share antar image.
Digest:— sidik jari kriptografis manifest image dalam bentuksha256:diikuti 64 karakter heksadesimal; digest adalah identitas image yang tidak pernah berubah.Status:dan baris terakhir — image kini tersimpan di lokal dengan nama lengkapdocker.io/library/nginx:alpine, siap dipakai tanpa mengunduh lagi.
Setelah pull selesai, kita periksa daftar image yang tersimpan di lokal. Perintah berikut menampilkan tabel image berserta ukurannya:
$ docker imagesOutput yang Dihasilkan:
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx alpine 613f27b0341a 3 days ago 47.9MB
hello-world latest 6c155a7581b0 2 years ago 13.3kBMari kita telaah tabel di atas:
- REPOSITORY dan TAG — nama dan tag image; kombinasi keduanya adalah cara kita merujuk image pada perintah berikutnya.
- IMAGE ID — 12 karakter pertama dari ID image 64 karakter; bentuk pendek ini yang biasa dipakai sehari-hari.
- CREATED dan SIZE — image nginx diperbarui tiga hari lalu dengan ukuran 47.9MB, sementara hello-world yang kita jalankan pada Chapter Apa itu Docker? masih tersimpan dan hanya berukuran 13.3kB.
Langkah ketiga: jalankan container dari image tersebut di latar belakang dengan nama web. Flag -d membuat container berjalan sebagai daemon dan langsung mengembalikan kontrol terminal kepada kita:
$ docker run -d --name web nginx:alpineOutput yang Dihasilkan:
f7c2a91b3e55913c4a5f1c6c0a4d8e2b3f4a5b6c7d8e9f0a1b2c3d4e5f60718aBaris panjang itu adalah ID container versi penuh: 64 karakter heksadesimal yang unik untuk container ini. Dua belas karakter pertamanya, f7c2a91b3e55, adalah bentuk pendek yang akan tampil pada perintah berikutnya. Terakhir, pastikan container benar-benar hidup dengan melihat daftar container yang sedang berjalan:
$ docker psOutput yang Dihasilkan:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f7c2a91b3e55 nginx:alpine "/docker-entrypoint.…" 20 seconds ago Up 19 seconds 80/tcp webMari kita telaah kolom-kolom output docker ps di atas:
- CONTAINER ID — bentuk pendek ID container, yaitu 12 karakter pertama dari ID panjang yang dicetak saat
docker run. - IMAGE dan COMMAND — container dibuat dari image nginx:alpine dan menjalankan skrip entrypoint nginx; entrypoint inilah yang menjaga proses nginx tetap hidup di depan.
- CREATED dan STATUS — container dibuat 20 detik lalu dan masih menyala, ditandai status Up.
- PORTS — nginx mendengarkan port 80 di dalam jaringan containernya sendiri; teks 80/tcp belum berarti port tersebut dapat diakses dari laptop kita karena kita belum menerbitkannya dengan flag
-p— pembahasan penuhnya menunggu Chapter Port Publishing. - NAMES — nama web berasal dari flag
--name; nama membuat container mudah dirujuk oleh perintah selanjutnya sepertidocker logs web.
Empat perintah tadi menutup satu putaran penuh siklus hidup: pull menyimpan image, run menghidupkan container, dan docker rm web kelak membuang container tanpa menghapus imagenya. Konsep inti Docker kini sudah lengkap di tangan kita — sebelum benar-benar memasang Docker di mesin masing-masing, mari kita lihat bagaimana seluruh konsep tersebut bekerja pada enam skenario nyata. Chapter Use Case Docker menutup Section ini dengan enam contoh pemakaian yang paling sering dijumpai developer.
Referensi #
- Docker Overview — penjelasan resmi relasi image, container, dan registry.
- nginx di Docker Hub — halaman image resmi nginx beserta daftar tag-nya.
- Docker Hub — dokumentasi Docker Hub termasuk batas jumlah tarik image.