Apa Itu Container Registry? Tempat Container Image Disimpan dan Dibawa ke Mana-mana

Bayangkan kamu sudah membangun sebuah container image di laptopmu. Jalannya mulus, sempurna. Sekarang image yang sama persis itu harus berjalan di server produksi yang lokasinya nun jauh di seberang dunia — dan mungkin juga di mesin rekan timmu, lalu di tiga server lagi bulan depan. Pertanyaannya: bagaimana image itu berpindah dari tempat dia dibuat ke semua tempat yang membutuhkannya? Kamu tentu tidak mengirimnya lewat email satu per satu. Kamu push ke sebuah container registry, lalu semua orang pull dari sana.

Registry termasuk bagian infrastruktur yang gampang luput dari perhatian — sampai kamu sadar bahwa hampir semua alur kerja container diam-diam bersandar padanya. Begitu kamu paham apa yang dikerjakan sebuah registry, janji “build sekali, jalan di mana saja” yang dibawa container akhirnya tersambung dari ujung ke ujung. Jadi ayo kita telusuri dari dasar.

Container registry itu sebenarnya apa

Container registry adalah server yang tugasnya menyimpan dan menyebarkan container image. Anggap saja dia gudang buat image: kamu mengunggah satu image ke dalamnya, lalu nanti siapa pun yang punya izin bisa mengunduh image yang sama persis itu, tanpa beda satu byte pun, ke mesin mana saja.

Kalau kamu pernah pakai layanan hosting kode untuk menyimpan source code, gambarannya nyaris identik. Registry bagi container image itu seperti host kode bagi berkas source. Kamu push sebuah image ke atas untuk membagikannya, dan kamu pull sebuah image ke bawah untuk memakainya. Registry-lah yang memegang salinan resmi yang disepakati semua orang.

Kenapa ini penting? Sebuah container image adalah paket aplikasimu yang sudah dibekukan dan siap jalan — kodemu plus berkas sistem operasi, library, dan pengaturan yang persis dia butuhkan. Membangun image itu satu urusan. Membuatnya jalan di tempat lain adalah persoalan terpisah, dan registry-lah jawabannya. Tanpa registry, tiap mesin harus membangun ulang image-nya sendiri, dan kamu kehilangan jaminan bahwa mereka semua menjalankan barang yang sama persis.

Registry vs. repository vs. image — tiga kata yang bertingkat

Ketiganya sering ketuker, jadi mari kita kunci sekarang. Registry adalah keseluruhan layanannya (gudangnya). Di dalamnya, sebuah repository adalah kumpulan bernama yang menampung semua versi dari satu image tertentu — misalnya repository bernama web-app. Di dalam repository itu, tiap versi adalah sebuah image yang ditandai dengan tag, seperti web-app:1.4 atau web-app:latest. Jadi alamat lengkapnya terbaca sebagai registry / repository : tag. Satu registry menampung banyak repository; satu repository menampung banyak image yang punya tag berbeda.

Push dan pull: dua operasi yang paling penting

Hampir semua yang kamu lakukan dengan registry intinya mengerucut jadi dua kata kerja.

Push mengunggah sebuah image dari mesinmu ke registry. Ini kamu lakukan setelah membangun image, ketika kamu ingin image itu tersedia buat mesin lain. Registry menyimpannya dan memberinya alamat yang bisa dijangkau orang lain.

Pull mengunduh sebuah image dari registry ke mesin yang perlu menjalankannya. Server produksi mem-pull image-nya, lalu menyalakan container dari image itu. Rekan timmu mem-pull image yang sama untuk dijalankan di mesinnya sendiri, dan dia dapat lingkungan yang identik.

Ini alur khasnya, dari build sampai jalan di produksi:

   MESIN KAMU                   REGISTRY                  SERVER PRODUKSI
        │                          │                            │
        │  1. build image-nya      │                            │
        │ ─────────┐               │                            │
        │ ◄────────┘               │                            │
        │                          │                            │
        │  2. push image ─────────►│                            │
        │                          │  (menyimpan image-nya)     │
        │                          │                            │
        │                          │◄──── 3. pull image ────────│
        │                          │                            │
        │                          │     4. jalankan container ─│ ─────┐
        │                          │                            │ ◄────┘

Yang indah dari pola ini adalah pemisahan urusannya. Mesin yang membangun image dan mesin yang menjalankannya tidak pernah perlu bicara langsung satu sama lain. Registry duduk di tengah sebagai titik serah-terima yang netral. Justru inilah yang membuat pipeline deployment otomatis jadi mungkin: sebuah server build mem-push image baru, lalu satu atau banyak server yang menjalankan tinggal mem-pull-nya — tanpa perlu koordinasi apa pun selain “mereka berdua sama-sama tahu alamat registry-nya”.

Tag: cara kamu menunjuk versi tertentu

Tiap image di dalam sebuah repository dikenali lewat tag. Tag itu cuma label yang mudah dibaca manusia yang ditempelkan ke sebuah versi image tertentu — 1.4, 2.0.1, stable, latest. Saat mem-pull, kamu menyebut tag mana yang kamu mau, dan registry menyerahkan persis image itu kepadamu.

# pull versi spesifik yang sudah dipatok
pull registry.example.com/web-app:1.4

# pull apa pun yang saat ini ber-tag "latest"
pull registry.example.com/web-app:latest

Tag inilah cara kamu mengatur versi mana yang jalan di mana. Server produksimu bisa saja mem-pull web-app:1.4 supaya mereka tetap berada di rilis yang sudah dikenal dan teruji, sementara server staging mem-pull web-app:latest untuk menguji build terbaru. Ubah tag yang di-pull server-mu, deploy ulang, dan kamu sudah maju ke versi baru — atau mundur lagi.

`latest` bukan jaminan ajaib 'versi terbaru'

Tag latest adalah sumber kebingungan yang umum. Dia bukan penunjuk istimewa yang otomatis mengarah ke image yang benar-benar paling baru — dia cuma tag biasa yang kebetulan dinamai “latest”. Dia menunjuk ke image apa pun yang paling terakhir di-push dengan tag itu. Ada dua masalah yang menyertainya. Pertama, latest bisa berubah tanpa kamu sadari, jadi dua server yang mem-pull latest dengan jarak satu jam bisa saja dapat image yang berbeda — buruk buat reproduktibilitas. Kedua, kalau kamu tidak pernah mem-push tag latest, ya tag itu memang tidak akan ada. Untuk apa pun yang benar-benar kamu deploy, patok tag versi spesifik seperti 1.4 supaya kamu selalu tahu persis apa yang sedang berjalan.

Karena alasan yang sama, tim yang serius sering mem-pull image lewat digest-nya — sidik jari berbasis konten (sebuah hash panjang) dari byte image yang persis. Sebuah tag bisa dipindahkan untuk menunjuk image lain di kemudian hari; sebuah digest tidak bisa, karena dia adalah konten image itu sendiri. Mem-pull lewat digest menjamin kamu mendapat image yang sama byte demi byte setiap kali tanpa kecuali, dan inilah standar tertinggi untuk deployment yang bisa direproduksi.

Registry publik vs. privat

Registry hadir dalam dua corak besar, dan bedanya cuma soal siapa yang boleh mem-pull darinya.

Registry publik membolehkan siapa pun mengunduh image tanpa perlu login. Di sinilah base image resmi tinggal — image siap pakai yang minimalis untuk sistem operasi dan runtime bahasa pemrograman, yang di atasnya kamu bangun image-mu sendiri. Saat kamu memulai sebuah image “dari” base Linux atau dari runtime sebuah bahasa, base itu biasanya di-pull, secara terbuka, dari registry publik. Registry publik inilah cara ekosistem container berbagi balok-balok bangunan yang umum dipakai.

Registry privat mensyaratkan autentikasi — kamu harus login dulu sebelum bisa push atau pull. Di sinilah kamu menyimpan image aplikasi milikmu sendiri, yang berisi kode dan konfigurasi rahasiamu. Jelas kamu tidak mau barang itu bisa dibaca sembarang orang sedunia. Registry privat bisa berupa layanan berbayar, atau yang kamu jalankan sendiri di atas infrastrukturmu.

   REGISTRY PUBLIK                      REGISTRY PRIVAT
   ┌──────────────────┐                 ┌──────────────────┐
   │  base image OS   │                 │  app-kamu:1.4    │  🔒
   │  image bahasa    │                 │  api-kamu:2.0    │  🔒
   │  tools terbuka   │                 │  job-internal:9  │  🔒
   └──────────────────┘                 └──────────────────┘
   semua orang bisa pull                wajib login

Susunan yang sangat umum justru mencampur keduanya: kamu pull base image dari registry publik, membangun aplikasimu di atasnya, lalu push image aplikasi yang sudah jadi ke registry privat yang hanya bisa dijangkau timmu dan server-server-mu. Publik untuk bahan baku yang dipakai bersama, privat untuk produk jadimu.

Cara registry menyimpan image secara hemat

Kamu mungkin mengira tiap image disimpan sebagai satu berkas raksasa, padahal registry jauh lebih pintar dari itu — dan ini layak kamu tahu, karena menjelaskan kenapa push dan pull sering kali terasa mengejutkan cepat.

Sebuah container image dibangun dalam layer, yang ditumpuk satu di atas yang lain. Layer paling bawah bisa jadi base sistem operasi, layer berikutnya runtime bahasa, lalu dependensi yang kamu instal, dan layer paling atas adalah kodemu sendiri. Tiap layer disimpan terpisah di registry, dikenali lewat hash dari isinya.

Karena layer dipakai bersama dan dialamati berdasarkan kontennya, registry hanya pernah menyimpan satu salinan untuk tiap layer yang unik. Kalau sepuluh image-mu sama-sama dibangun di atas layer base OS yang sama, layer itu cuma disimpan sekali, bukan sepuluh kali. Dan saat kamu mem-pull sebuah image, kamu hanya mengunduh layer yang belum kamu punya secara lokal. Ubah satu baris kodemu, build ulang, lalu push — hanya layer teratas mungil yang berubah itulah yang benar-benar melintasi jaringan. Layer base yang besar, yang sudah ada di registry dan sudah ada di mesin tujuan, dilewati saja.

   IMAGE = tumpukan layer (tiap layer disimpan sekali, lewat hash)

   ┌────────────────────────┐  ← kodemu           (sering berubah, kecil)
   ├────────────────────────┤  ← dependensi       (kadang berubah)
   ├────────────────────────┤  ← runtime bahasa   (jarang berubah)
   └────────────────────────┘  ← base OS          (hampir tidak pernah)

   push/pull cuma memindah layer yang baru — sisanya dipakai ulang

Berbagi layer inilah salah satu alasan diam-diam kenapa container terasa begitu ringan dalam praktiknya. Pull pertama dari sebuah base yang masih segar mungkin lumayan besar, tapi tiap pull setelahnya kebanyakan tinggal memakai ulang yang sudah ada.

Di mana posisi registry dalam pipeline deployment

Dalam alur kerja nyata, registry adalah engsel antara membangun dan menjalankan. Bayangkan sebuah pipeline otomatis:

Seorang developer mem-push kode baru ke proyek.
Sebuah server build mengompilasinya lalu membangun container image yang segar, diberi tag dengan nomor versi yang baru.
Server build itu mem-push image tadi ke registry.
Langkah deployment menyuruh server produksi untuk mem-pull image baru dan me-restart container-nya dari image itu.

Perhatikan bahwa registry-lah yang membuat langkah 2 dan 4 bisa terjadi di mesin yang sama sekali berbeda, mungkin terpaut menit atau jam, dengan keyakinan penuh bahwa mereka menangani image yang identik. Dialah sumber kebenaran bersama. Inilah juga kenapa kontrol akses registry penting buat keamanan: siapa pun yang bisa mem-push ke registry-mu pada dasarnya bisa mengubah apa yang dijalankan server produksimu, jadi izin push dijaga ketat, dan server biasanya cuma diberi akses pull saja.

Registry adalah satu sumber kebenaran soal 'apa yang sedang jalan'

Saat ada yang rusak di produksi, salah satu pertanyaan paling berguna adalah “persisnya image mana yang sedang jalan?” Karena tiap container yang terdeploy berasal dari sebuah image ber-tag (atau, lebih baik lagi, dipatok lewat digest) di registry-mu, kamu bisa melacak container mana pun yang sedang berjalan langsung kembali ke sebuah artefak yang spesifik dan tak bisa diubah di registry — lalu dari situ ke kode persis yang membangunnya. Kemampuan menelusuri itu, dari container yang hidup sampai kembali ke byte di registry, adalah bagian besar dari kenapa registry jadi infrastruktur yang tidak bisa ditawar buat tim yang menjalankan container secara serius.

Kenapa registry penting

Container berjanji “build sekali, jalan di mana saja”, tapi janji itu hampa tanpa cara untuk memindahkan barang yang sudah dibangun dari tempat dia dibuat ke semua tempat yang dia tuju. Registry-lah cara itu. Dialah lapisan distribusi yang mengubah sebuah image lokal jadi sesuatu yang bisa dijalankan secara identik oleh seluruh dunia — atau cukup oleh armada server-mu saja.

Registry juga memberimu tiga hal yang luar biasa pentingnya dalam praktik: satu salinan resmi yang disepakati semua orang, versioning lewat tag dan digest supaya kamu selalu tahu apa yang terdeploy, dan kontrol akses supaya kode privatmu tetap privat sementara base image bersama tetap terbuka. Cabut semua itu dan kamu kembali ke menyalin berkas secara manual sambil berharap tiap mesin akhirnya dapat barang yang sama — persis kekacauan yang justru ingin dihindari ketika container diciptakan.

Kalau kamu mengikuti dari awal, ini menyatu rapi dengan apa yang sudah kamu tahu: image adalah paketnya, dan registry adalah tempat paket itu tinggal dan berpindah. Berdua, mereka adalah jawaban utuh soal bagaimana sebuah container yang kamu bangun di satu tempat bisa berakhir berjalan, tanpa berubah, di semua tempat lain.

Penutup

Ini gambaran utuhnya dalam satu tempat:

Container registry adalah server yang menyimpan dan menyebarkan container image — sebuah gudang tempat kamu mem-push image ke dalamnya dan mem-pull image keluar darinya.
Dua operasi intinya adalah push (mengunggah image untuk dibagikan) dan pull (mengunduh image untuk dijalankan). Registry duduk di antara mesin yang membangun dan mesin yang menjalankan.
Image ditata sebagai registry / repository : tag. Sebuah tag menunjuk ke sebuah versi; mem-pull lewat digest menjamin byte yang sama persis setiap kali.
latest cuma tag biasa, bukan penunjuk yang dijamin terbaru — patok versi yang nyata untuk apa pun yang kamu deploy.
Registry publik (siapa pun bisa pull) menampung base image bersama; registry privat (wajib login) menampung image aplikasimu sendiri.
Registry menyimpan image dalam layer yang dipakai bersama dan dialamati berdasarkan kontennya, jadi layer yang tidak berubah disimpan dan ditransfer cuma sekali — itulah yang membuat push dan pull cepat.
Dalam pipeline deployment, registry adalah satu sumber kebenaran antara membangun dan menjalankan, dan kontrol aksesnya adalah batas keamanan yang nyata.

Berikutnya, ada baiknya kita lihat apa yang menjaga container tetap terpisah aman satu sama lain dan dari host yang mereka pakai bersama — yaitu ide soal isolasi container, dan kenapa menjalankan banyak container di satu mesin tidak berubah jadi satu kekusutan besar yang ruwet.