Panoramica dei repository virtuali

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

Le quote e i limiti di Artifact Registry si applicano ai repository virtuali.

Come funzionano i repository virtuali

I repository virtuali fungono da singolo punto di accesso per scaricare, installare o eseguire il deployment di 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 solo 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 sul repository scelto da Artifact Registry quando un artefatto richiesto si trova in più repository upstream.

Alcuni strumenti, come lo strumento pip di Python, 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 i repository remoti e virtuali insieme per mitigare questo rischio:

  1. Crea un repository remoto come proxy per il repository pubblico.
  2. Crea un repository standard per i 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 in modo che leggano 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 Gestione delle dipendenze.

In che modo i repository virtuali selezionano un repository upstream

Ogni repository upstream deve avere una priorità configurata. La priorità è un numero intero che funge da ponderazione, non da ranking. Ciò significa che i repository con un valore di priorità più alto hanno la priorità rispetto ai repository con valori di priorità più bassi.

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

  • Viene data la priorità al repository con il valore più alto. Ad esempio, un valore di 10 viene trattato come priorità più alta 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.

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 pip di Python per cercare PyPI e un repository virtuale, il pacchetto potrebbe essere scaricato direttamente da PyPI perché pip sceglierà sempre la versione più recente di un pacchetto, indipendentemente dal repository di provenienza. Se pip è configurato per cercare solo il 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 di Artifact Registry:

Pacchetti di linguaggio:

Pacchetti del sistema operativo:

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

Limitazioni

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

  • 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 la policy di versione su snapshot o release.

  • I repository 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 alcuni secondi. Per i repository più grandi, la reindicizzazione potrebbe richiedere diversi minuti o più. Al termine della reindicizzazione, la modifica del repository è visibile ai client Apt e Yum.

Altre modalità di repository

Le altre modalità di repository sono le seguenti:

  • Standard: la modalità di repository predefinita. 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 un'origine upstream memorizzando nella cache i pacchetti in Artifact Registry dopo che sono stati scaricati dall'origine upstream per la prima volta. 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 effettuate all'origine upstream. I repository connettore sono utili se richiedi la completa controllabilità dell'origine upstream o se hai policy che impediscono la memorizzazione nella cache degli artefatti.

Passaggi successivi