Questo documento fornisce una panoramica dei repository remoti. Per istruzioni su come creare un repository remoto, consulta Creare repository remoti.
Ai repository remoti si applicano quote e limiti di Artifact Registry.
Come funzionano i repository remoti
I repository remoti archiviano gli artefatti delle seguenti origini upstream:
- Repository Artifact Registry standard.
- Sorgenti esterne come Docker Hub, Maven Central, Python Package Index (PyPI), Debian o CentOS.
Un repository remoto funge da proxy per l'origine upstream, in modo da avere un maggiore controllo sulle dipendenze. La prima volta che richiedi una versione di un pacchetto, Artifact Registry scarica e memorizza nella cache il pacchetto nel repository remoto. La volta successiva che richiedi la stessa versione del pacchetto, Artifact Registry fornisce la copia memorizzata nella cache.
Se richiedi un artefatto da un'origine upstream che non esiste o non contiene la versione specificata, la richiesta non andrà a buon fine.
Le altre modalità del repository sono:
- Standard: la modalità predefinita del repository. Carichi o pubblichi artefatti come pacchetti privati direttamente nei repository standard. Sebbene sia possibile scaricare direttamente dai singoli repository standard, l'accesso a gruppi di repository con un repository virtuale semplifica la configurazione degli strumenti.
- Virtuale: un repository che funge da unico punto di accesso per più repository upstream, inclusi repository remoti e standard.
Autenticazione upstream
I repository remoti di Artifact Registry supportano l'autenticazione di base alle origini upstream per i formati supportati. Per saperne di più su come autenticarsi alle origini upstream del repository remoto, consulta Configura l'autenticazione per gli upstream del repository remoto.
Casi d'uso e vantaggi
- Accesso più rapido e affidabile agli artefatti
- L'archiviazione di copie memorizzate nella cache delle dipendenze pubbliche in Artifact Registry riduce la latenza quando altri Google Cloud servizi recuperano le immagini. Gli artefatti memorizzati nella cache sono ancora disponibili se il repository pubblico esterno è offline a causa di un'interruzione o di un altro problema.
- Risoluzione delle dipendenze più sicura
Utilizza i repository remoti insieme ai repository virtuali per mitigare i rischi associati alle dipendenze pubbliche. Alcuni strumenti 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.
Anziché configurare i client direttamente per la ricerca in più repository, puoi configurare repository virtuali per dare la priorità ai repository privati rispetto a quelli remoti.
- Ridurre i costi di trasferimento dei dati
Utilizza repository remoti per memorizzare nella cache gli artefatti nella stessa regione o in più regioni dei runtime per ridurre i costi di trasferimento dei dati.
Se Artifact Registry si trova in un perimetro di servizio Controlli di servizio VPC, per impostazione predefinita Artifact Registry nega l'accesso alle origini upstream al di fuori del perimetro. Per consentire ai repository remoti in una posizione specifica di accedere alle origini esterne configurate al di fuori del perimetro, consulta le istruzioni per la configurazione di Controlli di servizio VPC.
Per scoprire altre best practice per la gestione delle dipendenze, consulta la sezione Gestione delle dipendenze.
Aggiornamenti agli indici e ai metadati dei pacchetti
I file modificabili, come gli indici e i metadati dei pacchetti, vengono aggiornati dall'origine upstream quando superano l'età predefinita. I valori predefiniti per tipi di file specifici sono elencati nella tabella seguente:
Formato | Tipo di file | Età predefinita dell'aggiornamento |
---|---|---|
Maven | maven-metadata.xml |
5 minuti |
archetype-catalog.xml |
1 ora | |
Npm | File manifest | 5 minuti |
Python | File indice | 1 ora |
Docker | List/Get tags cache | 1 ora |
Apt/Yum (anteprima) | File indice | 2 minuti |
File del pacchetto | 72 ore |
Formati supportati
Per i formati disponibili per i repository remoti preimpostati e definiti dall'utente, consulta le sezioni seguenti.
URL upstream preimpostati
Per comodità, sono disponibili diversi URL di repository upstream comuni come selezioni preimpostate nei seguenti formati.
Formato | tipi di pacchetti | URL upstream | Nome preimpostazione upstream |
---|---|---|---|
Docker | Pubblico o privato | https://registry-1.docker.io |
DOCKER-HUB |
Vai | Pubblico | https://proxy.golang.org |
https://proxy.golang.org |
Maven | Pubblico o privato | https://repo.maven.apache.org/maven2 |
MAVEN-CENTRAL |
npm | Pubblico o privato | https://registry.npmjs.org |
NPMJS |
Python | Pubblico | https://pypi.io |
PYPI |
Pacchetti del sistema operativo (anteprima) | Pubblico | Vedi Upstream supportati per i pacchetti del sistema operativo | Vedi Upstream supportati per i pacchetti del sistema operativo |
Upstream preimpostati dei pacchetti del sistema operativo
Puoi creare un repository remoto di pacchetti del sistema operativo scegliendo uno degli URL di base del repository upstream preimpostati comuni e personalizzando il resto dell'URL in base al repository specifico. Sono supportate le seguenti basi del repository:
Apt
Repository | Prefisso URL | Nome base del repository |
---|---|---|
Debian archiviato | https://snapshot.debian.org |
DEBIAN_SNAPSHOT |
Debian | http://deb.debian.org |
DEBIAN |
Ubuntu LTS o Pro | http://archive.ubuntu.com
|
UBUNTU
|
Yum
Repository | Prefisso URL | Nome base del repository |
---|---|---|
CentOS | http://mirror.centos.org
|
CENTOS
|
http://debuginfo.centos.org
|
CENTOS_DEBUG
|
|
https://vault.centos.org
|
CENTOS_VAULT
|
|
https://mirror.stream.centos.org
|
CENTOS_STREAM
|
|
Rocky | http://dl.rockylinux.org
|
ROCKY
|
Fedora Extra Packages for Enterprise Linux (EPEL) | https://dl.fedoraproject.org/pub/epel
|
EPEL
|
Upstream del repository Artifact Registry
Puoi creare repository remoti con repository in formato standard Artifact Registry come upstream per i seguenti formati:
- Docker
- npm
- Maven
- Python
URL personalizzati
Puoi inserire direttamente l'URL del repository remoto, senza utilizzare una delle origini upstream preimpostate per i seguenti formati.
- Docker
- npm
- Maven
- Python
La seguente tabella non esaustiva elenca alcuni URI upstream comuni.
Formato | URI upstream | Nome del registro |
---|---|---|
Docker | https://ghcr.io |
GitHub Container Registry |
Docker | https://registry-1.docker.io |
Docker Hub |
Docker | https://public.ecr.aws |
Galleria pubblica AWS ECR |
Docker | https://registry.k8s.io |
Container Registry Kubernetes |
Docker | https://MY_NEXUS_IP |
Nexus |
npm | https://registry.npmjs.org |
npm |
npm | https://npm.pkg.github.com |
Registro Npm di GitHub |
npm | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY |
Nexus |
Maven | https://repo.maven.apache.org/maven2 |
Maven Central |
Maven | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY |
Nexus |
Python | https://pypi.io |
Python Package Index (PyPI) |
Python | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY |
Nexus |
Dove
- MY_NEXUS_IP è l'indirizzo IP e la porta dell'istanza upstream di Nexus.
- MY_UPSTREAM_REPOSITORY è il nome del repository upstream; utilizzato negli esempi di Nexus.
Limitazioni
Oltre alle quote e alle limitazioni di Artifact Registry, i repository remoti presentano le seguenti limitazioni:
- I repository remoti Maven non consentono di impostare la policy di versione su snapshot o release.
- Le origini upstream devono essere accessibili a internet. I repository remoti non supportano origini upstream on-premise o di rete Virtual Private Cloud (VPC) senza un indirizzo IP pubblico.
Passaggi successivi
- Crea repository remoti.
- Scopri di più sui repository Artifact Registry leggendo la Panoramica dei repository.