I repository remoti fungono da proxy per le origini upstream, come Docker Hub e Maven Central, e forniscono un maggiore controllo sulle dipendenze in Google Cloud. Questo documento descrive come funzionano i repository remoti e fornisce diversi casi d'uso.
Per istruzioni su come creare un repository remoto, consulta Crea repository remoti.
Come funzionano i repository remoti
I repository remoti archiviano artefatti provenienti da repository Artifact Registry standard e da origini esterne. 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.
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 alle origini 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 i 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 dei Controlli di servizio VPC, per impostazione predefinita 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 dei 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
Sono disponibili diversi URL di repository upstream comuni come selezioni preimpostate per comodità nei seguenti formati.
| Formato | tipi di pacchetti | URL upstream | Nome preimpostazione upstream |
|---|---|---|---|
| Docker | Pubblico o privato | https://registry-1.docker.io |
DOCKER-HUB |
| Go | 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 di 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.
Altre modalità del repository
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.
Passaggi successivi
- Crea repository remoti.
- Scopri di più sui repository Artifact Registry leggendo la Panoramica dei repository.