Remote-Repositories – Übersicht

Dieses Dokument bietet einen Überblick über Remote-Repositories. Eine Anleitung zum Erstellen eines Remote-Repositories finden Sie unter Remote-Repositories erstellen.

Für Remote-Repositories gelten die Kontingente und Limits von Artifact Registry.

Funktionsweise von Remote-Repositories

In Remote-Repositories werden Artefakte aus den folgenden Upstream-Quellen gespeichert:

  • Standard-Artifact Registry-Repositories
  • Externe Quellen wie Docker Hub, Maven Central, der Python Package Index (PyPI), Debian oder CentOS

Ein Remote-Repository fungiert als Proxy für die Upstream-Quelle, sodass Sie mehr Kontrolle über Ihre Abhängigkeiten haben. Wenn Sie zum ersten Mal eine Version eines Pakets anfordern, lädt Artifact Registry das Paket in das Remote-Repository herunter und speichert es im Cache. Wenn Sie dieselbe Paketversion das nächste Mal anfordern, liefert Artifact Registry die im Cache gespeicherte Kopie.

Wenn Sie ein Artefakt aus einer Upstream-Quelle anfordern, die nicht existiert oder die von Ihnen angegebene Version nicht enthält, schlägt die Anfrage fehl.

Die anderen Repository-Modi sind:

  • Standard: Der Standard-Repository-Modus. Sie laden Artefakte wie private Pakete direkt in Standard-Repositories hoch oder veröffentlichen sie dort. Sie können zwar direkt aus einzelnen Standard-Repositories herunterladen, aber der Zugriff auf Repositoriegruppen mit einem virtuellen Repository vereinfacht die Toolkonfiguration.
  • Virtuell: Ein Repository, das als einzelner Zugangspunkt für mehrere Upstream-Repositories dient, einschließlich Remote- und Standard-Repositories.

Upstream-Authentifizierung

Remote-Repositories von Artifact Registry unterstützen die Basisauthentifizierung für Upstream-Quellen für unterstützte Formate. Weitere Informationen zur Authentifizierung bei Upstream-Quellen des Remote-Repositories finden Sie unter Authentifizierung bei Upstreams des Remote-Repositories konfigurieren.

Anwendungsfälle und Vorteile

Schnellerer und zuverlässigerer Zugriff auf Artefakte
Wenn Sie Cache-Kopien Ihrer öffentlichen Abhängigkeiten in Artifact Registry speichern, wird die Latenz beim Abrufen von Images durch andere Google Cloud Dienste verringert. Im Cache gespeicherte Artefakte sind auch dann verfügbar, wenn das externe öffentliche Repository aufgrund eines Ausfalls oder eines anderen Problems offline ist.
Sicherere Auflösung von Abhängigkeiten

Verwenden Sie Remote-Repositories zusammen mit virtuellen Repositories, um die mit öffentlichen Abhängigkeiten verbundenen Risiken zu minimieren. Bei einigen Tools gibt es keine Möglichkeit, die Suchreihenfolge zu steuern, wenn im Client eine Mischung aus privaten und öffentlichen Repositories konfiguriert ist. Diese Art der Konfiguration ist anfällig für einen Dependency Confusion-Angriff, bei dem jemand eine neue Version eines Pakets mit fehlerhaftem Code in ein öffentliches Repository hochlädt, um Kunden dazu zu bringen, die fehlerhafte Version auszuwählen.

Anstatt Clients direkt für die Suche in mehreren Repositories zu konfigurieren, können Sie virtuelle Repositories konfigurieren, um Ihre privaten Repositories vor Remote-Repositories zu priorisieren.

Datenübertragungskosten senken

Verwenden Sie Remote-Repositories, um Artefakte in derselben Region oder Multiregion wie Ihre Laufzeiten zu cachen, um die Kosten für die Datenübertragung zu senken.

Wenn sich Artifact Registry in einem VPC Service Controls-Dienstperimeter befindet, wird standardmäßig der Zugriff auf Upstream-Quellen außerhalb des Perimeters verweigert. Wenn Sie Remote-Repositories an einem bestimmten Speicherort Zugriff auf ihre konfigurierten externen Quellen außerhalb des Perimeters gewähren möchten, lesen Sie die Anleitung zur Konfiguration von VPC Service Controls.

Weitere Best Practices für das Abhängigkeitsmanagement finden Sie unter Abhängigkeitsmanagement.

Aktualisierungen an Paketindexen und -metadaten

Veränderliche Dateien wie Paketindexe und Metadaten werden aus der Upstream-Quelle aktualisiert, wenn ihr Alter das Standardalter überschreitet. Die Standardeinstellungen für bestimmte Dateitypen sind in der folgenden Tabelle aufgeführt:

Format Dateityp Standardalter für Updates
Maven maven-metadata.xml 5 Minuten
archetype-catalog.xml 1 Stunde
Npm Manifestdateien 5 Minuten
Python Indexdateien 1 Stunde
Docker Tags-Cache auflisten/abrufen 1 Stunde
Apt/Yum (Vorabversion) Indexdateien 2 Minuten
Paketdateien 72 Stunden

Unterstützte Formate

In den folgenden Abschnitten finden Sie die Formate, die für vordefinierte und benutzerdefinierte Remote-Repositories verfügbar sind.

Vordefinierte Upstream-URLs

Eine Reihe gängiger Upstream-Repository-URLs sind als voreingestellte Auswahlmöglichkeiten in den folgenden Formaten verfügbar.

Format Pakettypen Upstream-URL Name der Upstream-Voreinstellung
Docker Öffentlich oder privat https://registry-1.docker.io DOCKER-HUB
Maven Öffentlich oder privat https://repo.maven.apache.org/maven2 MAVEN-CENTRAL
npm Öffentlich oder privat https://registry.npmjs.org NPMJS
Python Öffentlich https://pypi.io PYPI
Betriebssystempakete (Vorabversion) Öffentlich Siehe Unterstützte Upstreams für Betriebssystempakete Siehe Unterstützte Upstreams für Betriebssystempakete

Vordefinierte Upstreams für Betriebssystempakete

Sie können ein Remote-Repository für ein Betriebssystempaket erstellen, indem Sie eine der gängigen voreingestellten Basis-URLs für Upstream-Repositories auswählen und den Rest der URL an das jeweilige Repository anpassen. Die folgenden Repository-Basen werden unterstützt:

Apt

Repository URL-Präfix Repository-Basisname
Archivierte Debian-Versionen https://snapshot.debian.org DEBIAN_SNAPSHOT
Debian http://deb.debian.org DEBIAN
Ubuntu LTS oder Pro http://archive.ubuntu.com UBUNTU

Yum

Repository URL-Präfix Repository-Basisname
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
Max http://dl.rockylinux.org ROCKY
Fedora Extra Packages for Enterprise Linux (EPEL) https://dl.fedoraproject.org/pub/epel EPEL

Upstreams von Artifact Registry-Repositories

Sie können Remote-Repositories mit Artifact Registry-Standardformat-Repositories als Upstreams für die folgenden Formate erstellen:

  • Docker
  • npm
  • Maven
  • Python

Benutzerdefinierte URLs

Sie können die URL für Ihr Remote-Repository direkt eingeben, ohne eine der vordefinierten Upstream-Quellen für die folgenden Formate zu verwenden.

  • Docker
  • npm
  • Maven
  • Python

In der folgenden unvollständigen Tabelle sind einige gängige Upstream-URIs aufgeführt.

Format Upstream-URI Registry Name
Docker https://registry-1.docker.io Docker Hub
Docker https://public.ecr.aws AWS ECR Public Gallery
Docker https://registry.k8s.io Kubernetes Container Registry
Docker https://MY_NEXUS_IP Nexus
npm https://registry.npmjs.org npm
npm https://npm.pkg.github.com GitHub Npm Registry
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

Dabei gilt:

  • MY_NEXUS_IP ist die IP-Adresse und der Port Ihrer Nexus-Upstream-Instanz.
  • MY_UPSTREAM_REPOSITORY ist der Name Ihres Upstream-Repositorys, der in den Nexus-Beispielen verwendet wird.

Beschränkungen

Zusätzlich zu den Kontingenten und Einschränkungen der Artifact Registry gelten für Remote-Repositories die folgenden Einschränkungen:

  • In Maven-Remote-Repositories kann die Versionsrichtlinie nicht auf „Snapshot“ oder „Release“ festgelegt werden.
  • Upstream-Quellen müssen über das Internet zugänglich sein. Remote-Repositories unterstützen keine lokalen oder VPC-Netzwerk-Upstream-Quellen (Virtual Private Cloud) ohne öffentliche IP-Adresse.

Nächste Schritte