Dieses Dokument bietet einen Überblick über Remote-Repositories. Eine Anleitung zum Erstellen eines Remote-Repositorys finden Sie unter Remote-Repositories erstellen.
Für Remote-Repositories gelten Kontingente und Limits von Artifact Registry.
Funktionsweise von Remote-Repositories
Remote-Repositories speichern Artefakte aus voreingestellten externen Quellen wie Docker Hub, Maven Central, dem Python Package Index (PyPI), Debian oder CentOS sowie benutzerdefinierte Quellen für unterstützte Formate. 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 eines Pakets anfordern, wird das Paket von Artifact Registry heruntergeladen und im Remote-Repository gespeichert. Wenn Sie das nächste Mal dieselbe Paketversion anfordern, stellt Artifact Registry die im Cache gespeicherte Kopie bereit.
Wenn Sie ein Artefakt von einer vorgelagerten Quelle anfordern, das nicht vorhanden ist oder nicht die von Ihnen angegebene Version enthält, schlägt die Anfrage fehl.
Die anderen Repository-Modi sind:
- Standard: Der standardmäßige Repository-Modus. Sie laden Artefakte wie private Pakete direkt in Standard-Repositories hoch oder veröffentlichen sie. Obwohl Sie Inhalte direkt aus einzelnen Standard-Repositories herunterladen können, vereinfacht der Zugriff auf Gruppen von Repositories mit einem virtuellen Repository 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 eine Basisauthentifizierung für vordefinierte und benutzerdefinierte Upstream-Quellen für unterstützte Formate. Weitere Informationen zur Authentifizierung bei Remote-Repository-Upstream-Quellen finden Sie unter Authentifizierung bei Remote-Repository-Upstreams konfigurieren.
Anwendungsfälle und Vorteile
- Schnellerer, zuverlässigerer Zugriff auf Artefakte
- Das Speichern von im Cache gespeicherten Kopien Ihrer öffentlichen Abhängigkeiten in Artifact Registry 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ängigkeitslösung
Verwenden Sie Remote-Repositories zusammen mit virtuellen Repositories, um die mit öffentlichen Abhängigkeiten verbundenen Risiken zu minimieren. Einige Tools bieten keine Möglichkeit, die Suchreihenfolge zu steuern, wenn im Client eine Mischung aus privaten und öffentlichen Repositories konfiguriert ist. Diese Art von Konfiguration ist anfällig für Abhängigkeitsverwirrung. Dabei lädt jemand eine neue Version eines Pakets mit fehlerhaftem Code in ein öffentliches Repository hoch, um Clients dazu zu bringen, die schlechte Version auszuwählen.
Anstatt Clients direkt so zu konfigurieren, dass mehrere Repositories durchsucht werden, können Sie virtuelle Repositories so konfigurieren, dass Ihre privaten Repositories gegenüber Remote-Repositories priorisiert werden.
Wenn sich Artifact Registry in einem VPC Service Controls-Dienstperimeter befindet, verweigert Artifact Registry den Zugriff auf Upstream-Quellen außerhalb des Perimeters standardmäßig. Wenn Sie Remote-Repositories an einem bestimmten Standort erlauben möchten, auf ihre konfigurierten externen Quellen außerhalb des Perimeters zuzugreifen, lesen Sie die 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
Änderbare Dateien wie Paketindexe und Metadaten werden von der Upstream-Quelle aktualisiert, wenn das Standardalter überschritten wird. Die Standardeinstellungen für bestimmte Dateitypen sind in der folgenden Tabelle aufgeführt:
| Format | File type | Standardalter für Updates |
|---|---|---|
| Maven | maven-metadata.xml |
5 Minuten |
archetype-catalog.xml |
1 Stunde | |
| NPM | Manifestdateien | 5 Minuten |
| Python | Indexdateien | 1 Stunde |
| Docker | Cache für „Tags auflisten/abrufen“ | 1 Stunde |
| Apt./Yum (Vorabversion) | Indexdateien | 2 Minuten |
| Paketdateien | 72 Stunden |
Unterstützte Formate
In den folgenden Abschnitten finden Sie Informationen zu den Formaten, die für voreingestellte 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 erstellen:
| Format | Pakettypen | Upstream-URL | Name der Upstream-Voreinstellung |
|---|---|---|---|
| Docker | Öffentlich oder privat | https://registration-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 | Weitere Informationen zu unterstützten Upstreams von Betriebssystempaketen | Weitere Informationen zu unterstützten Upstreams von Betriebssystempaketen |
Voreingestellte Upstreams von Betriebssystempaketen
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-Basis wird unterstützt:
Apt.
| Repository | URL-Präfix | Repository-Basisname |
|---|---|---|
| Debian | http://deb.debian.org | DEBISCH |
| 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 Packages for Enterprise Linux (EPEL) | https://dl.fedoraproject.org/pub/epel | Logo: EPEL |
Benutzerdefinierte Upstreams
Sie können Remote-Repositories für benutzerdefinierte Upstream-Quellen in den folgenden Formaten erstellen:
- Docker
- npm
- Maven
- Python
In der folgenden Tabelle sind einige häufig verwendete Upstream-URIs aufgeführt.
| Format | Upstream-URI | Name der Registry |
|---|---|---|
| Docker | https://public.ecr.aws | Öffentliche AWS ECR-Galerie |
| Docker | https://registry.k8s.io | Kubernetes Container Registry |
| Docker | https://MY_ARTIFACTORY_INSTANCE.jfrog.io | JFrosch-Artefakt |
| 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-Artefakt |
| npm | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY | Nexus |
| Maven | https://MY_ARTIFACTORY_INSTANCE.jfrog.io/artifactory/MY_UPSTREAM_REPOSITORY | JFrosch-Artefakt |
| Maven | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY | Nexus |
| Python | https://MY_ARTIFACTORY_INSTANCE.jfrog.io/artifactory/api/pypi/MY_UPSTREAM_REPOSITORY | JFrosch-Artefakt |
| Python | https://MY_NEXUS_IP/repository/MY_UPSTREAM_REPOSITORY | Nexus |
Dabei gilt:
- MY_ARTIFACTORY_INSTANCE ist der Name der Upstream-Instanz von Jfrog Artifactory.
- MY_NEXUS_IP ist die IP-Adresse und der Port Ihrer vorgelagerten Nexus-Instanz.
- MY_UPSTREAM_REPOSITORY ist der Name Ihres Upstream-Repositorys; wird im Nexus- und Artifactory-Beispiel verwendet.
Beschränkungen
Neben den Kontingenten und Einschränkungen von Artifact Registry gelten für Remote-Repositories die folgenden Einschränkungen:
- Maven-Remote-Repositories erlauben nicht das Festlegen der Versionsrichtlinie auf „Snapshot“ oder „Release“.
Nächste Schritte
- Remote-Repositories erstellen
- Weitere Informationen zu Artifact Registry-Repositories finden Sie in der Repository-Übersicht.