Concetti sui container

Artifact Registry ti consente di archiviare e organizzare immagini container e altri artefatti nei repository in modo da poter gestire ed eseguire il deployment dei workload in vari ambienti. Puoi utilizzare livelli, tag e digest del manifest dell'immagine per controllare il controllo delle versioni delle immagini e gestire le implementazioni.

Gli esempi di Artifact Registry in questa pagina si riferiscono principalmente ai repository in formato Docker. Per ulteriori informazioni, consulta Formati supportati e la panoramica del repository.

Registri

Un registro archivia e distribuisce immagini container e artefatti organizzati per nome all'interno dei repository. Un registro può contenere un singolo repository o più repository e può essere pubblico o privato.

Servizi di registro come Docker Hub e Artifact Registry forniscono opzioni per creare repository pubblici o privati. Quando estrai immagini pubbliche, è importante comprendere i possibili problemi di sicurezza. Per saperne di più sul monitoraggio delle vulnerabilità e sulla riduzione dell'impronta delle dipendenze, leggi l'articolo sulla gestione delle dipendenze.

I registri sono organizzati in repository che archiviano singole immagini container. Artifact Registry ti consente di creare più repository in un unico progetto e associare una posizione regionale o multiregionale specifica a ogni repository. I repository correlati possono essere raggruppati per etichette.

Repository Artifact Registry e gestione delle immagini

Nei repository in formato Docker di Artifact Registry, puoi archiviare più immagini container con nomi diversi nello stesso repository. Ogni versione di un'immagine è identificata dal relativo digest e può essere associata a un tag. I tag possono essere modificabili o immutabili. Per saperne di più sulle versioni e sui tag delle immagini container, consulta Versioni delle immagini container.

Artifact Registry in genere fa riferimento a parti del percorso di un'immagine per identificare il progetto, la posizione regionale o multiregionale e il nome dell'immagine insieme al tag o al digest del manifest per identificare la versione corretta.

Ad esempio:

docker push us-west1-docker.pkg.dev/PROJECT/quickstart-docker-repo/quickstart-image:tag1

  • us-west1 è la posizione del repository
  • docker.pkg.dev è il nome host per i repository in formato Docker.
  • PROJECT è lo spazio dei nomi creato dal tuo Google Cloud ID progetto.
  • quickstart-docker-repo è lo spazio dei nomi del progetto in cui memorizzi le immagini. In Artifact Registry, questa parte del percorso è chiamata repository.
  • quickstart-image è il nome di tutte le versioni di quickstart-image e viene spesso chiamato l'immagine.
  • tag1 è il tag che specifica la versione dell'immagine.

Immagini

Sia gli artefatti che le immagini possono essere archiviati in Artifact Registry. Un artefatto può essere qualsiasi cosa: un file di testo, un'immagine Docker o un grafico Helm, mentre un' immagine in genere si riferisce a un'immagine container. Le immagini container sono pacchetti di software che contengono tutti gli elementi necessari per l'esecuzione in qualsiasi ambiente. Per saperne di più, leggi Che cosa sono i container.

Le immagini vengono inserite o caricate nei repository e estratte o scaricate dai repository. Per specificare l'immagine e la versione corrette, devono essere specificati il registro e l'artefatto univoci.

Per ulteriori informazioni sui nomi di repository e immagini in Artifact Registry, vedi Nomi di repository e immagini.

Base

Le immagini container archiviate nei repository vengono create in modo incrementale utilizzando i livelli. Immagini diverse possono utilizzare alcuni degli stessi livelli. I livelli vengono definiti in modi diversi a seconda del tipo di immagine. Ad esempio, ogni istruzione in un Dockerfile corrisponde a un livello nell'immagine Docker. All'interno di un registro, le immagini con livelli comuni condividono questi livelli, aumentando l'efficienza dello spazio di archiviazione. Per motivi di sicurezza, i livelli non vengono condivisi tra registri diversi.

Quando elimini un'immagine container, i livelli non vengono eliminati immediatamente. I livelli a cui non fanno riferimento le immagini nel registro vengono eliminati ogni giorno.

Tag

Gli utenti aggiungono tag quando eseguono il push o il pull di un'immagine in un repository per specificare la versione di un'immagine. Un'immagine può avere uno o più tag oppure nessun tag. Se utilizzi tag modificabili ed esegui il push di un'immagine due volte con lo stesso tag, il tag viene rimosso dalla prima immagine e spostato nella seconda, lasciando la prima immagine senza tag. L'immagine senza tag è ancora accessibile utilizzando i relativi digest del manifest.

Se utilizzi tag immutabili, le seguenti azioni non sono consentite:

  • Eliminare un'immagine taggata. L'eliminazione delle immagini senza tag è ancora consentita.
  • Rimuovere un tag da un'immagine.
  • Esegui il push di un'immagine con un tag già utilizzato da un'altra versione dell'immagine nel repository.

Il tag latest è un tag speciale aggiunto quando le immagini vengono inviate senza un tag.

Ad esempio:

docker push us-west1-docker.pkg.dev/my-project/my-repo/hello-app

sposta l'immagine su hello-app:latest

docker pull us-west1-docker.pkg.dev/my-project/my-repo/hello-app

estrae l'immagine hello-app:latest.

È importante notare che quando un'immagine viene inviata a un repository con un tag diverso da latest, il tag latest non viene aggiunto, pertanto è possibile che l'immagine latest sia in ritardo rispetto alle modifiche più recenti. Ti consigliamo di utilizzare tag diversi da latest per le uscite.

Manifest

I manifest delle immagini identificano e specificano in modo univoco i livelli all'interno di ogni immagine. I manifest vengono identificati da hash SHA-256 unici chiamati digest dei manifest. I digest manifest sono più affidabili e sicuri dei tag perché nei repository con tag modificabili, è possibile eseguire il push di più versioni della stessa immagine nello stesso tag, lasciando alcune immagini senza tag, mentre ogni immagine è specificata in modo univoco dal relativo digest manifest.

Se utilizzi strumenti per scansionare o analizzare le immagini, i risultati di questi strumenti sono validi solo per l'immagine scansionata. Per assicurarti di eseguire il deployment dell'immagine scansionata, non puoi fare affidamento sul tag perché l'immagine a cui fa riferimento il tag potrebbe cambiare.

Per saperne di più su tagging e manifest specifici di Artifact Registry, leggi Gestione delle immagini e Utilizzo delle immagini container.

Pre-riscaldamento delle immagini

Per le applicazioni sensibili alla latenza che utilizzano lo streaming di immagini, l'attesa del pull di un'immagine per la prima volta su un nuovo nodo o una nuova istanza, spesso chiamato "avvio a freddo", può introdurre ritardi indesiderati. Il pre-riscaldamento consente di avviare esplicitamente il download delle immagini nella cache di Image Streaming prima che vengano richieste. Questa procedura consente di garantire che l'immagine sia disponibile per la distribuzione rapida quando il cluster GKE la richiede.

Per eseguire il prewarm delle immagini, utilizza l'API Artifact Registry. Per istruzioni, vedi Riduci la latenza con il pre-riscaldamento delle immagini.

Passaggi successivi