Dieses Dokument bietet einen Überblick über Remote-Repositories. Anweisungen zur wie Sie ein Remote-Repository erstellen, siehe Erstellen Sie Remote-Repositories.
Für Remote-Repositories gelten die Kontingente und Limits von Artifact Registry.
Funktionsweise von Remote-Repositories
In Remote-Repositories werden Artefakte aus vordefinierten externen Quellen wie Docker Hub, Maven Central, dem Python Package Index (PyPI), Debian oder CentOS sowie benutzerdefinierte Quellen für unterstützte Formate gespeichert. Ein Remote-Repository fungiert als Proxy für die externe Quelle, sodass Sie mehr Kontrolle über Ihre externen Abhängigkeiten haben. Wenn Sie zum ersten Mal eine Version einer Paket, Artifact Registry lädt das Paket herunter und speichert es im Remote-Repository. Wenn Sie das nächste Mal dieselbe Paketversion anfordern, stellt Artifact Registry die im Cache gespeicherte Kopie bereit.
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 oder veröffentlichen Artefakte wie private Pakete direkt in Standard-Repositories übertragen. 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 Zugriff dient für mehrere Upstream-Repositories, einschließlich Remote- und Standard-Repositories Repositories.
Upstream-Authentifizierung
Unterstützung von Remote-Repositories von Artifact Registry Basisauthentifizierung auf die Voreinstellung zurückgesetzt und benutzerdefinierte Upstream-Quellen für unterstützte Formate. Weitere Informationen zur Authentifizierung bei Upstream-Quellen eines Remote-Repositories finden Sie unter Authentifizierung bei Upstream-Quellen eines Remote-Repositories konfigurieren.
Anwendungsfälle und Vorteile
- Schnellerer und zuverlässigerer Zugriff auf Artefakte
- Im Cache gespeicherte Kopien Ihrer öffentlichen Abhängigkeiten in Artifact Registry speichern reduziert die Latenz, wenn andere Google Cloud-Dienste Images abrufen. Im Cache gespeicherte Artefakte sind auch dann verfügbar, wenn das externe öffentliche Repository aufgrund eines Ausfalls oder eines anderen Problems offline ist.
- Sicherere Abhängigkeitsauflösung
Remote-Repositories zusammen mit virtuellen Repositories verwenden, um Risiken zu mindern die mit öffentlichen Abhängigkeiten verbunden sind. Einige Tools bieten keine Möglichkeit, Suchreihenfolge steuern, wenn eine Mischung aus privaten und öffentlichen Repositories die im Client konfiguriert sind. Diese Art der Konfiguration ist anfällig für Abhängigkeitsverwirrung, bei der jemand eine neue Version eines in ein öffentliches Repository übertragen, um Clients die schlechte Version haben.
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.
Wenn sich Artifact Registry in einem VPC Service Controls-Dienstperimeter befindet, wird standardmäßig der Zugriff auf Upstream-Quellen außerhalb des Perimeters verweigert. Zugriff auf Remote-Repositories an einem bestimmten Standort zulassen konfigurierte externe Quellen außerhalb des Perimeters, siehe Anleitung für die VPC Service Controls-Konfiguration.
Weitere Best Practices für das Abhängigkeitsmanagement finden Sie unter Abhängigkeitsverwaltung.
Aktualisierungen von Paketindexen und Metadaten
Änderbare Dateien wie Paketindexe und Metadaten werden aktualisiert aus der vorgelagerten Quelle, wenn sie älter als das Standardalter sind. Standardeinstellungen für bestimmte Dateitypen finden Sie in der folgenden Tabelle:
| Format | Dateityp | Standardalter für Aktualisierung |
|---|---|---|
| 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.
Voreingestellte Upstreams
Sie können Remote-Repositories für die folgenden Repository-Formate und entsprechende voreingestellte Upstream-Quellen:
| 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 Upstreams, die von Betriebssystempaketen unterstützt werden | Siehe Upstreams, die von Betriebssystempaketen unterstützt werden |
Voreingestellte Upstreams für Betriebssystempakete
Sie können ein Remote-Repository für Betriebssystempakete erstellen, indem Sie eine Repository-Basis 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 |
|---|---|---|
| Debian | http://deb.debian.org | DEBIAN |
| Ubuntu LTS oder Pro | http://archive.ubuntu.com | UBUNTU |
Lecker
| 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-Pakete für Enterprise Linux (EPEL) | https://dl.fedoraproject.org/pub/epel | EPEL |
Benutzerdefinierte Upstreams
Sie können Remote-Repositories für benutzerdefinierte Upstream-Quellen in der folgenden Formaten:
- 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://public.ecr.aws | Öffentliche Galerie von AWS ECR |
| Docker | https://registry.k8s.io | Kubernetes Container Registry |
| Docker | https://MY_ARTIFACTORY_INSTANCE.jfrog.io | JFrog Artifactory |
| Docker | https://MY_NEXUS_IP | Nexus |
| npm | https://npm.pkg.github.com | GitHub-Npm-Registry |
| npm | https://MY_ARTIFACTORY_INSTANCE.jfrog.io/artifactory/api/npm/MY_UPSTREAM_REPOSITORY | JFrosch |
| npm | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY | Nexus |
| Maven | https://MY_ARTIFACTORY_INSTANCE.jfrog.io/artifactory/MY_UPSTREAM_REPOSITORY | JFrosch |
| Maven | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY | Nexus |
| Python | https://MY_ARTIFACTORY_INSTANCE.jfrog.io/artifactory/api/pypi/MY_UPSTREAM_REPOSITORY | JFrosch |
| Python | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY | Nexus |
Dabei gilt:
- MY_ARTIFACTORY_INSTANCE ist der Name Ihrer Jfrog Artifactory-Upstream-Instanz.
- MY_NEXUS_IP ist die IP-Adresse und der Port Ihres Nexus-Upstreams. Instanz.
- MY_UPSTREAM_REPOSITORY ist der Name Ihres Upstream-Repositorys. die in den Beispielen für Nexus und Artifactory verwendet werden.
Beschränkungen
Zusätzlich zu den Kontingenten und Beschränkungen für Artifact Registry Repositories haben die folgenden Einschränkungen:
- Bei 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 können Unterstützung von lokalen oder VPC-Netzwerkquellen (Virtual Private Cloud) ohne öffentliche IP-Adresse.
Nächste Schritte
- Remote-Repositories erstellen
- Weitere Informationen zu Artifact Registry-Repositories finden Sie unter Repository-Übersicht.