Rate limit pada Chapter Docker Hub mengajarkan satu hal penting: Docker ID bukan formalitas, melainkan pintu ke kuota pull terautentikasi dan ke kemampuan menyimpan image sendiri. Budi kini memakai akunnya untuk menyiapkan wadah tersebut: sebuah repository bernama katalog-web yang kelak menampung hasil docker push dari laptopnya — dan, kelak lagi, dari pipeline CI. Chapter ini membedah langkah pembuatannya di antarmuka web, aturan penamaan image yang menyertainya, keputusan visibilitas publik atau privat, serta cara mengatur akses ketika repository berpindah dari akun pribadi ke organization.

Membuat Repository Baru #

Proses pembuatannya berlangsung di antarmuka web dan hanya butuh beberapa menit:

  1. Login ke hub.docker.com dengan Docker ID, lalu klik tombol Create repository.
  2. Pilih namespace — secara bawaan namespace adalah username (budi); bila akun menjadi anggota organization, namespace organization dapat dipilih dari daftar yang sama.
  3. Isi repository name dengan katalog-web. Nama hanya boleh huruf kecil, angka, serta karakter ., -, dan _.
  4. Tuliskan deskripsi singkat — opsional, tetapi sangat membantu pencarian dan calon pengguna.
  5. Pilih visibilitas: Public atau Private.
  6. Klik Create — repository kosong akan tampil beserta petunjuk docker push budi/katalog-web:tagname.

Repository yang baru lahir masih kosong: tab Tags belum memuat apa pun dan baru terisi setelah push pertama pada Chapter Push dan Pull Image. Meski kosong, keberadaannya sudah mengklaim alamat tersebut — tidak ada orang lain yang bisa membuat budi/katalog-web selama akun Budi memilikinya, dan tidak ada pula tag yang bisa muncul di sana tanpa kredensial Budi.

Struktur Nama Image di Repository Baru #

Repository yang barusan kita buat menjadi rumah bagi image katalog. Bentuk lengkap namanya kini utuh, dan anatomi ini adalah rekap dari Chapter Memahami Image Tag yang kini terbaca sebagai alamat sungguhan:

BagianContohKeterangan
hostnamedocker.ioregistry Docker Hub; boleh tidak ditulis karena merupakan bawaan
namespacebudiusername atau organization pemilik repository
repositorykatalog-webnama yang barusan kita buat
tag2.0dipilih saat push; jika tidak ditulis, dianggap latest
text
docker.io/budi/katalog-web:2.0

Bentuk singkat budi/katalog-web:2.0 dan bentuk lengkap di atas menunjuk image yang sama. Perjanjian penamaan ini juga menjelaskan kenapa nama image publik seperti nginx bisa sesingkat itu: hostname bawaan dan namespace library dihilangkan secara otomatis oleh Docker.

Publik atau Privat #

Keputusan visibilitas sebaiknya diambil dengan sadar, bukan dibiarkan sebagai default:

VisibilitasSiapa dapat pullBatas pada Docker Hub
Publicsiapa saja tanpa loginjumlah repository publik tidak dibatasi
Privatehanya akun yang diberi aksesplan Personal: 1 repo privat; Pro, Team, Business: tanpa batas

Image internal perusahaan — aplikasi dengan kode proprietary — jelas milik repository privat. Sebaliknya, base image rakitan ulang tim infrastruktur justru paling berguna bila dipublikasikan agar CI dan developer mana pun dapat menariknya tanpa koordinasi. Untuk latihan Course ini, repository katalog-web kita biarkan publik supaya pull dari laptop Siti tidak memerlukan langkah pembagian akses.

Perlu dicatat bahwa batas satu repository privat pada plan Personal cepat terasa ketika tim berkembang. Migrasi yang lazim adalah pindah kepemilikan repository ke organization dengan plan Team — sekalian membuka fitur pengaturan akses berbasis tim yang kita bahas berikutnya.

Organization, Team, dan Permission #

Organization adalah namespace kolektif: anggotanya adalah akun-akun Docker ID, penagihan terpusat, dan kepemilikan repository tidak terikat pada satu orang — pemilik akun yang resign tidak ikut membawa pulang repository perusahaan. Di dalam organization, anggota dikelompokkan dalam team — misalnya backend dan frontend — lalu setiap repository memberikan permission per team:

PermissionKemampuan pada repository
Readmenarik (pull) image
Writemendorong (push) tag baru
Adminmengatur permission anggota serta pengaturan repository

Pemetaan sederhana untuk produk katalog kita: team backend mendapat Write pada katalog-web karena tim itulah yang membangun imagenya, sementara team frontend cukup Read karena hanya menjalankan image di environment development. Struktur ini menggantikan kebiasaan berbagi satu akun bersama — kebiasaan yang sulit diaudit dan tidak bisa dicabut per orang saat terjadi rotasi tim.

Tab Tags sebagai Jejak Audit #

Setelah push pertama, tab Tags menjadi bagian tersibuk halaman repository. Setiap barisnya menampilkan nama tag, kapan tag terakhir di-push, digest manifest yang ditunjuk, ukuran terkompresi, dan arsitektur yang tersedia. Daftar tersebut berfungsi sebagai jejak audit ringan: ketika perilaku aplikasi berubah tanpa perubahan kode, membandingkan waktu push tag dengan waktu kemunculan gejala sering langsung menunjukkan tersangka. Kualitas jejak itu, kelak kita lihat pada Chapter Strategi Versioning Image, sangat bergantung pada disiplin penamaan tag.

Untuk budi/katalog-web, isi README yang layak dikerjakan setidaknya mencakup empat hal:

  • tautan ke repository sumber beserta Dockerfile yang membangun image;
  • contoh docker run atau potongan compose.yaml siap pakai, termasuk environment variable yang dikenali image seperti DATABASE_URL;
  • kebijakan tag: versi mana yang dianggap stabil, bagaimana pola tag rilis, dan apa makna tag latest;
  • catatan pemeliharaan: siapa yang mengurus image dan seberapa sering diperbarui.

Referensi #

Repository sudah menunggu di sisi Docker Hub, tetapi daemon di laptop Budi belum memperkenalkan diri kepada siapa pun. Sebelum bisa mendorong image, CLI harus diautentikasi ke registry — dan autentikasi tersebut menyimpan detail penting mengenai personal access token dan lokasi penyimpanan kredensial yang tidak boleh dilewatkan. Chapter berikutnya membahas docker login beserta seluruh perilakunya.