Pengantar Container Registry

Section Keamanan Docker ditutup dengan mengunci pintu terakhir: akses ke socket daemon diaudit, image dipindai sebelum berlayar, dan seluruh kebiasaan aman sudah menjadi rutinitas. Namun image yang diamankan tetap terkurung di laptop Budi selama tidak ada jalur untuk memindahkannya — ke laptop Siti yang baru ditugaskan membantu proyek, ke server produksi, dan kelak ke mesin CI. Jalur itu bernama container registry: server yang menyimpan image dan menyerahkannya kepada siapa pun yang meminta. Section Registry dan Distribusi kita mulai dari fondasinya: apa sebenarnya yang disimpan sebuah registry, bagaimana protokol pull bekerja di balik layar, dan siapa saja para pemain di ekosistemnya.

Registry: Server yang Paham Struktur Image #

Registry adalah server — atau layanan terkelola — yang menerima dua operasi utama: push mengunggah image dari mesin kita ke registry, dan pull mengunduh image dari registry ke mesin kita. Sejak chapter pertama Course ini kita diam-diam menjadi pelanggannya: setiap docker pull nginx yang tidak menyebut hostname diarahkan ke docker.io, yaitu Docker Hub, registry bawaan Docker.

Yang membedakan registry dari file server biasa adalah pemahamannya atas struktur image. Registry tidak pernah menyimpan image sebagai satu berkas besar; registry menyimpannya terpotong menjadi manifest — dokumen metadata berisi daftar layer — dan blob — unit penyimpanan biner untuk setiap layer. Saat kita menarik image, registry menyusun kembali potongan-potongan itu sesuai urutan pada manifest. Struktur terpotong inilah sumber dua keunggulan sekaligus: efisiensi jaringan, karena dua image yang berbagi layer tidak mengunduh data yang sama dua kali, dan integritas, karena setiap blob terverifikasi lewat digest-nya.

Anatomi Nama Image #

Setiap image diidentifikasi dengan nama yang bisa kita uraikan menjadi empat bagian. Materi anatomi nama sudah kita bahas tuntas lewat tabel dan aturan deteksinya pada Chapter Memahami Image Tag — tabel berikut merekapnya dari sudut pandang registry, tempat setiap bagian menentukan server tujuan dan alamat penyimpanan:

Bagian	Contoh	Peran dari sudut pandang registry
hostname	`docker.io`	server registry tujuan; diisi otomatis Docker Hub bila tidak ditulis
namespace	`library`	wilayah pemilik di dalam registry; `library` khusus official images
repository	`nginx`	nama image di dalam namespace
tag	`latest`	penunjuk versi yang menempel pada repository

Bentuk lengkap docker.io/library/nginx:latest boleh dipendekkan menjadi nginx karena hostname dan namespace library punya nilai bawaan. Image milik akun biasa memakai username sebagai namespace: image katalog milik Budi ditulis lengkap sebagai docker.io/budi/katalog-web:2.0, atau cukup budi/katalog-web:2.0 — nama yang sejak Section Docker dalam Pengembangan sudah sering kita lihat menempel pada hasil docker build -t.

Lima Konsep Inti di Balik Registry #

Lima istilah berikut muncul terus-menerus sepanjang section ini, jadi mari kita tuntaskan sekali di awal:

Konsep	Peran
Repository	kumpulan image bernama sama dalam satu namespace, dibedakan lewat tag
Tag	label yang menunjuk satu manifest; mutable — bisa digeser penerbitnya ke manifest baru
Manifest	dokumen JSON berisi daftar layer, digest masing-masing, dan rujukan konfigurasi image
Blob	unit penyimpanan biner di registry; layer dan berkas konfigurasi sama-sama disimpan sebagai blob
Digest	hash SHA-256 atas isi sebuah objek; identitas content-addressable yang tidak bisa digeser

Alur docker pull di Balik Layar #

Saat kita menjalankan docker pull, daemon tidak mengunduh satu berkas image besar. Alurnya berjalan lima langkah:

Daemon meresolusi nama image menjadi registry, repository, dan tag — melengkapi bagian yang tidak kita tulis dengan nilai bawaannya.
Daemon meminta manifest untuk tag tersebut dari registry lewat endpoint API-nya.
Daemon mencocokkan digest setiap layer pada manifest dengan yang sudah ada di penyimpanan lokal.
Daemon hanya mengunduh blob layer yang belum dimiliki, satu permintaan per layer.
Digest setiap blob yang diunduh diverifikasi terhadap manifest, layer dirakit menjadi image, dan image siap dijalankan.

Alur yang sama tergambar pada diagram berikut:

flowchart TD A["docker pull nginx"] --> B["resolusi nama menjadi docker.io library/nginx:latest"] B --> C["GET manifest dari registry"] C --> D{"layer sudah ada di penyimpanan lokal?"} D -- ya --> E["pakai blob yang sudah ada"] D -- tidak --> F["unduh blob layer dari registry"] E --> G["verifikasi digest lalu rakit image"] F --> G

Mari kita telaah diagram di atas: satu permintaan pull berubah menjadi satu permintaan manifest plus sejumlah permintaan blob; cabang keputusan tengah adalah titik penghematan, karena setiap layer yang sudah dikenal tidak pernah diunduh ulang; dan verifikasi digest di ujung menjadikan setiap byte yang sampai teruji keasliannya.

Output docker pull nginx yang sudah kita bedah baris per baris pada Chapter Menarik Image kini terbaca dengan makna baru:

bash

$ docker pull nginx

Output yang Dihasilkan:

text
Using default tag: latest
latest: Pulling from library/nginx
b97706ca828b: Pull complete
ca0385813dba: Pull complete
d3c681d06bd2: Pull complete
9a3f61c5e2b8: Pull complete
6e08c2f4a1d3: Pull complete
2c7e9b1f5d4a: Pull complete
Digest: sha256:348334896a6815a9c39de3ae8b7c3a37d64efbeac71edc6a2f83ee6e0f77a0d5
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest

Mari kita telaah lima baris kuncinya dari sudut pandang registry:

Using default tag: latest — langkah resolusi nama: kita tidak menulis tag, jadi daemon melengkapinya dengan latest.
latest: Pulling from library/nginx — alamat repository tempat manifest diminta: namespace library, repository nginx, tag latest.
Enam baris Pull complete — satu baris mewakili satu blob layer yang selesai diunduh dan diverifikasi; awalan 12 karakter seperti b97706ca828b adalah potongan digest layer, persis konvensi yang kita kenal dari Chapter Konsep Image Layer.
Digest: sha256:348334896a68... — digest manifest: identitas image yang barusan kita terima; nilai inilah yang bisa kita pakai menarik ulang image yang persis sama lewat referensi digest pada Chapter Image Digest.
docker.io/library/nginx:latest — nama lengkap yang akhirnya tercatat di penyimpanan lokal; bentuk inilah yang dipakai daemon saat berkomunikasi dengan registry.

Bukti Layer Berbagi Lintas Rilis #

Sekarang bukti bahwa struktur terpotong benar-benar menghemat jaringan. Kita melompat sejenak ke ujung section ini — sesaat setelah dua rilis pertama Budi naik ke Docker Hub lewat upacara push pada Chapter Push dan Pull Image — lalu menyaksikan laptop Siti yang masih kosong menarik keduanya berurutan:

bash

$ docker pull budi/katalog-web:2.0

Output yang Dihasilkan:

text
2.0: Pulling from budi/katalog-web
7a3e9c1f5d24: Pull complete
c48e2b6d90af: Pull complete
5f1d8a3c7e29: Pull complete
9b2e6fa8d41c: Pull complete
e6c417f2a89b: Pull complete
Digest: sha256:e3a47392fbb44a7fec80ab4002e269f8c6e71c769411fc9e102d59529137e8c6
Status: Downloaded newer image for budi/katalog-web:2.0
docker.io/budi/katalog-web:2.0

bash

$ docker pull budi/katalog-web:2.1

Output yang Dihasilkan:

text
2.1: Pulling from budi/katalog-web
7a3e9c1f5d24: Already exists
c48e2b6d90af: Already exists
5f1d8a3c7e29: Already exists
9b2e6fa8d41c: Already exists
41d8f9c2e7a1: Pull complete
Digest: sha256:af3d84c454a9da3d229ffa4eaab2507467b615caff4e77ae23a9149d49d7e67f
Status: Downloaded newer image for budi/katalog-web:2.1
docker.io/budi/katalog-web:2.1

Empat layer pertama dijawab Already exists karena rilis 2.1 hanya mengubah kode aplikasi — layer basis node:22-alpine dan layer dependensi identik byte-per-byte dengan milik 2.0, digest sama, sehingga tidak ada satu byte pun diunduh ulang. Hanya layer kode aplikasi (41d8f9c2e7a1) yang benar-benar baru. Hasil akhirnya terlihat rapi di penyimpanan lokal Siti:

bash

$ docker images budi/katalog-web

Output yang Dihasilkan:

text
REPOSITORY           TAG      IMAGE ID       CREATED         SIZE
budi/katalog-web     2.1      c3e91f6a2b7d   6 hours ago     142MB
budi/katalog-web     2.0      4d8b2e7f1a6c   2 days ago      142MB

Mari kita telaah tabel di atas: dua baris memuat dua IMAGE ID yang berbeda — memang dua image yang berbeda — tetapi ukuran keduanya sama 142MB karena layer-layer yang dibagikan hanya tersimpan sekali. Inilah alasan pembaruan harian image berukuran ratusan megabyte hanya memindahkan beberapa megabyte melalui jaringan.

Registry HTTP API V2 dan OCI Distribution Spec #

Komunikasi antara daemon dan registry mengikuti Registry HTTP API V2, yang kini distandarkan sebagai OCI Distribution Specification. Bentuk endpoint-nya mudah dikenali — manifest diambil lewat path /v2/<nama>/manifests/<referensi> dan blob lewat /v2/<nama>/blobs/<digest>:

text

GET /v2/library/nginx/manifests/latest
GET /v2/library/nginx/blobs/sha256:573ce0e79e0c8b1cb9560f3d71e779f2485492afbc9a62d334214ce1d0524a1b

Standarisasi ini berdampak praktis: semua registry modern berbicara bahasa yang sama. Ketika kelak kita menarik image dari ghcr.io atau mendorong image ke registry privat perusahaan, protokol yang bekerja tetap protokol yang sama dengan docker.io. Spesifikasi ini juga menegaskan sifat content-addressable: digest sha256 dihitung langsung dari isi blob dan manifest, sehingga identitas objek ditentukan oleh isinya, bukan oleh nama yang diberikan manusia.

Registry Publik dan Privat #

Registry terbagi dua watak besar. Registry publik seperti Docker Hub mengizinkan siapa pun menarik image tanpa login — cocok untuk base image, tool open source, dan image resmi. Registry privat menuntut autentikasi sebelum pull maupun push; perusahaan memakainya dengan alasan yang jelas: kode proprietary tidak boleh terbaca publik, regulasi menuntut rantai distribusi terkendali, dan tim tidak ingin berbagi kuota pull publik.

Pilihan publik atau privat biasanya berlaku per repository, bukan per registry: satu akun Docker Hub boleh memiliki puluhan repository publik di samping satu-dua repository privat untuk image yang belum layak dirilis. Kita akan menyaksikan keduanya — mulai dari repository publik milik Budi sampai registry privat yang dijalankan sendiri — sepanjang section ini.

Peta Ekosistem Registry #

Terakhir, mari kita kenali para pemain utamanya beserta kapan masing-masing masuk akal:

Registry	Watak	Kapan dipakai
Docker Hub (`docker.io`)	publik	default Docker; official images; tempat image katalog-web Budi berlayar
GHCR (`ghcr.io`)	publik/privat	tim yang kode dan CI-nya sudah hidup di GitHub
Amazon ECR	privat	stack AWS — terintegrasi IAM, ECS, dan EKS
Google Artifact Registry	privat	stack GCP; penerus Container Registry
Quay	publik/privat	kebutuhan enterprise; tersedia versi self-host
GitLab Container Registry	privat	bawaan setiap instance GitLab
`registry:2` (self-host)	privat	lab, jaringan terisolasi, atau kendali penuh atas distribusi

Empat chapter ke depan kita bekerja paling lama dengan Docker Hub, lalu kembali ke registry:2 ketika membangun private registry sendiri dan mirror-nya. Masing-masing berbicara protokol yang sama — itulah hadiah terbesar dari standarisasi yang kita bahas di atas.

Referensi #

Docker overview — posisi registry pada arsitektur client-server Docker.
Concepts: images and registries — konsep image, layer, dan registry versi dokumentasi resmi.
docker image pull — CLI Reference — perilaku resolusi nama dan unduhan per layer.

Bekal konsep kini cukup: registry menyimpan manifest dan blob, pull bekerja per layer, dan seluruh ekosistem berbicara satu protokol. Registry pertama yang pantas dikunjungi adalah yang paling besar dan menjadi alamat bawaan Docker sejak perintah pull pertama kita — Docker Hub — tempat kita akan berkenalan dengan official images, penanda kepercayaan, dan satu angka rate limit yang wajib dihafal setiap tim produksi.