Panoramica dei repository virtuali

Questo documento fornisce una panoramica dei repository virtuali. Per istruzioni su come creare un repository virtuale, consulta Creare repository virtuali.

A questi repository si applicano le quote e i limiti di Artifact Registry.

Come funzionano i repository virtuali

I repository virtuali fungono da unico punto di accesso per scaricare, installare o implementare artefatti nello stesso formato da uno o più repository upstream. Un repository upstream può essere un repository standard o remoto di Artifact Registry.

Casi d'uso e vantaggi

Configurazione client più semplice

Per le attività che richiedono solo l'accesso in lettura ai repository, devi configurare un singolo repository Artifact Registry per accedere agli artefatti archiviati in più repository upstream.

Ad esempio:

  • Un repository virtuale per i pacchetti Maven può pubblicare pacchetti Java privati da un repository standard di Artifact Registry e pacchetti Java pubblici da un repository remoto che memorizza nella cache i pacchetti pubblici di Maven Central.
  • Un repository virtuale può pubblicare pacchetti Python privati da più repository standard upstream di proprietà di team diversi. Ogni team ha accesso in scrittura al proprio repository upstream, ma scarica i pacchetti di altri team utilizzando il repository virtuale.
Risoluzione delle dipendenze più sicura

Puoi assegnare una priorità ai repository upstream per avere un maggiore controllo su quale repository sceglie Artifact Registry quando un artefatto richiesto si trova in più di un repository upstream.

Alcuni strumenti, come lo strumento Python pip, non forniscono un modo per controllare l'ordine di ricerca quando nel client è configurato un mix di repository privati e pubblici. Questo tipo di configurazione è vulnerabile a un attacco di confusione delle dipendenze, in cui qualcuno carica una nuova versione di un pacchetto con codice dannoso in un repository pubblico per indurre i client a scegliere la versione dannosa.

Puoi utilizzare insieme repository remoti e virtuali per mitigare questo rischio:

  1. Crea un repository remoto come proxy per il repository pubblico.
  2. Crea un repository standard per i tuoi pacchetti privati.
  3. Crea un repository virtuale configurato per dare la priorità al repository standard se una versione dello stesso pacchetto esiste in entrambi i repository.
  4. Configura i gestori di pacchetti e altri strumenti per leggere solo dal repository virtuale, in modo che la logica del client non sia coinvolta nella selezione del repository.

Per scoprire altre best practice per la gestione delle dipendenze, consulta la sezione Gestione delle dipendenze.

Come i repository virtuali selezionano un repository upstream

Ogni repository upstream deve avere una priorità configurata. La priorità è un numero intero che funge da peso, non da ranking. Ciò significa che i repository con un valore di priorità numerico più elevato hanno la precedenza sui repository con valori di priorità inferiori.

Quando richiedi un artefatto presente in più repository upstream, Artifact Registry utilizza la seguente logica di assegnazione delle priorità:

  • Viene data la priorità al repository con il valore più alto. Ad esempio, un valore di 10 viene considerato di priorità superiore rispetto a un valore di 1.
  • Se più repository upstream hanno la stessa priorità, l'artefatto può essere pubblicato da uno qualsiasi di questi repository.

Ti consigliamo inoltre di includere la versione dell'artefatto nella richiesta. In questo modo, il client restituisce il repository upstream con la priorità più alta che contiene la versione dell'artefatto richiesta. Se non specifichi la versione dell'artefatto, il client potrebbe restituire l'ultima versione dell'artefatto, indipendentemente dalla priorità del repository.

Quando configuri direttamente un client per cercare un repository virtuale e repository aggiuntivi, il client potrebbe comunque scaricare artefatti da repository esterni ad Artifact Registry.Ad esempio, se configuri lo strumento Python pip per cercare PyPI e un repository virtuale, il pacchetto potrebbe essere scaricato direttamente da PyPI perché pip sceglierà sempre l'ultima versione di un pacchetto, indipendentemente dal repository di provenienza. Se pip è configurato per cercare solo nel repository virtuale, puoi controllare la priorità di tutti i repository upstream, incluso un repository remoto upstream che funge da proxy per PyPI.

Formati di repository supportati

Puoi creare repository virtuali per i seguenti formati di repository Artifact Registry:

Pacchetti di lingua:

Pacchetti del sistema operativo:

Se non hai mai utilizzato Artifact Registry, puoi utilizzare le guide rapide per scoprire come configurare repository standard per questi formati.

Limitazioni

Oltre alle quote e alle limitazioni di Artifact Registry, i repository virtuali presentano le seguenti limitazioni:

  • Poiché i repository virtuali non archiviano dati, appariranno vuoti quando esegui gcloud artifacts docker images list e quando visualizzi il repository nella console Google Cloud .
  • I repository upstream standard di Artifact Registry devono trovarsi nella stessa regione o multiregione del repository virtuale, ma possono trovarsi in progetti Google Cloud diversi.

  • I repository virtuali Maven non consentono di impostare il criterio di versione su snapshot o release.

  • Gli upstream Apt e Yum devono essere repository standard di Artifact Registry.

  • I repository standard Apt e Yum aggiornano l'indice dei pacchetti in modo asincrono dopo l'importazione, il caricamento o l'eliminazione di un pacchetto. Per i repository di piccole dimensioni, la rigenerazione dell'indice può richiedere diversi secondi. Per i repository più grandi, la reindicizzazione potrebbe richiedere diversi minuti o più. Al termine della reindicizzazione, la modifica al repository è visibile ai client Apt e Yum.

Altre modalità del repository

Le altre modalità del repository sono le seguenti:

  • Standard: la modalità predefinita del repository. Carichi o pubblichi artefatti come pacchetti privati direttamente nei repository standard. Sebbene tu possa scaricare direttamente dai singoli repository standard, l'accesso a gruppi di repository con un repository virtuale semplifica la configurazione degli strumenti.
  • Remoto: un repository che funge da proxy per una sorgente upstream memorizzando nella cache i pacchetti in Artifact Registry dopo il primo download dalla sorgente upstream. La volta successiva che richiedi la stessa versione del pacchetto, Artifact Registry fornisce la copia memorizzata nella cache.
  • Connettore (anteprima): un repository che funge da proxy per un'origine upstream, ma non memorizza nella cache gli artefatti in Artifact Registry. Al contrario, tutte le richieste vengono inviate all'origine upstream. I repository dei connettori sono utili se richiedi la completa controllabilità della tua origine upstream o se hai policy che impediscono la memorizzazione nella cache degli artefatti.

Passaggi successivi