Strategi Container Registry di GCP: Dari GCR ke Artifact Registry

Pada 18 Maret 2025, Google menutup Container Registry (gcr.io) untuk push baru. Jika Anda masih menggunakan gcr.io/my-project/my-image di pipeline CI/CD Anda, Anda perlu bermigrasi ke Artifact Registry — sekarang. Di Commsult Indonesia, saya mengelola migrasi untuk tiga proyek GCP dan dua sistem CI/CD pada Februari 2025 sebelum batas waktu. Di luar migrasi, Artifact Registry menawarkan fitur yang tidak pernah dimiliki gcr.io: IAM per repository yang lebih granular, vulnerability scanning bawaan, caching repository jarak jauh untuk image Docker Hub, dan pembuatan SBOM. Panduan ini mencakup migrasi dan workflow baru.

Apa yang Ditambahkan Artifact Registry Dibanding GCR

Container Registry (gcr.io) adalah satu namespace global per proyek. Setiap image yang Anda push ke gcr.io/my-project/ dapat diakses oleh siapa saja dengan akses baca level proyek. Artifact Registry memperkenalkan IAM level repository — Anda dapat memberikan akun layanan CI/CD akses push ke satu repository tanpa memiliki akses baca ke yang lain. Ini jauh lebih aman untuk proyek dengan banyak tim dan banyak repository image. Artifact Registry juga mendukung beberapa format artifact selain Docker: paket npm, artifact Maven, paket Python, dan chart Helm — semuanya dalam satu layanan dengan IAM terpadu.

Membuat Repository Artifact Registry

Setiap repository Artifact Registry memiliki format (Docker, npm, Maven, dll.), lokasi (region), dan kebijakan IAM. Untuk image Docker, buat satu repository per tim atau per cluster aplikasi daripada satu repository global. Gunakan repository regional (asia-southeast1 untuk region Singapura) untuk meminimalkan latensi pull dari cluster GKE dan layanan Cloud Run di region yang sama. Aktifkan vulnerability scanning di level repository — Artifact Registry berintegrasi dengan Container Analysis untuk memindai image dari CVE yang diketahui saat push dan terus menerus ketika kerentanan baru diterbitkan.

Migrasi dari GCR ke Artifact Registry

Google menyediakan alat migrasi otomatis yang membuat repository Artifact Registry dalam mode kompatibilitas gcr.io — image yang di-push ke gcr.io/my-project/my-image secara transparan dialihkan ke backend Artifact Registry. Untuk migrasi bersih (direkomendasikan), buat repository pkg.dev baru, perbarui semua pipeline CI/CD untuk push ke URL registry baru (asia-southeast1-docker.pkg.dev/my-project/my-repo/my-image:tag), dan perbarui semua konfigurasi deployment (manifes Kubernetes, definisi layanan Cloud Run, file docker-compose) untuk pull dari URL baru. Jendela migrasi terdokumentasi dengan baik — uji dengan satu image berisiko rendah terlebih dahulu.

Strategi Pemberian Tag Docker Image

Strategi pemberian tag image yang kacau menyebabkan kebingungan deployment — versi mana yang berjalan di produksi? Strategi yang saya gunakan: tag versi semantik untuk image rilis (v1.2.3), tag git SHA untuk setiap build (sha-abc1234), dan tag branch untuk image spesifik branch (main-latest, feature-login-latest). Jangan gunakan latest sebagai satu-satunya tag — ini adalah floating tag yang membuat rollback tidak mungkin tanpa mengetahui SHA mana yang ditunjuk 'latest' saat itu. Dalam pipeline CD Anda, beri tag image produksi dengan versi semver dan git SHA. Ini memungkinkan Anda mengkorelasikan container yang berjalan dengan commit kode yang tepat.

# Create Artifact Registry repository
gcloud artifacts repositories create my-app-images   --repository-format=docker   --location=asia-southeast1   --description="Application Docker images"   --project=my-project

# Enable vulnerability scanning
gcloud artifacts repositories update my-app-images   --location=asia-southeast1   --enable-vulnerability-scanning

# Grant CI/CD service account push access (repo-level, not project-level)
gcloud artifacts repositories add-iam-policy-binding my-app-images   --location=asia-southeast1   --member="serviceAccount:cicd-sa@my-project.iam.gserviceaccount.com"   --role="roles/artifactregistry.writer"

# Build and push with new registry URL
docker build -t asia-southeast1-docker.pkg.dev/my-project/my-app-images/api:v1.2.3 .
docker push asia-southeast1-docker.pkg.dev/my-project/my-app-images/api:v1.2.3

# Check vulnerability scan results
gcloud artifacts docker images describe   asia-southeast1-docker.pkg.dev/my-project/my-app-images/api:v1.2.3   --show-package-vulnerability

Pemindaian Kerentanan Otomatis

Artifact Registry berintegrasi dengan Container Analysis untuk pemindaian kerentanan saat push. Ketika Anda push image, Container Analysis secara otomatis memindainya terhadap database CVE dan menampilkan temuan di konsol Artifact Registry. Aktifkan ini di level proyek. Dalam pipeline CI/CD Anda, tambahkan langkah setelah push yang mem-query Container Analysis untuk temuan kerentanan kritis dan tinggi menggunakan gcloud artifacts docker images describe. Blokir deployment jika kerentanan kritis ditemukan. Ini menciptakan gerbang keamanan otomatis yang mencegah image yang diketahui rentan mencapai produksi.

┌─────────────────────────────────────────────────────┐
│          GCR → Artifact Registry Migration           │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Before (gcr.io):                                   │
│  gcr.io/my-project/my-image:tag                     │
│  → Project-level IAM only                           │
│  → No vulnerability scanning                        │
│  → Docker images only                               │
│                                                     │
│  After (Artifact Registry):                         │
│  asia-southeast1-docker.pkg.dev/                    │
│    my-project/my-repo/my-image:sha-abc1234          │
│  → Repository-level IAM                             │
│  → Built-in CVE scanning                            │
│  → Docker + npm + Maven + Helm                      │
└─────────────────────────────────────────────────────┘

Konfigurasi IAM untuk Akses Hak Istimewa Minimum

Konfigurasikan akun layanan dengan izin minimal untuk setiap peran dalam workflow image Anda. Pipeline CI/CD mendapatkan roles/artifactregistry.writer pada repository spesifik yang mereka push. Sistem deployment (GKE, Cloud Run) mendapatkan roles/artifactregistry.reader pada repository yang mereka pull. Jangan pernah memberikan artifactregistry.admin level proyek ke akun layanan CI/CD — ini memberikan akses ke semua repository dalam proyek. Binding IAM level repository, ditambahkan melalui gcloud artifacts repositories add-iam-policy-binding, memberlakukan prinsip hak istimewa minimum dan membatasi blast radius jika kredensial CI/CD dikompromikan.

Manajemen Lifecycle Image dan Pembersihan

Tanpa kebijakan pembersihan, repository Artifact Registry mengakumulasi ribuan tag image selama berbulan-bulan. Penyimpanan murah ($0,10/GB/bulan) tetapi pertumbuhan yang tidak dikelola menciptakan kebisingan operasional — versi mana yang di produksi? Mana yang bisa dihapus dengan aman? Artifact Registry mendukung kebijakan pembersihan yang secara otomatis menghapus image tanpa tag yang lebih tua dari N hari dan versi di luar N terbaru untuk awalan tag tertentu. Atur kebijakan untuk menyimpan 10 versi bertag terakhir dan menghapus image tanpa tag yang lebih tua dari 7 hari. Jalankan ini sebagai job Cloud Scheduler + Cloud Run terjadwal untuk repository yang tidak mendukung kebijakan pembersihan native.

Pendapat Saya: Artifact Registry adalah Peningkatan Nyata

Saya awalnya frustrasi dengan migrasi paksa dari gcr.io — pipeline kami bekerja dengan baik dan migrasi menambah pekerjaan. Setelah menyelesaikan migrasi dan menggunakan Artifact Registry selama beberapa bulan, saya benar-benar lebih menyukainya. IAM level repository lebih aman. Integrasi vulnerability scanning menangkap masalah tanpa tooling tambahan. Caching remote repository untuk Docker Hub telah menghilangkan semua masalah batas rate kami. Dukungan multi-format berarti kami kini juga menggunakan Artifact Registry untuk npm package registry kami (paket privat untuk alat internal), mengkonsolidasikan dua sistem terpisah menjadi satu. Jika Anda belum bermigrasi, lakukan sekarang — manfaatnya nyata.

Artikel Terkait

• Cloud Run vs Cloud Functions: Memilih Platform Google Serverless yang Tepat
• GitHub Actions Self-Hosted Runner untuk Deployment GCP Privat