Questa pagina è stata tradotta dall'API Cloud Translation.

gcr.io ospitato su Artifact Registry per impostazione predefinita

Scopri come configurare gcr.io repository in Artifact Registry e scopri le differenze tra le autorizzazioni Artifact Registry e Container Registry e il bucket di archiviazione configurazione.

I passaggi manuali descritti in questo documento possono essere completati utilizzando di migrazione automatica. Se vuoi utilizzare i modelli strumento di migrazione per eseguire la transizione dei tuoi progetti con utilizzo attivo di Container Registry ai repository standard Artifact Registry o a gcr.io repository, consulta Automatizzare la migrazione ad Artifact Registry.

Ritiro di Container Registry

Progetti Google Cloud che non hanno mai utilizzato Container Registry Dal 15 maggio 2024 supporterà solo l'hosting e la gestione delle immagini in Artifact Registry. Questa modifica interessa:

Progetti appena creati.
Progetti esistenti per i quali non hai eseguito il push di un'immagine su Container Registry.

Organizzazioni che non hanno mai utilizzato Container Registry L'8 gennaio 2024 avrà tutti i nuovi repository gcr.io ospitati su Artifact Registry per impostazione predefinita.

Quando abiliti l'API Artifact Registry in questi progetti, Artifact Registry gestire automaticamente la creazione di gcr.io repository in Artifact Registry reindirizzi le richieste al dominio gcr.io all'elemento Artifact Registry appropriato repository Git. A differenza del supporto per i domini gcr.io esistente nei progetti con l'utilizzo attivo di Container Registry, il reindirizzamento ad Artifact Registry sarà automatico.

Container Registry rimarrà disponibile nei progetti in cui uno degli elementi seguenti azioni eseguite prima del 15 maggio 2024:

Hai abilitato l'API Container Registry nel progetto.
Hai eseguito il push di un'immagine a un host del registro nel progetto.

Per prepararti al cambiamento imminente, ti consigliamo di:

Segui le istruzioni in questo documento per configurare i progetti in cui non stanno utilizzando Container Registry in modo da essere pronti per la gestione automatica di gcr.io richieste quando vengono applicate le modifiche.
Testa il supporto del dominio gcr.io per verificare che l'automazione esistente continui a funzionare.

gcr.io repository ospitati su Artifact Registry vengono creati nello stesso in più regioni supportate da Container Registry. Se vuoi archiviare le tue immagini in altre regioni, devi eseguire la transizione ai repository standard nel dominio pkg.dev.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare i repository "gcr.io", chiedi all'amministratore di concederti seguenti ruoli IAM:

Per creare repository Artifact Registry e concedere l'accesso a singoli repository: Amministratore Artifact Registry (roles/artifactregistry.admin) del progetto
Per visualizzare e gestire la configurazione esistente di Container Registry applicata ai bucket di archiviazione di Cloud Storage: Storage Admin (roles/storage.admin) del progetto
Per concedere l'accesso al repository a livello di progetto: Amministratore IAM progetto (roles/resourcemanager.projectIamAdmin) o un ruolo che include autorizzazioni equivalenti come Amministratore cartelle (roles/resourcemanager.folderAdmin) o Amministratore organizzazione (roles/resourcemanager.organizationAdmin) a livello di progetto, cartella o organizzazione
Per elencare i servizi abilitati in un'organizzazione: Cloud Asset Viewer (roles/cloudasset.viewer) dell'organizzazione

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite la ruoli o altri ruoli predefiniti ruoli.

Prima di iniziare

Puoi elencare i progetti in cui è archiviata almeno un'immagine in Container Registry. Puoi quindi concentrarti sulla configurazione di altri progetti per l'hosting delle richieste gcr.io in Artifact Registry utilizzando le istruzioni in questo documento.

Esegui questo comando per individuare gli utilizzi di Container Registry nel dell'organizzazione Google Cloud.

  gcloud container images list-gcr-usage \
      --organization=ORGANIZATION

Sostituisci ORGANIZATION con il tuo Google Cloud ID organizzazione.

Puoi anche elencare l'utilizzo di Container Registry per il tuo progetto o la tua cartella. Per maggiori informazioni informazioni su come trovare l'utilizzo di Container Registry, consulta Controlla l'utilizzo di Container Registry.

Abilita l'API

Abilita l'API Artifact Registry in modo che le richieste al dominio gcr.io vengano gestita automaticamente da Artifact Registry quando viene applicato l'hosting automatico di gcr.io.

Esegui questo comando:

gcloud services enable \
    artifactregistry.googleapis.com

Se normalmente posizioni l'API Container Registry in una Perimetro di servizio Controlli di servizio VPC, e assicurati di posizionare anche l'API Artifact Registry nel perimetro. Consulta Protezione dei repository in un perimetro di servizio per istruzioni.

Concedi autorizzazioni ai repository

Container Registry utilizza i ruoli di Cloud Storage per controllare l'accesso. Artifact Registry dispone del proprio IAM roles. Questi ruoli separano i ruoli di lettura, scrittura e amministrazione dei repository in modo più chiaro e Container Registry.

per mappare rapidamente le autorizzazioni esistenti concesse sui bucket di archiviazione ai suggerimenti Per i ruoli di Artifact Registry, utilizza lo strumento di mappatura dei ruoli.

In alternativa, puoi visualizzare un elenco di entità con accesso allo spazio di archiviazione utilizzando la console Google Cloud.

Nella console Google Cloud, vai alla pagina Bucket di Cloud Storage.

Vai a Bucket
Fai clic sul bucket di archiviazione per l'host del registro che vuoi visualizzare. Nei nomi dei bucket, PROJECT-ID è il tuo Google Cloud ID progetto.
- gcr.io: artifacts.PROJECT-ID.appspot.com
- asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
- eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
- us.gcr.io: us.artifacts.PROJECT-ID.appspot.com
Fai clic sulla scheda Autorizzazioni.
Nella scheda Autorizzazioni, fai clic sulla scheda secondaria Visualizza per ruolo.
Espandi un ruolo per visualizzare le entità che lo hanno.

L'elenco include i ruoli IAM concessi direttamente nel bucket e i ruoli ereditati dal progetto padre. In base al ruolo, puoi scegliere il ruolo Artifact Registry più appropriato da concedere.

Cloud Storage e ruoli di base

Concedi agli utenti e agli account di servizio che attualmente accedono a Container Registry con accesso ai repository Artifact Registry. Per Cloud Storage ruoli ereditati dal progetto padre, devi verificare che l'entità che attualmente utilizza Container Registry. Alcune entità potrebbero accedere solo ad altri bucket Cloud Storage non correlati a Container Registry.

I ruoli di base Proprietario, Editor e Visualizzatore esistenti IAM ha accesso limitato ai bucket di archiviazione. Non danno intrinsecamente tutto l'accesso a Cloud Storage che implicano il nome e forniscono autorizzazioni aggiuntive per altri servizi Google Cloud. Verifica quali utenti e account di servizio richiedono l'accesso ad Artifact Registry e utilizza la tabella di mappatura dei ruoli per facilitare concedi i ruoli corretti se l'accesso ad Artifact Registry è appropriato.

La tabella seguente mappa i ruoli di Artifact Registry in base alle autorizzazioni concesse ruoli Cloud Storage predefiniti per l'accesso a Container Registry.

Accesso richiesto	Ruolo attuale	Ruolo Artifact Registry	Dove concedere il ruolo
Esegui il pull delle immagini solo (sola lettura)	Visualizzatore oggetti Storage (`roles/storage.objectViewer`)	Lettore Artifact Registry (`roles/artifactregistry.reader)`	Repository Artifact Registry o progetto Google Cloud
Esegui il push e il pull delle immagini (lettura e scrittura) Elimina immagini	Writer bucket legacy Storage (`roles/storage.legacyBucketWriter`)	Amministratore repository Artifact Registry (`roles/artifactregistry.repoAdmin)`	Repository Artifact Registry o progetto Google Cloud
Crea un repository gcr.io in Artifact Registry la prima volta che viene un'immagine a un nome host gcr.io in un progetto.	Amministratore Storage (`roles/storage.admin`)	Amministratore repository Create-on-push Artifact Registry `(roles/artifactregistry.createOnPushRepoAdmin)`	Progetto Google Cloud
Crea, gestisci ed elimina repository	Amministratore Storage (`roles/storage.admin`)	Amministratore Artifact Registry `(roles/artifactregistry.Admin)`	Progetto Google Cloud

Ruoli dell'agente di servizio ereditati dal progetto

Gli account di servizio predefiniti per i servizi Google Cloud hanno le proprie ruoli concessi a livello di progetto. Ad esempio, l'agente di servizio Cloud Run ha il ruolo di agente di servizio Cloud Run.

Nella maggior parte dei casi, questi ruoli dell'agente di servizio contengono valori predefiniti equivalenti per Container Registry e Artifact Registry e tu non deve apportare ulteriori modifiche se è in esecuzione Artifact Registry nello stesso progetto del tuo Container Registry esistente completamente gestito di Google Cloud.

Consulta le Riferimento del ruolo di agente di servizio per i dettagli sulle autorizzazioni nei ruoli degli agenti di servizio.

Ruoli personalizzati

Utilizza la tabella della mappatura dei ruoli per decidere meglio il ruolo da concedere a utenti o account di servizio in base al livello di accesso di cui hanno bisogno.

Per istruzioni sulla concessione dei ruoli di Artifact Registry, consulta Configura ruoli e autorizzazioni.

Configurazione del bucket di archiviazione

Quando crei un repository in Artifact Registry, Artifact Registry non crea ai bucket Cloud Storage corrispondenti nel tuo progetto. Se disponi dell'automazione per Container Registry che interagisce direttamente con i bucket di archiviazione, devi aggiornare per apportare le modifiche corrispondenti al repository Artifact Registry.

Ad esempio, se concedi in modo programmatico le autorizzazioni di Cloud Storage bucket di archiviazione per Container Registry, devi aggiornare l'automazione per concedere Autorizzazioni Artifact Registry nei repository Artifact Registry che ospitano immagini per il dominio gcr.io.

In Artifact Registry, imposti il metodo di crittografia per i dati archiviati in un repository di archiviazione di un bucket Cloud Storage. L'hosting gcr.io automatico su Artifact Registry crea gcr.io repository criptati con chiavi di proprietà e gestite da Google. Se vuoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK), devi creare gcr.io repository autonomamente e specifica CMEK come metodo di crittografia quando le crei tu.

Per creare manualmente un repository gcr.io:

Se utilizzi CMEK, crea la chiave che utilizzerai con questo repository e concedere le autorizzazioni per utilizzare la chiave. Consulta Attivazione delle chiavi di crittografia gestite dal cliente
Aggiungi il repository.
Console
1. Apri la pagina Repository nella console Google Cloud.
  
  Apri la pagina Repository
2. Fai clic su Crea repository.
3. Specifica il nome del repository.
  
  Nome host Container Registry Nome repository Artifact Registry
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
4. Specifica Docker come formato del repository.
5. In Tipo di località, specifica la località multiregionale del repository:
  
  Nome host Container Registry Posizione del repository Artifact Registry
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
6. Aggiungi una descrizione per il repository. Non includere dati sensibili, poiché le descrizioni del repository non sono criptate.
7. Nella sezione Crittografia, scegli il meccanismo di crittografia per nel repository.
  - Chiave gestita da Google: cripta i contenuti del repository con una Chiave di proprietà di Google e gestita da Google.
  - Chiave gestita dal cliente: cripta i contenuti del repository con una chiave che puoi controllare tramite Cloud Key Management Service. Per istruzioni sulla configurazione della chiave, consulta Configurazione di CMEK per i repository.
8. Fai clic su Crea.
gcloud
Esegui questo comando per creare un nuovo repository.
```
gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description=DESCRIPTION \
    --kms-key=KMS-KEY
```
Sostituisci i seguenti valori:
- REPOSITORY è il nome del repository.
  
  Nome host Container Registry Nome repository Artifact Registry
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
- LOCATION indica la località multiregionale del repository:
  
  Nome host Container Registry Posizione del repository Artifact Registry
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
- DESCRIPTION è una descrizione del repository. Azioni sconsigliate includere dati sensibili, poiché le descrizioni dei repository non sono criptate.
- KMS-KEY è il percorso completo della crittografia di Cloud KMS se utilizzi una chiave di crittografia gestita dal cliente per criptare i contenuti del repository. Il percorso ha il seguente formato:
```
projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
```
  Sostituisci i seguenti valori:
  - KMS-PROJECT è il progetto in cui è archiviata la chiave.
  - KMS-LOCATION è la posizione della chiave.
  - KEY-RING è il nome del keyring.
  - KEY è il nome della chiave.
Puoi confermare che il repository è stato creato elencando i tuoi repository con il seguente comando:
```
gcloud artifacts repositories list
```

Nome host Container Registry	Nome repository Artifact Registry
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

Nome host Container Registry	Posizione del repository Artifact Registry
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

Nome host Container Registry	Nome repository Artifact Registry
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

Nome host Container Registry	Posizione del repository Artifact Registry
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

Passaggi successivi

Configura l'assistenza per i domini gcr.io in un progetto di test per verificare che l'automazione e l'integrazione come Cloud Build, Google Kubernetes Engine o Cloud Functions funzionano come previsto.