Questo documento illustra le differenze tra Container Registry e Artifact Registry durante la creazione di immagini container con Cloud Build e il loro deployment in Google Cloud ambienti di runtime come Cloud Run o Google Kubernetes Engine.
In questa guida, i confronti si concentrano sui repository standard di Artifact Registry, ovvero i repository di Artifact Registry regolari indipendenti da Container Registry e che supportano tutte le funzionalità di Artifact Registry. Se il tuo
amministratore ha configurato
repository con supporto per il dominio gcr.io, le richieste ai nomi di host gcr.io
vengono reindirizzate automaticamente a un corrispondente
repository Artifact Registry e gli account di servizio predefiniti che hanno accesso
a Container Registry dispongono di autorizzazioni predefinite equivalenti per Artifact Registry.
Per scoprire le differenze tra Container Registry e Artifact Registry utilizzando un client Docker, consulta Modifiche al push e al pull con Docker.
Utilizza queste informazioni per adattare i comandi, la configurazione o la documentazione esistenti incentrati su Container Registry con Cloud Build.
Prima di iniziare
Questo documento presuppone che tu abbia:
- Abilita Artifact Registry nel progetto.
- Abilitato l'API Cloud Build e l'API per qualsiasi Google Cloud altro servizio Google Cloud che utilizzi con Artifact Registry.
Modifiche al flusso di lavoro
Quando utilizzi Cloud Build con Container Registry nello stesso progetto, il workflow è il seguente:
Crea, tagga ed esegui il push di un'immagine nel repository con Cloud Build, utilizzando un file
Dockerfile
o un file di configurazione della build.L'esempio seguente crea l'immagine
my-image
, la tagga contag1
e la spinge all'hostgcr.io
nel progettomy-project
:gcloud builds submit --tag gcr.io/my-project/my-image:tag1
Google Cloud Gli ambienti di runtime, come Cloud Run e Google Kubernetes Engine, estraggono le immagini dal registry.
Ad esempio, questo comando esegue il deployment dell'immagine del passaggio precedente in Cloud Run come
my-service
.gcloud run deploy my-service --image gcr.io/my-project/my-image:tag1
Il flusso di lavoro di Container Registry combina le responsabilità dell'amministratore con la compilazione e il deployment.
- Quando attivi alcune Google Cloud API, l'API Container Registry viene attivata automaticamente. Ciò significa che gli utenti di questi servizi hanno accesso implicito a Container Registry nello stesso progetto. Ad esempio, gli utenti che possono eseguire build in Cloud Build possono eseguire il push delle immagini nei registry e aggiungere gli host dei registry per impostazione predefinita.
- L'account di servizio Cloud Build dispone delle autorizzazioni per creare bucket di archiviazione Cloud Storage. Ciò significa che l'account può aggiungere automaticamente gli host di Container Registry a un progetto la prima volta che esegue il push di un'immagine all'host. Ciò significa anche che l'account può creare, leggere e scrivere nei bucket di archiviazione dell'intero progetto, inclusi i bucket non utilizzati da Container Registry.
In Artifact Registry, esiste una chiara separazione dei ruoli di amministratore e di compilazione che modifica i passaggi del flusso di lavoro di compilazione e di deployment. Per adattare il flusso di lavoro di Container Registry ad Artifact Registry, apporta le seguenti modifiche. Ogni passaggio rimanda a informazioni aggiuntive sulla modifica del flusso di lavoro.
Novità: abilita l'API Artifact Registry.
Devi abilitare l'API Artifact Registry. Cloud Build e gli ambienti di runtime come Cloud Run e GKE non abilitano automaticamente l'API.
Novità: crea il repository Docker di destinazione se non esiste già. Devi creare un repository prima di poter eseguire il push delle immagini. Il push di un'immagine non può attivare la creazione di un repository e l'account di servizio Cloud Build non dispone delle autorizzazioni per creare repository.
Modifica: crea, tagga ed esegui il push di un'immagine nel repository con Cloud Build utilizzando un file
Dockerfile
o di configurazione della build.Il seguente comando di esempio è uguale a quello di Container Registry, ma utilizza un percorso del repository Artifact Registry per l'immagine.
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Modifica: esegui il deployment dell'immagine in un Google Cloud ambiente di runtime come Cloud Run o GKE.
Il seguente comando di esempio è uguale a quello di Container Registry, ma utilizza il percorso del repository Artifact Registry per l'immagine.
gcloud run deploy my-service --image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Inoltre, Artifact Registry utilizza ruoli diversi rispetto a Container Registry per controllare l'accesso alle immagini. Devi configurare le autorizzazioni nelle seguenti situazioni:
- Cloud Build o gli ambienti di runtime si trovano in un progetto diverso da Artifact Registry. Google Cloud
- Utilizzi account di servizio personalizzati per Google Cloud servizi come Cloud Build o GKE anziché gli account di servizio predefiniti.
- Hai concesso autorizzazioni ad altri account utente o di servizio.
Attivazione dell'API
Punti chiave:
- Devi abilitare l'API Artifact Registry oltre all'API per altri Google Cloud servizi come Cloud Build, Cloud Run e GKE.
Il seguente confronto descrive l'attivazione dell'API per ciascun servizio:
Container Registry
Quando attivi le seguenti Google Cloud API, viene attivata automaticamente anche l'API Container Registry:
- Ambiente flessibile di App Engine
- Cloud Build
- Funzioni Cloud Run
- Cloud Run
- Scansione dei contenitori o analisi on demand in Artifact Analysis
- Google Kubernetes Engine
Con le autorizzazioni predefinite, gli utenti che possono eseguire build in Cloud Build, eseguire la scansione dei container con Artifact Analysis o eseguire il deployment dei container nei runtimeGoogle Cloud hanno implicitamente accesso alle immagini in Container Registry quando il registry si trova nello stesso progetto.
Artifact Registry
Devi abilitare l'API Artifact Registry. Servizi come Cloud Build, Cloud Run e GKE non attivano automaticamente l'API Artifact Registry.
Puoi abilitare più API nello stesso progetto utilizzando gcloud. Ad esempio, per abilitare l'API Cloud Build e l'API Artifact Registry, esegui il comando:
gcloud services enable
artifactregistry.googleapis.com \
cloudbuild.googleapis.com
Aggiunta di registry e repository
Punti chiave:
- Devi creare un repository Docker di Artifact Registry prima di eseguire il push di un'immagine.
- Container Registry archivia tutte le immagini in un'unica regione multipla nello stesso bucket di archiviazione. In Artifact Registry, puoi creare più repository nella stessa regione o in più regioni con criteri di accesso distinti.
Il seguente confronto descrive la configurazione del repository in ogni servizio:
Container Registry
In Container Registry puoi aggiungere fino a quattro host del registry al tuo progetto. Aggiungi un host del registry eseguendo il push della prima immagine.
Per aggiungere un registry come
gcr.io
al tuo progetto, un account con il ruolo Amministratore archiviazione a livello di progetto spinge un'immagine iniziale.Ad esempio, se l'host
gcr.io
non esiste nel progettomy-project
, l'invio dell'immaginegcr.io/my-project/my-image:1.0
attiva i seguenti passaggi:- Aggiungi l'host
gcr.io
al progetto - Crea un bucket di archiviazione per
gcr.io
nel progetto. - Memorizza l'immagine come
gcr.io/my-project/my-image:1.0
- Aggiungi l'host
Dopo questo push iniziale, puoi concedere autorizzazioni al bucket di archiviazione per altri utenti.
Per impostazione predefinita, Cloud Build dispone delle autorizzazioni necessarie per creare un bucket di archiviazione, pertanto il push dell'immagine iniziale e i push successivi sono indistinguibili.
All'interno di un progetto, un host del registry archivia tutte le immagini nello stesso bucket di archiviazione. Nel seguente esempio, il progetto my-project
ha due immagini chiamate
web-app
nel registry gcr.io
. Uno si trova direttamente sotto l'ID progetto
my-project
. L'altra immagine si trova nel repository team1
.
gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app
Artifact Registry
Cloud Build non dispone delle autorizzazioni per creare un repository standard nel dominio Artifact Registry pkg.dev
.
Un account con il ruolo Amministratore del repository Artifact Registry deve creare il repository prima di eseguire il push delle immagini. Puoi quindi concedere autorizzazioni al repository per altri utenti.
In Artifact Registry ogni repository è una risorsa separata. Pertanto, tutti i percorsi delle immagini devono includere un repository.
Percorsi immagine validi:
us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0
Percorso immagine non valido (non include un repository) :
us-central1-docker.pkg.dev/my-project/web-app:1.0
Gli esempi riportati di seguito mostrano situazioni in cui l'invio di un'immagine a un repository mancante non va a buon fine.
- Eseguire il push di un'immagine in
us-central1-docker.pkg.dev/my-project/team1
seus-central1-docker.pkg.dev/my-project/team1
non esiste. - Caricamento di un'immagine in
us-central1-docker.pkg.dev/my-project/team2
quando esisteus-central1-docker.pkg.dev/my-project/team1
, ma non esisteus-central1-docker.pkg.dev/my-project/team2
.
Concessione di autorizzazioni
Punti chiave:
- I serviziGoogle Cloud hanno accesso in lettura o scrittura equivalente sia a Container Registry sia ad Artifact Registry. Tuttavia, l'account di servizio Cloud Build predefinito non può creare repository standard nel dominio
pkg.dev
. - Concedi i ruoli Artifact Registry appropriati agli altri account che accedono ad Artifact Registry.
- Container Registry supporta il controllo dell'accesso a livello di bucket di archiviazione. Artifact Registry supporta il controllo dell'accesso a livello di repository.
Il seguente confronto descrive le autorizzazioni per ciascun servizio:
Container Registry
Container Registry utilizza i ruoli Cloud Storage per controllare l'accesso. Cloud Build dispone delle autorizzazioni necessarie nel ruolo Amministratore Storage per aggiungere gli host di Container Registry a un progetto.
- Visualizzatore oggetti Storage a livello di bucket di archiviazione
- Esegui il pull (leggi) delle immagini dagli host del registry esistenti nel progetto.
- Storage Legacy Bucket Writer a livello di bucket di archiviazione
- Esegui il push (scrittura) e il pull (lettura) delle immagini per gli host di registry esistenti nel progetto.
- Amministratore archiviazione a livello di progetto
- Aggiungi un host del registry a un progetto eseguendo il push di un'immagine iniziale sull'host.
Dopo il push iniziale dell'immagine in un registry, concedi i ruoli Cloud Storage ad altri account che richiedono l'accesso al bucket di archiviazione. Tieni presente che qualsiasi account con tutte le autorizzazioni nel ruolo Amministratore Storage può leggere, scrivere ed eliminare bucket e oggetti di archiviazione nell'intero progetto.
Le autorizzazioni su un bucket di archiviazione si applicano a tutti i repository nel registry.
Ad esempio, qualsiasi utente con autorizzazioni di Visualizzatore oggetti Storage per il bucket per gcr.io/my-project
può leggere le immagini in tutti questi repository:
gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production
Artifact Registry
Artifact Registry ha i propri ruoli per controllare l'accesso. Questi ruoli forniscono una chiara separazione tra i ruoli utente di amministratore e del repository.
Cloud Build dispone delle autorizzazioni nel ruolo Artifact Registry Writer perché deve solo eseguire il push e il pull delle immagini con i repository standard nel dominio pkg.dev
.
Solo gli account che gestiscono i repository devono avere il ruolo Amministratore repository Artifact Registry o Amministratore Artifact Registry.
- Artifact Registry Reader
- Elenca gli elementi e i repository. Scarica gli elementi.
- Artifact Registry Writer
- Elenca gli elementi e i repository. Scarica gli elementi, carica nuove versioni degli elementi e aggiungi o aggiorna i tag.
- Artifact Registry Repository Administrator
- Autorizzazioni di autore di Artifact Registry e autorizzazioni per eliminare elementi e tag.
- Artifact Registry Administrator
- Autorizzazioni e autorizzazioni di amministratore del repository Artifact Registry per creare, aggiornare, eliminare e concedere autorizzazioni ai repository.
Puoi applicare queste autorizzazioni a livello di repository. Ad esempio:
- Concedi l'accesso al team 1 per
us-central1-docker.pkg.dev/my-project/team1
- Concedi l'accesso al team 2 per
us-central1-docker.pkg.dev/my-project/team2
.
Per informazioni dettagliate sulla concessione delle autorizzazioni di Artifact Registry, consulta la documentazione sul controllo dell'accesso.
Creazione ed esecuzione del push delle immagini
Punti chiave:
- Devi creare un repository Docker di Artifact Registry prima di eseguire il push di un'immagine.
- I nomi host di Artifact Registry sono diversi da quelli di Container Registry.
Cloud Build può creare, taggare ed eseguire il push di un'immagine in un unico passaggio.
Con Container Registry, Cloud Build può eseguire il push di un'immagine in un host del registry che non esiste ancora nel Google Cloud progetto. Per questo push iniziale dell'immagine, Cloud Build dispone delle autorizzazioni per aggiungere automaticamente l'host del registry al progetto.
Per adattare un flusso di lavoro di Container Registry:
- Configura i repository prima di eseguire il push delle immagini.
- Aggiorna i percorsi delle immagini nel file di configurazione della build o nei comandi
gcloud builds submit
.
Eseguire la compilazione con un file di configurazione della build
Sostituisci i percorsi di Container Registry per le immagini che crei con il percorso di un repository Artifact Registry esistente.
Il seguente file cloudbuild.yaml
di esempio genera l'immagine
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'
Puoi quindi creare l'immagine con il comando:
gcloud builds submit --config cloudbuild.yaml
Creazione con un Dockerfile
Sostituisci i percorsi di Container Registry per le immagini che crei con il percorso di un repository Artifact Registry esistente.
Il seguente comando di esempio crea l'immagine
us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
con un
Dockerfile
nella directory corrente:
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Eseguire il deployment delle immagini
Punto chiave:
- I nomi host di Artifact Registry sono diversi da quelli di Container Registry.
Per adattare un workflow di Container Registry, aggiorna i percorsi delle immagini nella configurazione e nei comandi di deployment. Le sezioni seguenti mostrano esempi per Cloud Build, Cloud Run e GKE, ma lo stesso approccio si applica a qualsiasi altro servizio che esegue il deployment delle immagini. Google Cloud
Cloud Build
Sostituisci i percorsi di Container Registry per le immagini di cui esegui il deployment con il percorso di un repository Artifact Registry esistente.
Il seguente file cloudbuild.yaml
di esempio esegue il deployment dell'immagine di esempio
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
Sostituisci i percorsi di Container Registry per le immagini di cui esegui il deployment con il percorso di un repository Artifact Registry esistente.
Ad esempio, questo comando esegue il deployment dell'immagine di esempio
us-docker.pkg.dev/cloudrun/container/hello
.
gcloud run deploy my-service --image us-docker.pkg.dev/cloudrun/container/hello
GKE
Sostituisci i percorsi di Container Registry per le immagini che crei con il percorso di un repository Artifact Registry esistente.
I seguenti esempi per Artifact Registry utilizzano l'immagine di esempious-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
.
Creazione di un cluster dalla riga di comando:
kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Specifica di un'immagine in un manifest di 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/google-samples/containers/gke/hello-app:1.0