Repository-Übersicht

Artifact Registry ermöglicht das Speichern verschiedener Artefakttypen, das Erstellen mehrerer Repositories in einem einzelnen Projekt und das Verknüpfen einer bestimmten Region oder Mehrfachregion mit jedem Repository. Auf dieser Seite werden Überlegungen zum Planen der Speicherorte und der Organisation Ihrer Repositories beschrieben.

Berücksichtigen Sie beim Erstellen Ihrer Repositories sowohl interne Prozesse als auch die Nutzung durch Nutzer Ihrer Artefakte.

Repository-Formate

Jedem Repository ist ein bestimmtes Artefaktformat zugeordnet. In einem Docker-Repository werden beispielsweise Docker-Images gespeichert. Sie können für jedes Format mehrere Repositories im selben Google Cloud Projekt erstellen.

Repository-Modi

Es gibt mehrere Repository-Modi. Jeder Modus hat einen anderen Zweck. Daher kann der Repository-Modus nicht geändert werden, nachdem Sie ein Repository erstellt haben.

Standard-Repository

Standard-Repositories sind reguläre Artifact Registry-Repositories für Ihre privaten Artefakte. Sie laden Artefakte direkt über diese Repositories hoch und herunterladen sie und verwenden die Artefaktanalyse, um nach Sicherheitslücken und anderen Metadaten zu suchen.

Folgen Sie der Anleitung unter Standard-Repositories erstellen, um Standard-Repositories zu erstellen.

Remote-Repository

Remote-Repositories sind schreibgeschützte Repositories, die als Proxys dienen, um Artefakte aus den folgenden Upstream-Quellen zu speichern:

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

Wenn Sie eine Artefaktversion zum ersten Mal anfordern, wird sie vom Repository aus der Upstream-Quelle heruntergeladen und eine Kopie davon im Cache gespeichert. Das Remote-Repository gibt die im Cache gespeicherte Kopie aus, wenn dieselbe Version noch einmal angefordert wird.

Mit Remote-Repositories wird die Latenz verringert und die Verfügbarkeit für Builds und Bereitstellungen auf Google Cloudverbessert. Mit der Artefaktanalyse können Sie auch im Cache gespeicherte Pakete auf Sicherheitslücken und andere Metadaten prüfen.

Weitere Informationen zu Remote-Repositories finden Sie unter Remote-Repositorys – Übersicht. Informationen zum Erstellen von Remote-Repositories finden Sie unter Remote-Repositories erstellen.

Virtuelles Repository

Ein Lesezugriffs-Repository, das als einzelner Zugriffspunkt dient, um Artefakte desselben Formats aus einem oder mehreren Upstream-Repositories herunterzuladen, zu installieren oder bereitzustellen. Ein Upstream-Repository kann ein Standard-, Remote- oder virtuelles Repository sein.

Virtuelle Repositories vereinfachen die Clientkonfiguration für Nutzer Ihrer Artefakte. Sie können auch Abhängigkeitsverwirrungsangriffe abmildern, indem Sie Ihre Upstream-Richtlinie so konfigurieren, dass Repositories mit Ihren privaten Artefakten vorrangig vor Remote-Repositories priorisiert werden, in denen öffentliche Artefakte im Cache gespeichert werden.

Weitere Informationen zu virtuellen Repositories finden Sie unter Virtuelle Repositories. Folgen Sie der Anleitung unter Virtuelle Repositories erstellen, um virtuelle Repositories zu erstellen.

Beispiel für die Repository-Nutzung

Das folgende Diagramm zeigt eine von vielen Möglichkeiten, wie Sie Repositories in verschiedenen Modi zusammen verwenden können. Das Diagramm zeigt einen Workflow für zweiGoogle Cloud -Projekte. In einem Entwicklungsprojekt erstellen Entwickler eine Java-Anwendung. In einem separaten Laufzeitprojekt wird mit einem weiteren Build ein Containerimage mit der Anwendung für die Bereitstellung in der Google Kubernetes Engine erstellt.

1. In diesem Entwicklungsprojekt verwendet ein Java-Entwicklerteam Cloud Build, um eine Java-Anwendung zu erstellen.

   • Der Build kann öffentliche Java-Abhängigkeiten über das virtuelle Repository anfordern. Das virtuelle Repository stellt die Abhängigkeiten aus dem Remote-Repository bereit, das ein Caching-Proxy für Maven Central ist.
   • Cloud Build lädt das Paket in das Standard-Maven-Repository im Komponentenprojekt hoch.

2. Im Laufzeitprojekt containerisiert Cloud Build die Java-Anwendung.

   Für den Build wird das virtuelle Maven-Repository verwendet, um die Anwendung herunterzuladen. Das virtuelle Repository stellt das Paket aus dem Standardrepository im Entwicklungsprojekt bereit. Der Build kann auch öffentliche Java-Abhängigkeiten aus demselben virtuellen Repository herunterladen.

3. Im Laufzeitprojekt lädt Cloud Build das erstellte Container-Image in ein Standard-Docker-Repository hoch.

4. GKE ruft Images aus dem virtuellen Docker-Repository ab.

   • Das Upstream-Standard-Docker-Repository bietet private Images, z. B. die containerisierte Java-Anwendung.
   • Das Upstream-Remote-Repository stellt Images bereit, die GKE von Docker Hub anfordert.

In diesem Beispiel befinden sich alle Repositories, Builds und GKE-Cluster in derselben Region. Die Verwendung desselben Speicherorts für Google Cloud -Dienste hat Vorteile, die unter Speicherort des Repositories beschrieben werden.

Speicherort des Repositories

Sie können ein oder mehrere Repositories in einer unterstützten Region oder Multi-Region erstellen. Ein guter Speicherort für das Repository bietet für die Datennutzer den optimalen Ausgleich von Latenz, Verfügbarkeit und Kosten der Bandbreite. Möglicherweise hat Ihre Organisation auch bestimmte Compliance-Anforderungen.

Überlegungen zum Standort

In diesem Abschnitt wird beschrieben, warum Sie ein Repository in derselben Region wie andere Google Cloud Dienste erstellen sollten.

Sie können die Latenz und die Kosten für ausgehenden Netzwerktraffic reduzieren, indem Sie Repositories in derselben Region erstellen, in der Sie GKE, Cloud Run, Cloud Build und andere Google Cloud Dienste ausführen, die mit dem Repository interagieren. Für den ausgehenden Traffic von der Artifact Registry zu anderen Google Cloud Diensten in derselben Region fallen keine Gebühren an.

Für den ausgehenden Traffic von einem multiregionalen Dienst zu einemGoogle Cloud -Dienst in einer entsprechenden Region fallen zwar keine Gebühren an, diese Preise gelten jedoch nur für eine begrenzte Anzahl von Regionen.

• Für die Multiregion us werden keine Gebühren für ausgehenden Traffic zu einer Region in den USA wie us-central berechnet, aber für ausgehenden Traffic zu einer Region in Kanada oder Südamerika.
• Für die multiregionale asia-Instanz werden keine Gebühren für ausgehenden Traffic zu Regionen in Asien wie asia-northeast1 berechnet, aber für ausgehenden Traffic zu Regionen in Australien.

Sie können das Image-Streaming nur in GKE und Dataproc Serverless verwenden, wenn Ihre Container-Images in Artifact Registry-Repositories in derselben Region wie Ihre Arbeitslasten oder in einer Multi-Region gespeichert sind, die der Region mit Ihren Arbeitslasten entspricht. Mit Image-Streaming lässt sich die Initialisierungszeit von Arbeitslasten bei größeren Container-Images erheblich reduzieren, da Arbeitslasten gestartet werden können, bevor das gesamte Image heruntergeladen wurde.

Berücksichtigen Sie den Standort von Verbrauchern außerhalb von Google Cloud. Wenn Ihr Entwicklerteam in Australien beispielsweise Artefakte aus der Artifact Registry auf seine lokalen Workstations herunterladen muss, reduziert ein Repository in einer australischen Region die Latenz und verursacht geringere Ausgangskosten als ein Repository auf einem anderen Kontinent.

Repository-Standorte einschränken

Wenn Sie Bestimmungen oder Richtlinien einhalten müssen, die das Speichern von Daten in bestimmten Regionen vorschreiben, können Sie in Ihrer Google CloudOrganisationsrichtlinie eine Einschränkung für Ressourcenstandorte angeben, die die Erstellung von Repositories nur in konformen Regionen zulässt. Artifact Registry erzwingt die Einschränkung erst, nachdem Sie sie in Ihre Organisationsrichtlinie aufgenommen haben. Wenn Sie bereits Repositories an nicht konformen Speicherorten haben, müssen Sie Ihre Artefakte selbst in ein Repository an einem konformen Speicherort verschieben und dann das nicht konforme Repository löschen.

Bereinigungsrichtlinien

Mit einer Bereinigungsrichtlinie für die Artifact Registry können Sie Kriterien für das automatische Löschen von Artefaktversionen festlegen, die Sie nicht mehr benötigen, oder Artefakte behalten, die Sie unbegrenzt speichern möchten.

Bereinigungsrichtlinien sind nützlich, wenn Sie viele Versionen Ihrer Artefakte speichern, aber nur bestimmte Versionen aufbewahren müssen, die Sie für die Produktion freigeben. Sie können Löschrichtlinien mit Kriterien für das Löschen von Artefakten und Aufbewahrungsrichtlinien mit Kriterien für das Aufbewahren von Artefakten definieren.

Wenn eine Artefaktversion sowohl den Kriterien einer Löschrichtlinie als auch einer Aufbewahrungsrichtlinie entspricht, wird in Artifact Registry die Aufbewahrungsrichtlinie angewendet.

Richtlinien löschen

Durch Löschrichtlinien werden Artefakte gelöscht, die den folgenden erforderlichen Kriterien entsprechen:

• Tag-Status: Gibt an, ob die Richtlinie nach getaggten oder nicht getaggten Artefakten suchen soll. Artefakte werden getaggt, wenn ein Image in ein Repository hoch- oder daraus heruntergeladen wird. Weitere Informationen zu Docker-Tags finden Sie unter Containerkonzepte.

  • Beliebiger Tag-Status: Der Tag-Status wird ignoriert und gilt sowohl für getaggte als auch für nicht getaggte Artefakte.
  • Getaggt: gilt nur für getaggte Artefakte.
  • Ohne Tag: gilt nur für nicht getaggte Artefakte.

  Formate, die keine Tags unterstützen, werden als untagged behandelt. Getaggte Artefakte in Repositories mit aktivierten unveränderlichen Tags können nicht gelöscht werden.

  Weitere Informationen zum Tag-Status im Hinblick auf Bereinigungsrichtlinien finden Sie in der Referenz zu „TagState“.

Sie haben folgende Möglichkeiten, Ihre Löschrichtlinie zu definieren:

• Tag-Präfixe: Eine durch Kommas getrennte Liste von Tag-Präfixen. Die Präfixe test und staging würden beispielsweise mit Bildern mit den Tags testenv und staging-1.5 übereinstimmen. tagState muss auf TAGGED gesetzt sein, damit Tag-Präfixe verwendet werden können.
  • Versionspräfixe: Eine durch Kommas getrennte Liste von Präfixen für die Versionen von Artefakten. Beispiel: v1, v2 würde mit den Versionen v1.5, v2.0alpha und v10.2 übereinstimmen.
• Paketpräfixe: Liste der Präfixe für Artefaktenamen. Sie können mehrere Präfixe eingeben, indem Sie zwischen den Präfixen Enter oder , drücken. Mit red, blue werden beispielsweise die beiden Präfixe red und blue erstellt und mit den Artefaktnamen red-team, redis und bluebird abgeglichen.
• Älter als: Gibt die Mindestzeit an, die vergangen ist, seit eine Artefaktversion in das Repository hochgeladen wurde. Die Zeit wird als Dauer angegeben. 30d entspricht beispielsweise 30 Tagen. Sie können die Dauer in Sekunden, Minuten, Stunden oder Tagen angeben, indem Sie jeweils s, m, h oder d anhängen.
• Jünger als: Gibt die maximale Zeit an, die vergangen ist, seit eine Artefaktversion in das Repository hochgeladen wurde. Die Zeit wird als Dauer angegeben. 30d entspricht beispielsweise 30 Tagen.

Richtlinien beibehalten

Mit Richtlinien zur Datenbeibehaltung werden Artefakte beibehalten, die denselben Bedingungen wie Richtlinien zur Datenlöschung entsprechen, oder eine festgelegte Anzahl der neuesten Versionen.

Achtung: Wenn Sie Paketpräfixe in einer Aufbewahrungsrichtlinie vom Typ Neueste Versionen beibehalten definieren, werden nur Pakete beibehalten, die den von Ihnen definierten Paketpräfixen entsprechen.

Angenommen, Sie haben ein Repository mit den folgenden Artefakten:

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

Wenn in der Richtlinie Neueste Versionen beibehalten festgelegt ist, dass drei Versionen von Paketen mit den Paketpräfixen {release-xyz} beibehalten werden sollen, werden nur release-xyz-v1 und release-xyz-v2 beibehalten.

Durch Löschrichtlinien ausgelöste Löschungen werden auf Ihr Kontingent für Löschanträge pro Projekt in Artifact Registry angerechnet.

Informationen zum Erstellen und Anwenden von Bereinigungsrichtlinien auf Ihr Repository finden Sie unter Bereinigungsrichtlinien konfigurieren.

Unterstützung von gcr.io-Domains

Artifact Registry unterstützt das Hosten von Images in der Domain gcr.io. Wenn Sie von Container Registry zu Artifact Registry wechseln, können Sie gcr.io-Repositories in Artifact Registry einrichten, um Änderungen an Ihren vorhandenen Automatisierungen und Workflows zu minimieren. Diese Repositories bieten:

• Weiterleitung von Anfragen an die Domain gcr.io
• Erstellen von gcr.io-Repositories, wenn das erste Image per Push-Befehl auf einen gcr.io-Hostnamen verschoben wird, um mit dem Verhalten von Container Registry kompatibel zu sein.

Weitere Informationen finden Sie unter Zu Repositories mit Unterstützung von gcr.io-Domains wechseln.

Projektstruktur

Mit der Ressourcenhierarchie organisieren Sie Ihre Ressourcen in Google Cloud Projekten. Die Struktur, die Sie auswählen, hängt von Faktoren wie den Anforderungen an die Datenverwaltung, den Vertrauensgrenzen und der Teamstruktur ab.

Es gibt zwei allgemeine Ansätze für die Einrichtung von Repositories in Organisationen mit mehreren Projekten.

Repositories zentralisieren

Alle Repositories in einem einzigen Projekt erstellen und dann auf Repositoryebene Zugriff für Principals aus anderen Projekten gewähren. Dieser Ansatz kann effektiver sein, wenn eine einzelne Person oder ein Team die Repository-Verwaltung und den Repository-Zugriff in Ihrer Organisation übernimmt.

Außerdem lässt sich die Einrichtung virtueller Repositories vereinfachen, da Sie nur eine Instanz von Artifact Registry aktivieren und verwalten müssen.

Projektspezifische Repositories

Erstellen Sie Repositories in Projekten, in denen Artefakte gespeichert und heruntergeladen werden. Dieser Ansatz kann erforderlich sein, wenn Sie Richtlinien zur Datenverwaltung oder Vertrauensgrenzen haben, die eine stärkere Trennung und Kontrolle von Ressourcen auf Projektebene erfordern.

Zugriffssteuerung

Auf Repositories kann nur mit den entsprechenden Berechtigungen zugegriffen werden, es sei denn, Sie konfigurieren das Repository für den öffentlichen Zugriff. Sie können Berechtigungen auf Projekt- oder Repository-Ebene erteilen.

Einige Google Cloud Dienste verwenden Standarddienstkonten mit Standardberechtigungen für Repositories im selben Google Cloud Projekt. Diese Standardeinstellungen sind jedoch möglicherweise nicht für Ihren Softwareentwicklungsprozess geeignet oder entsprechen nicht den Sicherheits- oder Richtlinienanforderungen in Ihrer Organisation. Ihr Repository-Administrator muss diesen Diensten ausdrücklich Zugriff auf Repositories gewähren, wenn:

• Artifact Registry befindet sich in einem anderen Projekt als der Dienst, der damit interagiert.
• Sie verwenden benutzerdefinierte IAM-Rollen mit den Standarddienstkonten anstelle der vordefinierten Rolle.
• Sie verwenden nicht das Standarddienstkonto für den Google Cloud Dienst.
• Sie richten virtuelle Repositories ein. Sie müssen dem Artifact Registry-Dienstkonto explizit Zugriff auf Upstream-Repositories gewähren.

Anderen Identitäten, die Zugriff auf Repositories benötigen, muss der Repository-Administrator Zugriff gewähren. Gewähren Sie gemäß dem Sicherheitsprinzip der geringsten Berechtigung die minimal erforderlichen Berechtigungen. Beispiel:

• Sie stellen Container-Images in Artifact Registry in GKE-Clustern in mehreren verschiedenen Projekten bereit. Das Dienstkonto für Knoten in diesen Clustern benötigt nur Lesezugriff auf Repositories.
• Sie haben ein Entwicklungs-Repository für Anwendungen in der Entwicklung und ein Produktions-Repository für veröffentlichte Anwendungen. Entwickler benötigen Lese- und Schreibzugriff auf das Entwicklungs-Repository und Lesezugriff auf das Produktions-Repository.
• Sie haben ein Demo-Repository mit Beispielanwendungen. Ihr Vertriebsteam benötigt nur Lesezugriff, um die Demos herunterzuladen.

Downloads von Artefakten einschränken

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Sie können Artifact-Downloads mit Downloadregeln einschränken. Mit Downloadregeln können Sie den Download von Artefakten aus Ihren Repositories und Paketen zulassen oder ablehnen. Sie können auch Bedingungen festlegen, damit die Regel für bestimmte Tags oder Versionen gilt.

Weitere Informationen zur Funktionsweise von Downloadregeln finden Sie im Abschnitt Downloads von Artefakten einschränken der Übersicht „Zugriff steuern und Artefakte schützen“.

Datenverschlüsselung

Standardmäßig werden Daten im inaktiven Zustand Google Cloud automatisch mitVerschlüsselungsschlüsseln, die von Google verwaltet werden , verschlüsselt. Wenn Sie bestimmte Compliance- oder behördliche Anforderungen in Bezug auf die Schlüssel zum Schutz Ihrer Daten haben, können Sie Repositories erstellen, die mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt sind.

Artifact Registry unterstützt auch Einschränkungen für Organisationsrichtlinien, die einen CMEK-Schutz für den Schutz von Ressourcen erfordern können.

Labels und Tags

Mit Labels können Sie Ressourcen für einen bestimmten Dienst organisieren. Google CloudIn Artifact Registry können Sie Repositories Labels hinzufügen, um sie zu gruppieren oder Repositorylisten nach Label zu filtern. Sie können beispielsweise Repositories nach Entwicklungsphase oder Team für Automatisierungs- oder Abrechnungszwecke gruppieren. Weitere Informationen zum Erstellen und Verwenden von Repository-Labels finden Sie unter Repositories labeln.

Sie können Repositories auch Tags zuweisen. Labels dienen in erster Linie dazu, dienstspezifische Ressourcen zu organisieren und zu filtern. Tags hingegen dienen der programmatischen Steuerung von Richtlinien in einer Google Cloud Organisation. Weitere Informationen finden Sie unter Repositories taggen.

Weitere Informationen

• Standard-Repositories erstellen
• Weitere Informationen zu Remote-Repositories
• Weitere Informationen zu virtuellen Repositories
• Remote-Repositories erstellen
• Virtuelle Repositories erstellen