Halaman ini diterjemahkan oleh Cloud Translation API.

Perubahan untuk proses build dan deployment di Google Cloud

Dokumen ini 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 menggunakan klien Docker, lihat Perubahan pada pengiriman dan pengambilan 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 Anda.
Mengaktifkan Cloud Build API dan API untuk layanan Google Cloud lainnya yang Anda gunakan dengan Artifact Registry.

Perubahan pada alur kerja

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

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

Contoh berikut mem-build image my-image, memberi tag dengan tag1, dan mendorongnya ke host gcr.io 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 mem-build dan men-deploy.

Saat Anda mengaktifkan beberapa Google Cloud API, Container Registry API akan diaktifkan secara otomatis. 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 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 yang jelas antara peran administrator dan build yang mengubah langkah-langkah dalam alur kerja build dan deployment. Untuk menyesuaikan alur kerja Container Registry untuk Artifact Registry, lakukan perubahan berikut. Setiap langkah ditautkan ke informasi tambahan tentang cara mengubah alur kerja.

Baru: Aktifkan Artifact Registry API.

Anda harus mengaktifkan Artifact Registry API. Cloud Build dan lingkungan runtime seperti Cloud Run dan GKE tidak otomatis mengaktifkan API untuk Anda.
Baru: Buat 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.
Berubah: Mem-build, 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
```
Berubah: 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 dengan 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 kepada pengguna atau akun layanan 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 cara mengaktifkan API untuk setiap layanan:

Container Registry

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

Lingkungan fleksibel App Engine
Cloud Build
Fungsi Cloud Run
Cloud Run
Pemindaian Container atau Pemindaian On-Demand di Artifact Analysis
Google Kubernetes Engine

Dengan izin default, pengguna yang dapat menjalankan build di Cloud Build, memindai penampung dengan Analisis Artefak, atau men-deploy penampung ke runtime Google Cloud secara implisit memiliki akses ke image di Container Registry jika 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 yang sama atau multi-region dengan kebijakan akses terpisah.

Perbandingan berikut menjelaskan penyiapan repositori di setiap layanan:

Container Registry

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

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

Misalnya, jika host gcr.io tidak ada di project my-project, mendorong 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 dalam project.
3. Menyimpan gambar sebagai gcr.io/my-project/my-image:1.0
Setelah pengiriman 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 pengiriman image awal dan pengiriman berikutnya tidak dapat dibedakan.

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

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 Administrator Repositori Artifact Registry harus create repositori sebelum Anda mengirim image ke repositori tersebut. Kemudian, Anda dapat memberikan izin ke repositori untuk pengguna lain.

Di Artifact Registry, setiap repositori adalah resource terpisah. Oleh karena itu, semua jalur gambar 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 gambar tidak valid (tidak menyertakan repositori) :

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

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

Mengirim gambar ke us-central1-docker.pkg.dev/my-project/team1 jika us-central1-docker.pkg.dev/my-project/team1 tidak ada.
Mendorong gambar ke us-central1-docker.pkg.dev/my-project/team2 saat 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 tingkat bucket penyimpanan. Artifact Registry mendukung kontrol akses di tingkat 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 project.

Storage Object Viewer di tingkat bucket penyimpanan: Mengambil (membaca) image dari host registry yang ada dalam project.
Storage Legacy Bucket Writer di tingkat bucket penyimpanan: Mengirim (menulis) dan menarik (membaca) image untuk host registry yang ada dalam project.
Storage Admin di tingkat project: Menambahkan host registry ke project dengan mendorong image awal ke host.

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

Izin di bucket penyimpanan berlaku untuk semua repositori di registry. Misalnya, setiap pengguna dengan 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 peran sendiri untuk mengontrol akses. Peran ini memberikan pemisahan yang jelas antara peran administrator dan pengguna repositori.

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

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

Pembaca Artifact Registry: Mencantumkan artefak dan repositori. Download artefak.
Penulis Artifact Registry: Mencantumkan artefak dan repositori. Mendownload artefak, mengupload versi artefak baru, dan menambahkan atau memperbarui tag.
Administrator Repositori Artifact Registry: Izin Artifact Registry Writer dan izin untuk menghapus artefak dan tag.
Artifact Registry Administrator: Izin Administrator Repositori Artifact Registry dan izin untuk membuat, memperbarui, menghapus, dan memberikan izin ke repositori.

Anda dapat menerapkan izin ini di tingkat repositori. Contoh:

Memberikan 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.

Mem-build 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 mem-build, memberi tag, dan mengirim image dalam satu langkah.

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

Untuk menyesuaikan alur kerja Container Registry:

Siapkan repositori sebelum Anda mengirim image ke repositori tersebut.
Perbarui jalur gambar di file konfigurasi build atau perintah gcloud builds submit.

Membangun 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 mem-build 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'

Kemudian, Anda dapat mem-build image dengan perintah:

gcloud builds submit --config cloudbuild.yaml

Membangun dengan Dockerfile

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

Contoh perintah berikut mem-build image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1 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 dalam 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 contoh 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 contoh gambar us-docker.pkg.dev/cloudrun/container/hello.

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 berikut untuk Artifact Registry 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