Repository-Übersicht

Artifact Registry ermöglicht das Speichern verschiedener Artefakttypen, das Erstellen mehrerer Repositories in einem einzelnen Projekt und das Verknüpfen einer bestimmtenRegion oder Mehrfachregionmit 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

Jedes Repository ist mit einem bestimmten Artefakt verknüpft format an. Beispiel: Ein Docker-Repository Docker-Images speichert. Sie können mehrere Repositories für jedes Format in im selben Google Cloud-Projekt.

Repository-Modi

Es gibt mehrere Repository-Modi. Jeder Modus hat einen anderen Zweck. Der Repository-Modus kann also 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.
Remote-Repository

Ein schreibgeschütztes Repository, das als Proxy dient, um 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 zu speichern. Wenn Sie zum ersten Mal eine Artefaktversion anfordern, wird sie vom Repository aus der externen Quelle heruntergeladen und eine Kopie davon im Cache gespeichert. Das Repository stellt die im Cache gespeicherte Kopie bereit, wenn dasselbe Version erneut angefordert wird.

Remote-Repositories reduzieren die Latenz und verbessern die Verfügbarkeit für Builds und Bereitstellungen in Google Cloud. Sie können auch Artefaktanalyse zum Scannen von im Cache gespeicherten Paketen auf Sicherheitslücken und andere Metadaten.

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 zwischengespeichert werden.

Beispiel für die Repository-Nutzung

Das folgende Diagramm zeigt eine von vielen Möglichkeiten zur Verwendung von Repositories in verschiedenen Modi zusammen. Das Diagramm zeigt einen Workflow in zwei Google Cloud-Projekten. In einem Entwicklungsprojekt erstellen Entwickelnde . In einem separaten Laufzeitprojekt erstellt ein anderer Build einen Container Image mit der Anwendung für die Bereitstellung in Google Kubernetes Engine.

Standard-, virtuelle und Remote-Repositories, die in zwei Projekten verwendet werden.

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

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

  2. Im Laufzeitprojekt containerisiert Cloud Build die Java- .

    Für den Build wird das virtuelle Maven-Repository verwendet, um die Anwendung herunterzuladen. Die virtuelles Repository stellt das Paket aus dem Standard-Repository in des Entwicklungsprojekts. Der Build kann auch öffentliche Java-Anwendungen herunterladen aus demselben virtuellen Repository abrufen.

  3. Cloud Build lädt den erstellten Container im Laufzeitprojekt hoch. in ein Standard-Docker-Repository zu übertragen.

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

    • Das Upstream-Standard-Docker-Repository stellt private Images bereit, z. B. der containerisierten Java-Anwendung.
    • Das vorgelagerte Remote-Repository stellt Images bereit, die von der GKE -Anfragen von Docker Hub.

In diesem Beispiel befinden sich alle Repositories, Builds und GKE-Cluster in derselben Region. Denselben Standort für Google Cloud-Dienste verwenden hat Vorteile, die unter Speicherort des Repositorys beschrieben werden.

Speicherort des Repositories

Sie können ein oder mehrere Repositories in einem unterstützten Region oder Multiregion . Gute Balance zwischen Repository-Standorten Latenz, Verfügbarkeit und Bandbreitenkosten für Datennutzer. Möglicherweise hat Ihre Organisation auch bestimmte Compliance-Anforderungen.

Überlegungen zum Standort

Das Erstellen eines Repositories in derselben Region wie andere Google Cloud-Dienste bietet eine Reihe von Vorteilen:

  • Reduzieren Sie die Latenz und die Kosten für ausgehenden Netzwerktraffic, 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 ausgehenden Traffic von Artifact Registry an andere Google Cloud-Dienste in derselben Region wird keine Gebühr erhoben.

    Auch wenn für ausgehenden Traffic von einem multiregionalen Standort zu einem Google Cloud-Dienst in einer entsprechenden Region, nur diese Preise für eine begrenzte Anzahl von Regionen gilt.

    • Für den multiregionalen Standort us wird ausgehender Traffic an eine Region in den USA wie us-central wird nicht berechnet, in einer Region in Kanada oder Südamerika geladen wurde.
    • 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 Image-Streaming nur in GKE verwenden und Dataproc Serverless , wenn Ihre Container-Images in Artifact Registry gespeichert sind Repositories in derselben Region wie Ihre Arbeitslasten oder an einem entspricht der Region mit Ihren Arbeitslasten. 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 der Nutzer außerhalb von Google Cloud. Für Wenn Ihr Entwicklerteam in Australien Artefakte von Artifact Registry auf ihre lokalen Workstations übertragen, in Australien können Sie die Latenz reduzieren und die Gebühren für ausgehenden Traffic senken. als 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 Cloud-Organisationsrichtlinie eine Einschränkung für Ressourcenstandorte angeben, die das Erstellen von Repositories nur in konformen Regionen zulässt. Artifact Registry erzwingt die Einschränkung erst, nachdem Sie sie aufgenommen haben in Ihrer Organisationsrichtlinie. 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

In einer Artifact Registry-Bereinigungsrichtlinie sind Kriterien für das automatische Löschen definiert Artefaktversionen, die Sie nicht mehr benötigen, oder Artefakte, die Sie behalten möchten speichern können.

Bereinigungsrichtlinien sind nützlich, wenn Sie viele Versionen Ihrer Artefakte speichern, aber Sie müssen nur bestimmte Versionen beibehalten, die Sie für die Produktion veröffentlichen. 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 Artefakten oder nicht getaggte Artefakte. Artefakte werden beim Hoch- oder Herunterladen eines Images auf oder aus einem Repository stammen. 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 nicht getaggte Artefakte.
    • Getaggt: gilt nur für getaggte Artefakte.
    • Ungetaggt: Gilt nur für Artefakte ohne Tags.

    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 können die Löschrichtlinie folgendermaßen definieren:

  • Tag-Präfixe: ist eine durch Kommas getrennte Liste von Tag-Präfixe. 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. So würde z. B. v1 und v2 den Versionen v1.5 entsprechen, v2.0alpha und v10.2.
  • Paketpräfixe: Liste der Präfixe für Artefaktenamen. Sie können 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, die den Artefaktnamen red-team, redis und bluebird entsprechen.
  • Ä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 eine Dauer in Sekunden, Minuten, Stunden oder Tage durch Anfügen von s, m, h bzw. d an.
  • 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. Beispiel: 30d entspricht 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.

Angenommen, ein Repository enthält die folgenden Artefakte:

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 Hosting von Images in der Domain gcr.io. Wenn Sie von Container Registry auf Artifact Registry umstellen, können Sie gcr.io-Repositories und Artifact Registry, um Änderungen an vorhandenen Automatisierung und Workflows. Diese Repositories bieten Folgendes:

  • Weiterleitung von Anfragen an die Domain gcr.io
  • Erstellen von gcr.io-Repositories, wenn das erste Image auf einen gcr.io übertragen wird Hostname für die Kompatibilität mit Container Registry-Verhalten.

Weitere Informationen finden Sie unter Umstellung auf Repositories mit Unterstützung der gcr.io-Domain

Projektstruktur

Mit der Ressourcenhierarchie organisieren Sie Ihre Ressourcen in Google Cloud-Projekten. Welche Struktur Sie wählen, hängt davon ab, Faktoren wie Data-Governance-Anforderungen, Vertrauensgrenzen und Team Struktur.

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 Zugriff auf Hauptkonten aus anderen Projekten auf Repository-Ebene. 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 lassen sich damit virtuelle Repositories oder Lösungen wie Software Delivery Shield, da nur eine Instanz aktiviert und verwaltet werden muss von Artifact Registry.
Projektspezifische Repositories
Erstellen Sie Repositories in Projekten, in denen Artefakte gespeichert und heruntergeladen werden. Dieses kann erforderlich sein, wenn Sie Data-Governance-Richtlinien oder Vertrauensgrenzen, die eine stärkere Trennung und Kontrolle von Ressourcen.

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 auf Projekt- oder Repository-Ebene.

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 explizit diese Dienste greifen in folgenden Fällen auf Repositories zu:

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

Bei anderen Hauptkonten, die Zugriff auf Repositories benötigen, Administrator muss 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 bereit Clustern in verschiedenen Projekten. Das Dienstkonto für Knoten in diesen Clustern 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.

Artefaktdownloads einschränken

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 verschlüsselt Google Cloud Daten automatisch, wenn sie Schlüssel, die Google gehören und von Google verwaltet werden. Wenn Sie bestimmte Compliance- oder regulatorische in Bezug auf die Schlüssel, die Ihre Daten schützen, können Sie Repositories, die mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEKs) 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

Mithilfe von Labels können Sie Ressourcen organisieren, die einem Google Cloud-Dienst zugewiesen sind. In Artifact Registry können Sie Repositories Labels hinzufügen, können Sie sie gruppieren oder Repository-Listen nach Label filtern. Sie können beispielsweise Repositories nach Entwicklungsphase oder Team für Automatisierungs- oder Abrechnungszwecke gruppieren. Weitere Informationen zum Erstellen und Verwenden Repository-Labels finden Sie unter Repositories mit Labels versehen.

Sie können Repositories auch Tags zuweisen. Obwohl Labels in erster Linie für zum Organisieren und Filtern dienstspezifischer Ressourcen, sind Tags für die programmatische Nachfrage. Kontrolle über Richtlinien in einer Google Cloud-Organisation. Weitere Informationen finden Sie unter Repositories taggen.

Weitere Informationen