Perubahan untuk proses build dan deployment di Google Cloud

Dokumen ini akan memandu Anda memahami perbedaan antara Container Registry dan Artifact Registry saat mem-build image container dengan Cloud Build dan men-deploy-nya ke lingkungan runtime Google Cloud seperti Cloud Run atau Google Kubernetes Engine.

Dalam panduan ini, perbandingan berfokus pada repositori Artifact Registry standar, repositori Artifact Registry reguler yang independen dari Container Registry, dan mendukung semua fitur Artifact Registry. Jika administrator Anda menyiapkan repositori dengan dukungan domain gcr.io, permintaan ke nama host gcr.io akan otomatis dialihkan ke repositori Artifact Registry yang sesuai, dan akun layanan default yang memiliki akses ke Container Registry memiliki izin default yang setara untuk Artifact Registry.

Untuk mempelajari perbedaan antara Container Registry dan Artifact Registry yang menggunakan klien Docker, baca artikel Perubahan pada pengiriman dan penarikan dengan Docker.

Gunakan informasi ini untuk membantu Anda menyesuaikan perintah, konfigurasi, atau dokumentasi yang ada yang berfokus pada Container Registry dengan Cloud Build.

Sebelum memulai

Dokumen ini mengasumsikan bahwa Anda telah:

Mengaktifkan Artifact Registry di project.
Mengaktifkan Cloud Build API dan API untuk layanan Google Cloud lain yang Anda gunakan dengan Artifact Registry.

Perubahan pada alur kerja

Saat Anda menggunakan Cloud Build dengan Container Registry dalam project yang sama, alur kerja akan terlihat seperti ini:

Buat, beri tag, dan kirim image ke repositori dengan Cloud Build, menggunakan Dockerfile atau file konfigurasi build.

Contoh berikut mem-build image my-image, memberinya tag dengan tag1, dan mendorongnya ke gcr.io host dalam project my-project:
```
gcloud builds submit --tag gcr.io/my-project/my-image:tag1
```
Lingkungan runtime Google Cloud, seperti Cloud Run dan Google Kubernetes Engine, mengambil image dari registry.

Misalnya, perintah ini men-deploy image dari langkah sebelumnya ke Cloud Run sebagai my-service.
```
gcloud run deploy my-service --image gcr.io/my-project/my-image:tag1
```

Alur kerja Container Registry menggabungkan tanggung jawab administrator dengan proses build dan deployment.

Saat Anda mengaktifkan beberapa Google Cloud API, Container Registry API akan otomatis diaktifkan. Artinya, pengguna layanan ini memiliki akses implisit ke Container Registry dalam project yang sama. Misalnya, pengguna yang dapat menjalankan build di Cloud Build dapat mengirim image ke registry dan menambahkan host registry secara default.
Akun layanan Cloud Build memiliki izin untuk membuat bucket penyimpanan Cloud Storage. Artinya, akun dapat otomatis menambahkan host Container Registry ke sebuah project saat pertama kali mengirimkan image ke host. Hal ini juga berarti bahwa akun dapat membuat, membaca, dan menulis ke bucket penyimpanan di seluruh project, termasuk bucket yang tidak digunakan oleh Container Registry.

Di Artifact Registry, ada pemisahan peran administrator dan build yang jelas yang mengubah langkah-langkah dalam alur kerja build dan deployment. Guna menyesuaikan alur kerja Container Registry untuk Artifact Registry, lakukan perubahan berikut. Setiap langkah ditautkan ke informasi tambahan tentang cara mengubah alur kerja.

Baru: Mengaktifkan Artifact Registry API.

Anda harus mengaktifkan Artifact Registry API. Cloud Build dan lingkungan runtime seperti Cloud Run dan GKE tidak secara otomatis mengaktifkan API untuk Anda.
Baru: Membuat repositori Docker target jika belum ada. Anda harus membuat repositori sebelum dapat mengirim image apa pun ke dalamnya. Mengirim image tidak dapat memicu pembuatan repositori dan akun layanan Cloud Build tidak memiliki izin untuk membuat repositori.
Diubah: Membangun, memberi tag, dan mengirim image ke repositori dengan Cloud Build, menggunakan Dockerfile atau file konfigurasi build.

Contoh perintah berikut sama dengan contoh Container Registry, tetapi menggunakan jalur repositori Artifact Registry untuk image.
```
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```
Diubah: Men-deploy image ke lingkungan runtime Google Cloud seperti Cloud Run atau GKE.

Contoh perintah berikut sama dengan contoh Container Registry, tetapi menggunakan jalur repositori Artifact Registry untuk image.
```
gcloud run deploy my-service --image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```

Selain itu, Artifact Registry menggunakan peran yang berbeda dari Container Registry untuk mengontrol akses ke image. Anda perlu mengonfigurasi izin dalam situasi berikut:

Lingkungan runtime Cloud Build atau Google Cloud berada di project yang berbeda dengan Artifact Registry.
Anda menggunakan akun layanan kustom untuk layanan Google Cloud seperti Cloud Build atau GKE, bukan akun layanan default.
Anda memberikan izin ke akun layanan atau pengguna lain.

Mengaktifkan API

Poin utama:

Anda harus mengaktifkan Artifact Registry API selain API untuk layanan Google Cloud lainnya seperti Cloud Build, Cloud Run, dan GKE.

Perbandingan berikut menjelaskan pengaktifan API untuk setiap layanan:

Container Registry

Saat Anda mengaktifkan Google Cloud API berikut, Container Registry API juga otomatis diaktifkan:

Lingkungan fleksibel App Engine
Cloud Build
Cloud Functions
Cloud Run
Pemindaian Container atau Pemindaian On-Demand dalam Analisis Artefak
Google Kubernetes Engine

Dengan izin default, pengguna yang dapat menjalankan build di Cloud Build, memindai container dengan Analisis Artefak, atau men-deploy container ke runtime Google Cloud secara implisit memiliki akses ke image di Container Registry saat registry berada dalam project yang sama.

Artifact Registry

Anda harus mengaktifkan Artifact Registry API. Layanan seperti Cloud Build, Cloud Run, dan GKE tidak otomatis mengaktifkan Artifact Registry API.

Anda dapat mengaktifkan beberapa API dalam project yang sama menggunakan gcloud. Misalnya, untuk mengaktifkan Cloud Build API dan Artifact Registry API, jalankan perintah:

gcloud services enable
    artifactregistry.googleapis.com \
    cloudbuild.googleapis.com

Menambahkan registry dan repositori

Poin utama:

Anda harus membuat repositori Docker Artifact Registry sebelum mengirim image ke dalamnya.
Container Registry menyimpan semua image dalam satu multi-region di bucket penyimpanan yang sama. Di Artifact Registry, Anda dapat membuat beberapa repositori di region atau multi-region yang sama dengan kebijakan akses yang terpisah.

Perbandingan berikut menjelaskan penyiapan repositori di setiap layanan:

Container Registry

Di Container Registry, Anda dapat menambahkan hingga empat host registry ke project. Anda menambahkan host registry dengan mengirim image pertama.

Untuk menambahkan registry seperti gcr.io ke project Anda, akun dengan peran Storage Admin di level project mengirim image awal.

Misalnya, jika host gcr.io tidak ada dalam project my-project, mengirim image gcr.io/my-project/my-image:1.0 akan memicu langkah-langkah berikut:
1. Menambahkan host gcr.io ke project
2. Buat bucket penyimpanan untuk gcr.io di project.
3. Simpan gambar sebagai gcr.io/my-project/my-image:1.0
Setelah push awal ini, Anda dapat memberikan izin ke bucket penyimpanan untuk pengguna lain.

Secara default, Cloud Build memiliki izin yang diperlukan untuk membuat bucket penyimpanan, sehingga push image awal dan push berikutnya tidak dapat dibedakan.

Dalam sebuah project, host registry menyimpan semua image di bucket penyimpanan yang sama. Pada contoh berikut, project my-project memiliki dua image yang disebut web-app di registry gcr.io. Salah satunya berada tepat di bawah project ID my-project. Image lainnya ada di team1 repositori.

gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app

Artifact Registry

Cloud Build tidak memiliki izin untuk membuat repositori standar di domain pkg.dev Artifact Registry.

Akun dengan peran Artifact Registry Repository Administrator harus membuat repositori sebelum Anda mengirim gambar ke dalamnya. Anda kemudian dapat memberikan izin ke repositori untuk pengguna lain.

Di Artifact Registry, setiap repositori adalah resource terpisah. Oleh karena itu, semua jalur image harus menyertakan repositori.

Jalur gambar yang valid:

us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0

Jalur image tidak valid (tidak termasuk repositori) :

us-central1-docker.pkg.dev/my-project/web-app:1.0

Contoh berikut menunjukkan situasi saat pengiriman image ke repositori yang tidak ada gagal.

Mengirim image ke us-central1-docker.pkg.dev/my-project/team1 jika us-central1-docker.pkg.dev/my-project/team1 tidak ada.
Mengirim gambar ke us-central1-docker.pkg.dev/my-project/team2 jika us-central1-docker.pkg.dev/my-project/team1 ada, tetapi us-central1-docker.pkg.dev/my-project/team2 tidak ada.

Memberikan izin

Poin utama:

Layanan Google Cloud memiliki akses baca atau tulis yang setara ke Container Registry dan Artifact Registry. Namun, akun layanan Cloud Build default tidak dapat membuat repositori standar di domain pkg.dev.
Berikan peran Artifact Registry yang sesuai ke akun lain yang mengakses Artifact Registry.
Container Registry mendukung kontrol akses di level bucket penyimpanan. Artifact Registry mendukung kontrol akses di level repositori.

Perbandingan berikut menjelaskan izin untuk setiap layanan:

Container Registry

Container Registry menggunakan peran Cloud Storage untuk mengontrol akses. Cloud Build memiliki izin yang diperlukan dalam peran Storage Admin untuk menambahkan host Container Registry ke sebuah project.

Storage Object Viewer pada level bucket penyimpanan: Ambil (baca) image dari host registry yang ada dalam project.
Penulis Bucket Lama Penyimpanan di level bucket penyimpanan: Mendorong (menulis) dan menarik (membaca) image untuk host registry yang ada dalam project.
Admin Penyimpanan di level project: Menambahkan host registry ke project dengan mengirim image awal ke host.

Setelah image awal dikirim ke registry, Anda dapat memberikan peran Cloud Storage ke akun lain yang memerlukan akses ke bucket penyimpanan. Perhatikan bahwa setiap akun dengan semua izin dalam peran Storage Admin dapat membaca, menulis, dan menghapus bucket penyimpanan dan objek penyimpanan di seluruh project.

Izin pada bucket penyimpanan berlaku untuk semua repositori dalam registry. Misalnya, setiap pengguna yang memiliki izin Storage Object Viewer di bucket untuk gcr.io/my-project dapat membaca gambar di semua repositori ini:

gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production

Artifact Registry

Artifact Registry memiliki perannya sendiri untuk mengontrol akses. Peran ini memberikan pemisahan yang jelas antara peran pengguna administrator dan repositori.

Cloud Build memiliki izin dalam peran Artifact Registry Writer karena hanya perlu mengirim dan mengambil image dengan repositori standar di domain pkg.dev.

Hanya akun yang mengelola repositori yang boleh memiliki peran Artifact Registry Repository Administrator atau Artifact Registry Administrator.

Pembaca Artifact Registry: Membuat daftar artefak dan repositori. Download artefak.
Penulis Artifact Registry: Membuat daftar artefak dan repositori. Download artefak, upload versi artefak baru, dan tambahkan atau perbarui tag.
Administrator Repositori Artifact Registry: Izin dan izin Penulis Artifact Registry untuk menghapus artefak dan tag.
Artifact Registry Administrator: Izin dan izin Administrator Repositori Artifact Registry untuk membuat, memperbarui, menghapus, dan memberikan izin ke repositori.

Anda dapat menerapkan izin ini di level repositori. Contoh:

Berikan akses ke Tim 1 untuk us-central1-docker.pkg.dev/my-project/team1
Berikan akses ke Tim 2 untuk us-central1-docker.pkg.dev/my-project/team2.

Untuk mengetahui detail tentang cara memberikan izin Artifact Registry, lihat dokumentasi kontrol akses.

Membuat dan mengirim image

Poin utama:

Anda harus membuat repositori Docker Artifact Registry sebelum mengirim image ke dalamnya.
Nama host Artifact Registry berbeda dengan nama host Container Registry.

Cloud Build dapat membuat, memberi tag, dan mengirim image dalam satu langkah.

Dengan Container Registry, Cloud Build dapat berhasil mengirim image ke host registry yang belum ada dalam project Google Cloud. Untuk push image awal ini, Cloud Build memiliki izin untuk menambahkan host registry ke project secara otomatis.

Untuk menyesuaikan alur kerja Container Registry:

Siapkan repositori Anda sebelum mengirim image ke dalamnya.
Update jalur image di file konfigurasi atau file konfigurasi build atau perintah gcloud builds submit.

Mem-build dengan file konfigurasi build

Ganti jalur Container Registry untuk image yang Anda build dengan jalur ke repositori Artifact Registry yang ada.

Contoh file cloudbuild.yaml berikut membuat image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1'

Anda kemudian dapat mem-build image dengan perintah:

gcloud builds submit --config cloudbuild.yaml

Membangun aplikasi dengan Dockerfile

Ganti jalur Container Registry untuk image yang Anda build dengan jalur ke repositori Artifact Registry yang ada.

Contoh perintah berikut membuat us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1 image dengan Dockerfile di direktori saat ini:

gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1

Men-deploy image

Poin utama:

Nama host Artifact Registry berbeda dengan nama host Container Registry.

Untuk menyesuaikan alur kerja Container Registry, perbarui jalur image di konfigurasi deployment dan perintah deployment Anda. Bagian berikut menunjukkan contoh untuk Cloud Build, Cloud Run, dan GKE, tetapi pendekatan yang sama berlaku untuk layanan Google Cloud lainnya yang men-deploy image.

Cloud Build

Ganti jalur Container Registry untuk image yang Anda deploy dengan jalur ke repositori Artifact Registry yang ada.

Contoh file cloudbuild.yaml berikut men-deploy gambar sampel us-docker.pkg.dev/cloudrun/container/hello.

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args:
  - 'run'
  - 'deploy'
  - 'cloudrunservice'
  - '--image'
  - 'us-docker.pkg.dev/cloudrun/container/hello'
  - '--region'
  - 'us-central1'
  - '--platform'
  - 'managed'
  - '--allow-unauthenticated'

Cloud Run

Ganti jalur Container Registry untuk image yang Anda deploy dengan jalur ke repositori Artifact Registry yang ada.

Misalnya, perintah ini men-deploy us-docker.pkg.dev/cloudrun/container/hello gambar contoh.

gcloud run deploy my-service --image us-docker.pkg.dev/cloudrun/container/hello

GKE

Ganti jalur Container Registry untuk image yang Anda build dengan jalur ke repositori Artifact Registry yang ada.

Contoh untuk Artifact Registry berikut menggunakan image contoh us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0.

Membuat cluster dari command line:

kubectl create deployment hello-server --image=us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0

Menentukan image dalam manifes deployment:

In a deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0