Remote-Repositories – Übersicht

Remote-Repositories fungieren als Proxys für Upstream-Quellen wie Docker Hub und Maven Central und bieten mehr Kontrolle über Ihre Abhängigkeiten inGoogle Cloud. In diesem Dokument wird die Funktionsweise von Remote-Repositories beschrieben und es werden mehrere Anwendungsfälle vorgestellt.

Eine Anleitung zum Erstellen eines Remote-Repositorys finden Sie unter Remote-Repositories erstellen.

Funktionsweise von Remote-Repositories

In Remote-Repositories werden Artefakte aus Standard-Artifact Registry-Repositories und externen Quellen gespeichert. Wenn Sie zum ersten Mal eine Version eines Pakets anfordern, lädt Artifact Registry das Paket herunter und speichert es im Remote-Repository. Wenn Sie das nächste Mal dieselbe Paketversion anfordern, wird die im Cache gespeicherte Kopie von Artifact Registry bereitgestellt.

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

Upstream-Authentifizierung

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

Anwendungsfälle und Vorteile

Schnellerer und zuverlässigerer Zugriff auf Artefakte
Durch das Speichern von gecachten Kopien Ihrer öffentlichen Abhängigkeiten in Artifact Registry wird die Latenz verringert, wenn andere Google Cloud Dienste Images abrufen. Zwischengespeicherte Artefakte sind auch dann noch 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 Risiken im Zusammenhang mit öffentlichen Abhängigkeiten zu minimieren. Bei einigen Tools lässt sich die Suchreihenfolge nicht steuern, wenn im Client eine Mischung aus privaten und öffentlichen Repositorys konfiguriert ist. Diese Art der Konfiguration ist anfällig für einen Angriff durch Verwirrung von Abhängigkeiten. Dabei lädt jemand eine neue Version eines Pakets mit schädlichem Code in ein öffentliches Repository hoch, um Clients dazu zu bringen, die schädliche 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 gegenüber Remote-Repositories zu priorisieren.

Kosten für Datenübertragung reduzieren

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

Wenn sich Artifact Registry in einem VPC Service Controls-Dienstperimeter befindet, verweigert Artifact Registry standardmäßig den Zugriff auf Upstream-Quellen außerhalb des Perimeters. Wenn Sie zulassen möchten, dass Remote-Repositories an einem bestimmten Standort außerhalb des Perimeters auf ihre konfigurierten externen Quellen zugreifen, folgen Sie der Anleitung zur Konfiguration von VPC Service Controls.

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

Aktualisierungen von Paketindexen und ‑metadaten

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

Format Dateityp Standardmäßiges Alter von Updates
Maven maven-metadata.xml 5 Minuten
archetype-catalog.xml 1 Stunde
Npm Manifestdateien 5 Minuten
Python Dateien indexieren 1 Stunde
Docker Cache für Tags auflisten/abrufen 1 Stunde
Apt/Yum (Vorabversion) Dateien indexieren 2 Minuten
Paketdateien 72 Stunden

Unterstützte Formate

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

Upstream-URLs voreinstellen

Eine Reihe gängiger Upstream-Repository-URLs sind als voreingestellte Auswahl 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
Go Öffentlich https://proxy.golang.org https://proxy.golang.org
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

Voreingestellte Upstreams für Betriebssystempakete

Sie können ein Remote-Repository für Betriebssystempakete erstellen, indem Sie eine der gängigen voreingestellten Upstream-Repository-Basis-URLs 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
Archiviertes Debian 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 für 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 voreingestellten 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 Registrierungsname
Docker https://ghcr.io GitHub Container Registry
Docker https://registry-1.docker.io Docker Hub
Docker https://public.ecr.aws Öffentliche AWS ECR-Galerie
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

Wo

  • 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 Artifact Registry-Kontingenten und -Einschränkungen gelten für Remote-Repositories die folgenden Einschränkungen:

  • In Maven-Remote-Repositories ist es nicht zulässig, die Versionsrichtlinie auf „snapshot“ oder „release“ festzulegen.
  • Upstream-Quellen müssen über das Internet zugänglich sein. Für Remote-Repositories werden keine Upstream-Quellen in lokalen Netzwerken oder VPC-Netzwerken (Virtual Private Cloud) ohne öffentliche IP-Adresse unterstützt.

Andere Repository-Modi

Die anderen Repository-Modi sind:

  • Standard: Der Standardmodus für das Repository. 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, der Zugriff auf Repository-Gruppen mit einem virtuellen Repository vereinfacht jedoch die Toolkonfiguration.
  • Virtuell: Ein Repository, das als einzelner Zugriffspunkt für mehrere Upstream-Repositories dient, einschließlich Remote- und Standard-Repositories.

Nächste Schritte