Concetti sui container

Questo documento introduce i concetti chiave relativi alle immagini container, tra cui registri, repository e artefatti. Sono incluse anche alcune informazioni di base su come questi concetti si applicano ad Artifact Registry e Container Registry.

Gli esempi di Artifact Registry in questa pagina si riferiscono principalmente ai repository in formato Docker e gcr.io. 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.

I servizi di registro come Docker Hub e Artifact Registry offrono opzioni per creare repository pubblici o privati. Quando esegui il pull di immagini pubbliche, è importante comprendere i possibili problemi di sicurezza. Per ulteriori informazioni sul monitoraggio delle vulnerabilità e sulla riduzione dell'impronta delle dipendenze, consulta Gestione delle dipendenze.

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

Repository di 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 dell'immagine e può essere associata a un tag. I tag possono essere mutabili o immutabili. Per ulteriori informazioni sulle versioni e sui tag delle immagini container, consulta Versioni delle immagini container.

In genere, Artifact Registry 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 dall'Google Cloud ID progetto.
  • quickstart-docker-repo è lo spazio dei nomi del progetto in cui archiviare 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.

Google Immagini

Sia gli artefatti sia 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 ulteriori informazioni, consulta 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, è necessario specificare il registro e l'artefatto univoci.

Per ulteriori informazioni sui nomi di repository e immagini in Artifact Registry, consulta 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 sono 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 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 inseriscono o estraggono 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 mutabili e inserisci 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 suoi digest del manifest.

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

  • Eliminare un'immagine con tag. L'eliminazione delle immagini senza tag è ancora consentita.
  • Rimuovere un tag da un'immagine.
  • Inserire 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 inserite senza tag.

Ad esempio:

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

inserisce l'immagine in 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 inserita in un repository con un tag diverso da latest, il tag latest non viene aggiunto, pertanto è possibile che l'immagine latest sia precedente alle modifiche più recenti. Ti consigliamo di utilizzare tag diversi da latest per le release.

Manifest

I manifest delle immagini identificano e specificano in modo univoco i livelli all'interno di ogni immagine. I manifest sono identificati da hash SHA-256 univoci chiamati digest del manifest. I digest del manifest sono più affidabili e sicuri dei tag perché nei repository con tag mutabili è possibile inserire più versioni della stessa immagine nello stesso tag, lasciando alcune immagini senza tag, mentre ogni immagine è specificata in modo univoco dal relativo digest del 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ù sui tag e sui manifest specifici di Artifact Registry, consulta Gestire le immagini e Utilizzare le 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 chiamata "avvio a freddo", può introdurre ritardi indesiderati. Il pre-riscaldamento ti consente di avviare esplicitamente il download delle immagini nella cache di Streaming di immagini prima che vengano richieste. Questo processo contribuisce a garantire che l'immagine sia disponibile per la consegna rapida quando il cluster GKE la richiede.

Per pre-riscaldare le immagini, utilizza l'API Artifact Registry. Per le istruzioni, consulta Ridurre la latenza con il pre-riscaldamento delle immagini.

Passaggi successivi