Docker Hub

Setiap kali kita menjalankan docker pull nginx atau docker pull postgres, image tersebut sebenarnya ditarik dari Docker Hub, registry publik bawaan Docker yang jadi tempat penyimpanan dan distribusi image secara default. Docker Hub bukan cuma tempat menarik image orang lain; begitu kita mulai membangun image sendiri lewat docker build, langkah wajar berikutnya adalah menyimpan image itu di suatu tempat supaya bisa dipakai ulang di server lain, dibagikan ke rekan satu tim, atau ditarik otomatis oleh pipeline CI/CD. Bab ini membahas cara mendaftar dan login ke Docker Hub, mekanisme push dan pull image, perbedaan repository publik dan privat, sampai strategi pemberian versi pada image supaya deployment tetap bisa dilacak dan diulang dengan aman.

19.1 Pendaftaran dan Login

Docker Hub butuh akun sebelum kita bisa menyimpan image sendiri di sana, meskipun menarik image publik seperti nginx atau alpine tetap bisa dilakukan tanpa login. Bagian ini membahas cara membuat akun sekaligus login dari Docker CLI dengan aman.

19.1.1 Membuat Akun Docker Hub

Buka hub.docker.com lewat browser, lalu daftar menggunakan email atau akun GitHub/Google yang sudah ada. Docker Hub akan meminta kita memilih Docker ID, yaitu username unik yang nantinya jadi namespace untuk seluruh repository image milik kita. Docker ID ini penting diperhatikan sejak awal karena akan selalu muncul di depan nama repository, misalnya namaakun/nama-image, dan tidak bisa diganti sembarangan setelah banyak image dan integrasi bergantung padanya.

Akun baru otomatis masuk paket Docker Personal yang gratis. Paket ini sudah cukup untuk kebutuhan belajar dan project kecil, meski ada batasan jumlah repository privat dan rate limit pull dibanding paket berbayar seperti Docker Pro atau Team.

19.1.2 Login dari Docker CLI

Setelah akun siap, login dari terminal memakai perintah docker login supaya Docker CLI di komputer kita punya kredensial untuk push maupun pull dari repository privat.

docker login

Perintah ini meminta username dan password, atau membuka browser untuk proses autentikasi kalau dijalankan dari Docker Desktop versi terbaru. Setelah berhasil, Docker CLI menyimpan token autentikasi di file konfigurasi lokal (umumnya ~/.docker/config.json di Linux dan macOS, atau lokasi setara di Windows), sehingga perintah docker push dan docker pull berikutnya ke Docker Hub tidak perlu login ulang selama sesi tersebut masih valid.

Untuk keluar dari sesi login, misalnya di komputer bersama atau server yang dipakai banyak orang, jalankan docker logout supaya kredensial yang tersimpan lokal ikut dihapus.

docker logout

19.1.3 Autentikasi dengan Access Token

Menurut dokumentasi resmi Docker, access token adalah cara autentikasi ke Docker Hub tanpa memakai password akun secara langsung, dan wajib dipakai kalau akun sudah mengaktifkan two-factor authentication (2FA) atau single sign-on (SSO) karena login CLI dengan password biasa tidak didukung lagi untuk kedua kondisi tersebut. Di lapangan, access token juga jadi pilihan lebih aman untuk skenario otomatis seperti CI/CD, karena token bisa dibuat khusus untuk satu keperluan, diberi scope terbatas (misalnya hanya read atau read & write), dan dicabut kapan saja tanpa perlu mengganti password akun utama.

Buat access token dari halaman Account Settings > Personal access tokens di Docker Hub, beri nama yang jelas sesuai peruntukannya (misalnya ci-pipeline-app), lalu salin tokennya karena hanya ditampilkan sekali. Gunakan token itu sebagai pengganti password saat login.

docker login --username namaakun

Saat diminta password, tempelkan access token yang sudah dibuat, bukan password akun Docker Hub. Simpan token di password manager atau secrets manager platform CI/CD yang dipakai, dan jangan pernah menuliskannya langsung di dalam Dockerfile, source code, atau file yang ikut ter-commit ke repository Git, karena siapa pun yang mengakses history repository tersebut bisa memakai token itu untuk push maupun pull image atas nama akun kita.

19.2 Push Image

Setelah image berhasil dibangun secara lokal, langkah berikutnya adalah mengirimnya ke Docker Hub lewat docker push supaya bisa ditarik dari mesin lain. Sebelum push bisa berjalan, image tersebut harus diberi nama sesuai konvensi yang dikenali Docker Hub.

19.2.1 Konvensi Penamaan Repository

Nama lengkap sebuah image mengikuti format [HOST[:PORT]/]PATH[:TAG]. Kalau bagian HOST tidak disebutkan, Docker CLI menganggap image itu berasal dari docker.io, alias Docker Hub. Untuk Docker Hub sendiri, bagian PATH berbentuk NAMESPACE/REPOSITORY, di mana NAMESPACE adalah Docker ID akun atau nama organisasi, dan REPOSITORY adalah nama image yang kita tentukan sendiri.

Karena itu, image yang dibangun secara lokal dengan nama bebas seperti my-app perlu di-tag ulang memakai docker tag agar namanya mengandung namespace akun Docker Hub kita, sebelum bisa di-push.

docker tag my-app namaakun/my-app:1.0

Perintah di atas tidak menyalin ulang seluruh isi image; docker tag hanya menambahkan referensi nama baru yang menunjuk ke image ID yang sama, sehingga prosesnya berjalan hampir instan berapa pun ukuran image-nya. Kalau bagian TAG tidak disebutkan sama sekali, Docker otomatis memakai latest sebagai tag default, sebuah kebiasaan yang perlu diwaspadai karena latest tidak menjamin isinya benar-benar versi terbaru.

19.2.2 Menjalankan Push

Setelah image punya nama yang mengandung namespace kita, jalankan docker push dengan menyebutkan nama lengkap beserta tag-nya.

docker push namaakun/my-app:1.0

Docker mengunggah image tersebut layer demi layer. Layer yang sudah pernah ada di Docker Hub, misalnya karena berasal dari base image publik yang sama seperti node:20-alpine, otomatis dilewati (skipped) dan tidak diunggah ulang, sehingga proses push image berikutnya yang memakai base image serupa biasanya jauh lebih cepat dibanding push pertama kali.

Kalau proses push gagal dengan pesan denied: requested access to the resource is denied, penyebab paling umum di lapangan ada dua: kita belum login lewat docker login, atau namespace pada nama image tidak cocok dengan akun yang sedang login. Jalankan docker login ulang dan pastikan nama image benar-benar diawali Docker ID akun yang dipakai login, bukan nama bebas seperti my-app saja.

Kalau nama repository yang dituju belum pernah ada, Docker Hub otomatis membuatkan repository baru begitu push pertama berhasil, dengan visibility mengikuti pengaturan default repository privacy milik namespace tersebut, yang bisa diatur ke public atau private lewat halaman Settings > Default privacy di dashboard Docker Hub. Developer yang ingin memastikan visibility repository tertentu sejak awal, tanpa bergantung pada pengaturan default namespace, sebaiknya membuat repository secara manual dari dashboard Docker Hub dan menentukan visibility-nya sebelum menjalankan push pertama. Visibility repository yang sudah terbentuk tetap bisa diubah kapan saja lewat pengaturan repository tersebut, baik dari public ke private maupun sebaliknya.

19.3 Pull Image

Menarik image dari Docker Hub adalah operasi yang paling sering dilakukan sehari-hari, baik untuk base image di dalam Dockerfile maupun menjalankan container langsung dari image yang sudah jadi.

19.3.1 Menarik Image dari Repository

Gunakan docker pull diikuti nama image beserta tag yang diinginkan.

docker pull namaakun/my-app:1.0

Untuk image resmi seperti nginx atau postgres yang tidak punya namespace pengguna, Docker Hub sebenarnya menyimpannya di namespace khusus bernama library. Jadi docker pull nginx setara dengan docker pull library/nginx, hanya saja Docker CLI mengizinkan penulisan tanpa namespace untuk image resmi semacam ini supaya lebih ringkas.

Kalau repository yang ditarik bersifat privat, pastikan sudah login lewat akun yang punya akses ke repository tersebut sebelum menjalankan docker pull, karena tanpa autentikasi yang sesuai Docker Hub akan menolak permintaan dengan pesan error akses ditolak, sama seperti kasus push ke repository yang bukan milik kita.

19.3.2 Rate Limit Pull Image

Docker Hub menerapkan batas jumlah pull dalam periode enam jam, dihitung berdasarkan jenis akun. Menurut dokumentasi resmi Docker mengenai usage and limits, pengguna yang tidak login (unauthenticated) dibatasi 100 pull per 6 jam per alamat IPv4 atau per subnet IPv6 /64, sementara akun Docker Personal yang sudah login dibatasi 200 pull per 6 jam. Akun berbayar seperti Docker Pro, Team, dan Business tidak memiliki batas pull sama sekali.

Batas ini sering jadi jebakan di lapangan bagi Sysadmin/DevOps Engineer yang menjalankan banyak build di CI/CD dengan IP address yang sama, misalnya shared runner yang dipakai bergantian oleh banyak project. Karena rate limit dihitung per IP untuk pengguna tanpa login, seluruh job di IP tersebut ikut terpengaruh begitu limit tercapai, bukan cuma job yang kebetulan menyentuh limit duluan. Kalau pull dari Docker Hub gagal dengan pesan you have reached your pull rate limit dan kode status 429, solusi paling langsung adalah login lewat docker login di proses CI/CD tersebut supaya limit dihitung per akun, bukan per IP, atau upgrade ke paket berbayar kalau volume pull memang sudah tinggi secara rutin.

19.4 Public dan Private Repository

Docker Hub membedakan visibility repository menjadi dua: public dan private, yang menentukan siapa saja yang bisa menemukan dan menarik image dari repository tersebut.

19.4.1 Mengatur Visibility Repository

Repository dengan visibility public muncul di hasil pencarian Docker Hub dan bisa ditarik siapa saja tanpa perlu login maupun izin khusus. Pola ini cocok untuk image open source atau tool internal yang memang ditujukan untuk dipakai publik. Sebaliknya, repository private tidak muncul di pencarian dan hanya bisa diakses oleh akun yang sudah diberi izin, cocok untuk image aplikasi internal perusahaan yang mengandung source code proprietary atau konfigurasi sensitif.

Ubah visibility lewat halaman pengaturan repository di dashboard Docker Hub, pada bagian Settings > Visibility. Perlu diperhatikan bahwa mengubah repository dari private menjadi public bersifat langsung berlaku begitu disimpan; kalau image di repository tersebut sempat menyimpan data sensitif di salah satu layer-nya (misalnya API key yang ter-commit tidak sengaja saat proses build), data itu langsung bisa diakses siapa pun sejak repository berubah jadi public, sekalipun layer tersebut sudah tidak dipakai di tag terbaru. Hapus dan bangun ulang image dari awal tanpa data sensitif tersebut sebelum mengubah visibility, alih-alih hanya mengandalkan penghapusan tag.

19.4.2 Kolaborator dan Batasan Repository Private

Untuk repository personal (bukan milik organisasi), akses push dan pull ke repository private diatur lewat fitur collaborators, yaitu akun lain yang diundang secara eksplisit lewat dashboard Docker Hub. Repository organisasi punya kontrol akses yang lebih granular lewat kombinasi roles, teams, dan organization access token, sehingga cocok dipakai tim yang butuh mengatur siapa boleh push, siapa cuma boleh pull, tanpa perlu membagikan kredensial akun utama ke semua anggota.

Paket Docker Personal gratis membatasi jumlah repository private hanya sampai satu repository saja, sementara jumlah repository public tidak dibatasi. Batasan ini penting diperhitungkan Developer yang berencana menyimpan banyak image internal di Docker Hub; kalau kebutuhan repository private lebih dari satu, opsi yang bisa dipertimbangkan adalah upgrade ke paket Docker Pro/Team yang menyediakan repository private tanpa batas, atau menyiapkan private registry sendiri untuk menyimpan image-image tersebut secara mandiri.

19.5 Strategi Versioning Image

Pemberian tag pada image bukan cuma soal penamaan, tapi juga strategi supaya setiap versi aplikasi yang pernah di-deploy tetap bisa dilacak dan ditarik ulang persis sama kapan pun dibutuhkan, misalnya saat harus rollback ke versi sebelumnya di production.

19.5.1 Semantic Versioning pada Tag

Pola paling umum dipakai adalah mengikuti semantic versioning (MAJOR.MINOR.PATCH), dengan setiap build image yang dianggap layak rilis diberi tag versi eksplisit alih-alih dibiarkan hanya bertag latest.

docker tag my-app namaakun/my-app:1.2.0
docker push namaakun/my-app:1.2.0

Selain tag versi lengkap, banyak image resmi di Docker Hub juga menyediakan tag major/minor seperti alpine:3.21 yang otomatis mengarah ke patch version terbaru dari seri 3.21 setiap kali image dibangun ulang oleh maintainer-nya. Pola ini memberi keseimbangan antara stabilitas (tetap di seri 3.21) dan tetap mendapat update patch keamanan terbaru tanpa perlu mengubah referensi tag secara manual. Developer yang membangun image sendiri bisa meniru pola serupa dengan mendorong beberapa tag sekaligus ke commit yang sama.

docker tag my-app namaakun/my-app:1.2.0
docker tag my-app namaakun/my-app:1.2
docker tag my-app namaakun/my-app:1

docker push namaakun/my-app:1.2.0
docker push namaakun/my-app:1.2
docker push namaakun/my-app:1

Di lapangan, Sysadmin/DevOps Engineer yang mengelola pipeline CI/CD biasanya menambahkan pula tag berbasis commit hash Git atau nomor build (misalnya namaakun/my-app:git-a1b2c3d) di samping tag semantic version, supaya setiap image yang pernah dibangun tetap bisa ditelusuri langsung ke commit sumbernya, terutama berguna saat proses debugging insiden production yang perlu memastikan versi kode persis mana yang sedang berjalan.

19.5.2 Menghindari Jebakan Tag latest

Tag latest bukan penanda "versi paling baru" secara otomatis; tag ini cuma tag default yang dipakai Docker kalau kita tidak menyebutkan tag lain saat push maupun pull. Konsekuensinya, latest menunjuk ke image apa pun yang terakhir kali di-push dengan tag tersebut, yang bisa jadi versi lama kalau urutan push tidak konsisten, atau bahkan versi yang belum stabil kalau tidak sengaja ter-push dari branch development.

Menggunakan latest di file deployment production, misalnya di dalam compose.yaml atau manifest orchestration lain, berisiko membuat deployment tidak bisa diulang (not reproducible): menjalankan docker pull namaakun/my-app:latest hari ini dan minggu depan bisa saja menghasilkan image yang berbeda tanpa ada perubahan konfigurasi apa pun di sisi kita. Kondisi ini menyulitkan proses rollback, karena tidak ada cara memastikan versi mana yang sebelumnya benar-benar berjalan stabil di production.

Praktik yang lebih aman adalah selalu menyebutkan tag versi eksplisit di environment production, dan menyimpan latest hanya sebagai tag tambahan untuk kemudahan development atau eksperimen cepat.

services:
  app:
    image: namaakun/my-app:1.2.0

Tag eksplisit seperti di atas membuat rollback ke versi sebelumnya cukup dilakukan dengan mengganti angka versi di file konfigurasi dan menjalankan ulang deployment, tanpa perlu menebak-nebak image mana yang sebenarnya sedang berjalan.