Modifiche per la creazione e il deployment in Google Cloud

Questo documento illustra le differenze tra Container Registry e Artifact Registry durante la creazione di immagini container con Cloud Build ed eseguirne il deployment in ambienti di runtime Google Cloud, Cloud Run o Google Kubernetes Engine.

In questa guida, i confronti sono incentrati su Artifact Registry standard Artifact Registry, i normali repository indipendenti di Container Registry e di supportare tutte le funzionalità di Artifact Registry. Se il tuo amministratore ha configurato repository con supporto per il dominio gcr.io, le richieste agli host gcr.io vengono reindirizzate automaticamente a un repository Artifact Registry corrispondente 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 dedicata a Container Registry con Cloud Build.

Prima di iniziare

In questo documento si presuppone che tu abbia:

1. Artifact Registry abilitato nel tuo progetto.
2. Hai abilitato l'API Cloud Build e l'API per qualsiasi a un altro servizio Google Cloud che stai utilizzando con Artifact Registry.

Modifiche al flusso di lavoro

Quando utilizzi Cloud Build con Container Registry all'interno dello stesso progetto, il flusso di lavoro sarà simile al seguente:

1. Creare, taggare ed eseguire il push di un'immagine nel repository con Cloud Build. utilizzando un Dockerfile o un file di configurazione della build.

   Nell'esempio seguente viene creata l'immagine my-image, la tagga con tag1 e ne esegue il push all'host gcr.io nel progetto my-project:

   gcloud builds submit --tag gcr.io/my-project/my-image:tag1
   

2. Gli ambienti di runtime di Google Cloud, come Cloud Run e Google Kubernetes Engine, estraggono le immagini dal registry.

   Ad esempio, questo comando esegue il deployment dell'immagine dal passaggio precedente a 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 creazione e il deployment.

• Quando abiliti alcune API Google Cloud, L'API Container Registry viene abilitata automaticamente. Ciò significa che gli utenti hanno accesso implicito a Container Registry nello stesso progetto. Per Ad esempio, gli utenti che possono eseguire build in Cloud Build possono eseguire il push registri e aggiungi host di registry per impostazione predefinita.
• L'account di servizio Cloud Build dispone delle autorizzazioni per creare bucket di archiviazione Cloud Storage. Ciò significa che un account può aggiungere automaticamente host Container Registry a un progetto il primo 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 nell'intero progetto, inclusi i bucket non utilizzati da Container Registry.

In Artifact Registry, c'è una chiara separazione tra amministratori e creare ruoli che modifichino i passaggi nel flusso di lavoro di creazione e deployment. Per adattare flusso di lavoro di Container Registry per Artifact Registry, apporta le seguenti modifiche modifiche. Ogni passaggio rimanda a informazioni aggiuntive sulla modifica del flusso di lavoro.

1. 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 per te.

2. Novità: crea il repository Docker di destinazione se non è presente esistono 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.

3. Modificata: crea, tagga ed esegui il push di un'immagine nel repository con Cloud Build, usando un file Dockerfile o di configurazione di compilazione.

   Il seguente comando di esempio è uguale all'esempio 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
   

4. Modificata: esegui il deployment dell'immagine in un runtime di Google Cloud 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:

• Gli ambienti di runtime Cloud Build o Google Cloud si trovano in un progetto diverso rispetto ad Artifact Registry.
• Utilizzi account di servizio personalizzati per i servizi Google Cloud come Cloud Build o GKE al posto del servizio predefinito .
• Hai concesso le autorizzazioni ad altri account utente o di servizio.

Attivazione dell'API

Punti chiave:

• Devi abilitare l'API Artifact Registry oltre all'API per altri servizi Google Cloud come Cloud Build, Cloud Run e GKE.

Il seguente confronto descrive l'attivazione dell'API per ciascun servizio:

Container Registry

Quando abiliti le seguenti API Google Cloud, Container Registry L'API viene abilitata automaticamente anche:

• Ambiente flessibile di App Engine
• Cloud Build
• Funzioni Cloud Run
• Cloud Run
• Scansione dei container o scansione on demand in Artifact Analysis
• Google Kubernetes Engine

Con le autorizzazioni predefinite, gli utenti che possono eseguire build in Cloud Build, analizza i container con Artifact Analysis o esegui il deployment dei container I runtime di Google Cloud hanno implicitamente accesso alle immagini in 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 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 un'immagine.
• Container Registry archivia tutte le immagini in un'unica multiregione nello stesso Cloud Storage. In Artifact Registry, puoi creare più nella stessa regione o a più regioni con criteri di accesso separati.

Il confronto seguente descrive la configurazione del repository in ciascun servizio:

Container Registry

In Container Registry puoi aggiungere fino a quattro host di registry al tuo progetto. Per aggiungere un host del registry, esegui il push della prima immagine.

1. Per aggiungere al tuo progetto un registro, ad esempio gcr.io, devi disporre di un account con il Il ruolo Amministratore Storage a livello di progetto esegue il push di un'immagine iniziale.

   Ad esempio, se l'host gcr.io non esiste nel progetto my-project, push dell'immagine gcr.io/my-project/my-image:1.0 trigger segui questi passaggi:

   1. Aggiungi l'host gcr.io al progetto
   2. Crea un bucket di archiviazione per gcr.io nel progetto.
   3. Archivia l'immagine come gcr.io/my-project/my-image:1.0

2. Al termine del push iniziale, potrai concedere le autorizzazioni al bucket Cloud Storage per gli altri utenti.

Per impostazione predefinita, Cloud Build include autorizzazioni per creare un bucket di archiviazione, quindi il push dell'immagine iniziale e quelli successivi sono indistinguibili.

All'interno di un progetto, un host del registry archivia tutte le immagini nello stesso spazio di archiviazione di sincronizzare la directory di una VM con un bucket. Nel seguente esempio, il progetto my-project ha due immagini chiamate web-app nel registry gcr.io. Uno è 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 uno standard repository sul dominio Artifact Registry pkg.dev.

un account con il repository Artifact Registry Il ruolo di amministratore deve creare il repository prima di eseguire il push delle immagini. Puoi quindi concedere autorizzazioni ad altri utenti nel repository.

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

I seguenti esempi mostrano situazioni in cui il push di un'immagine a un il repository mancante non riesce.

• Push di un'immagine a us-central1-docker.pkg.dev/my-project/team1 se us-central1-docker.pkg.dev/my-project/team1 non esiste.
• Push di un'immagine a us-central1-docker.pkg.dev/my-project/team2 durante us-central1-docker.pkg.dev/my-project/team1 esiste, ma us-central1-docker.pkg.dev/my-project/team2 non esiste.

Concessione di autorizzazioni

Punti chiave:

• I servizi Google Cloud hanno accesso equivalente in lettura o scrittura a entrambi Container Registry e Artifact Registry. Tuttavia, il valore predefinito L'account di servizio Cloud Build non può creare repository standard nel dominio pkg.dev.
• Concedi i ruoli Artifact Registry appropriati ad altri account che per accedere 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 confronto seguente descrive le autorizzazioni per ciascun servizio:

Container Registry

Container Registry utilizza i ruoli di 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 (lettura) delle immagini da host del registry esistenti nel progetto.

Writer bucket legacy Storage a livello di bucket di archiviazione

Esegui il push (scrittura) e il pull (lettura) di immagini per gli host del 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 all'host.

Dopo il push iniziale dell'immagine in un registro, concedi i ruoli di Cloud Storage a 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 registro. Ad esempio, qualsiasi utente con autorizzazioni di Visualizzatore oggetti Storage nella 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 dispone di ruoli propri per controllare l'accesso. Questi ruoli che assicurano una chiara separazione tra i ruoli utente di amministratore e 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 repository dovrebbero disporre di Artifact Registry Ruolo Amministratore repository o Amministratore Artifact Registry.

Artifact Registry Reader

Elenca gli elementi e i repository. Scarica gli artefatti.

Artifact Registry Writer

Elenca artefatti e repository. Scarica elementi, carica nuovo elemento e aggiungere o aggiornare i tag.

Artifact Registry Repository Administrator

Autorizzazioni e autorizzazioni per Writer di Artifact Registry artefatti e tag.

Artifact Registry Administrator

Autorizzazioni e autorizzazioni dell'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 maggiori dettagli sulla concessione delle autorizzazioni Artifact Registry, consulta le documentazione sul controllo dell'accesso.

Creazione e push delle immagini

Punti chiave:

• Devi creare un repository Docker di Artifact Registry prima di eseguire il push un'immagine.
• I nomi host di Artifact Registry sono diversi da quelli di Container Registry e nomi host.

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 progetto Google Cloud. Per questo push iniziale dell'immagine, Cloud Build dispone delle autorizzazioni aggiungere l'host del registry al progetto.

Per adattare un flusso di lavoro di Container Registry:

1. Configura i repository prima di eseguire il push delle immagini.
2. Aggiorna i percorsi delle immagini nel file di configurazione della build o nel tuo file gcloud builds submit tramite comandi SQL.

Eseguire la compilazione con un file di configurazione della build

Sostituisci i percorsi di Container Registry per le immagini create con a un repository Artifact Registry esistente.

Il file cloudbuild.yaml di esempio seguente crea 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 create con a un repository Artifact Registry esistente.

Il comando di esempio seguente crea l'immagine us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1 con un Dockerfile nella directory attuale:

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

Deployment delle immagini in corso...

Punto chiave:

• I nomi host di Artifact Registry sono diversi da quelli di Container Registry e nomi host.

Per adattare un flusso di lavoro di Container Registry, aggiorna i percorsi delle immagini nel deployment di configurazione e deployment. Le sezioni seguenti mostrano esempi per Cloud Build, Cloud Run e GKE, ma lo stesso approccio si applica a qualsiasi altro servizio Google Cloud che esegue il deployment di immagini.

Cloud Build

Sostituisci i percorsi di Container Registry per le immagini di cui esegui il deployment con a 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 a 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 create con a un repository Artifact Registry esistente.

I seguenti esempi di Artifact Registry utilizzano l'immagine di esempio us-docker.pkg.dev/artifact-registry-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/artifact-registry-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/artifact-registry-samples/containers/gke/hello-app:1.0