Repository-Übersicht

Mit Artifact Registry können Sie verschiedene Artefakttypen speichern, mehrere Repositories in einem Projekt zu erstellen und ein bestimmtes Region oder Multiregion 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

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 dient einem anderen Zweck. Sie können den Repository-Modus nicht mehr ändern, nachdem Sie ein Repository erstellt haben.

Standard-Repository
Standard-Repositories sind normale Artifact Registry-Repositories für privaten Artefakten präsentieren. Sie können Artefakte direkt mit diesen Repositories suchen und mithilfe der Artefaktanalyse nach Sicherheitslücken suchen und andere Metadaten.
Remote-Repository

Ein schreibgeschütztes Repository, das als Proxy zum Speichern von Artefakten aus Voreinstellungen dient Externe Quellen wie Docker Hub, Maven Central und der Python-Paketindex (PyPI), Debian oder CentOS sowie benutzerdefinierte Quellen für unterstützte Formaten. Wenn Sie zum ersten Mal eine Artefaktversion erstellt, lädt das Repository aus der externen Quelle herunter speichert eine Kopie davon. 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 schreibgeschütztes Repository, das als zentraler Zugangspunkt zum Herunterladen fungiert, Artefakte desselben Formats aus einem oder mehreren Quellen installieren oder bereitstellen vorgelagerten Repositories. Ein Upstream-Repository kann ein ein Standard-, Remote- oder virtuelles Repository.

Virtuelle Repositories vereinfachen die Clientkonfiguration für Nutzer Ihrer Artefakte. Sie können auch Konflikt mit Abhängigkeiten, indem Sie Ihre Upstream- Richtlinie zur Priorisierung von Repositories mit privaten Artefakten gegenüber Remote-Artefakten Repositories, die öffentliche Artefakte im Cache speichern.

Beispiel für die Verwendung von Repositories

Das folgende Diagramm zeigt eine von vielen Möglichkeiten zur Verwendung von Repositories in verschiedenen Modi zusammen. Das Diagramm zeigt einen Workflow Google Cloud-Projekte 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.

Standardmäßige, virtuelle und Remote-Repositories, die in zwei Projekten verwendet werden.

  1. Im Entwicklungsprojekt nutzt ein Java-Entwicklungsteam Cloud Build zum Erstellen einer Java-Anwendung.

    • 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- .

    Der Build verwendet das virtuelle Maven-Repository zum Herunterladen der Anwendung. 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 sind 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 <ph type="x-smartling-placeholder"></ph> Region oder Multiregion . Gute Balance zwischen Repository-Standorten Latenz, Verfügbarkeit und Bandbreitenkosten für Datennutzer. Ihre Organisation hat möglicherweise auch bestimmte Compliance-Anforderungen.

Überlegungen zum Standort

Repository in derselben Region wie andere Google Cloud-Dienste erstellen hat eine Reihe von Vorteilen:

  • Latenzen und Kosten für ausgehenden Netzwerktraffic durch das Erstellen von Repositories reduzieren in der Sie GKE, Cloud Run, Cloud Build und anderen Google Cloud-Diensten, die mit des Repositorys. Für ausgehenden Traffic von Artifact Registry mit anderen Google Cloud-Diensten im selben Region.

    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 den multiregionalen Standort asia wird ausgehender Traffic an Regionen in Asien wie beispielsweise asia-northeast1 werden nicht berechnet, ausgehender Traffic in Regionen in Australien jedoch geladen wurde.

  • 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. Bildstreaming kann die die Arbeitslastinitialisierung erheblich, wenn größere Container verwendet werden da Arbeitslasten gestartet werden können, bevor das gesamte Image heruntergeladen wurde.

  • Berücksichtigen Sie den Standort von Nutzern 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 Vorschriften oder Richtlinien einhalten müssen, die in bestimmten Regionen enthalten, können Sie Einschränkung der Ressourcenstandorte in Ihrer Google Cloud Organisationsrichtlinie, die das Erstellen von Repositories nur in konformen Regionen zulässt. Artifact Registry erzwingt die Einschränkung erst, nachdem Sie sie eingefügt haben in Ihrer Organisationsrichtlinie. Wenn Sie bereits Repositories in Standorte nicht konform, müssen Sie Ihre Artefakte in ein Repository Speicherort und löschen Sie dann das nicht konforme Repository.

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 behalten, die Sie für die Produktion veröffentlichen. Ich kann Löschrichtlinien mit Kriterien zum Löschen von Artefakten und Richtlinien beibehalten mit Kriterien für die Beibehaltung von Artefakten.

Wenn eine Artefaktversion den Kriterien sowohl in einer Löschrichtlinie als auch in einem Keep entspricht wird die Keep-Richtlinie in Artifact Registry angewendet.

Richtlinien löschen

Durch Löschen von Richtlinien 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 Informationen zum Tag-Status bei den Bereinigungsrichtlinien finden Sie in der TagState-Referenz

Sie können die Löschrichtlinie folgendermaßen definieren:

  • Tag-Präfixe: ist eine durch Kommas getrennte Liste von Tag-Präfixe. So würden z. B. die Präfixe test und staging übereinstimmen Bilder mit den Tags testenv und staging-1.5. tagState muss festgelegt werden auf TAGGED, um Tag-Präfixe zu verwenden.
    • Versionspräfixe: – eine durch Kommas getrennte Liste der Artefaktversion Präfixe. So würde z. B. v1 und v2 den Versionen v1.5 entsprechen, v2.0alpha und v10.2.
  • Paketpräfixe: Eine Liste von Artefaktnamenspräfixen. Sie können Sie können mehrere Präfixe eingeben, indem Sie zwischen den Präfixen Enter oder , drücken. Beispiel: red, blue würde die beiden Präfixe red und blue erstellen. würden den Artefaktnamen red-team, redis, und bluebird.
  • Älter als: Der Mindestzeitraum, in dem ein Die Artefaktversion wurde in das Repository hochgeladen, angegeben als Dauer. Beispiel: 30d entspricht 30 Tagen. Sie können eine Dauer in Sekunden, Minuten, Stunden oder Tage durch Anfügen von s, m, h bzw. d an.
  • Neuer als: gibt die maximale Zeit an, die seit einem Die Artefaktversion wurde in das Repository hochgeladen, angegeben als Dauer. Beispiel: 30d entspricht 30 Tagen.

Richtlinien beibehalten

Sorgen Sie dafür, dass Artefakte die gleichen Bedingungen wie Löschrichtlinien erfüllen, 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 Ihre Richtlinie Neueste Versionen beibehalten so eingestellt ist, dass 3 Versionen Pakete, die mit den Paketpräfixen übereinstimmen: {release-xyz}, nur release-xyz-v1 und release-xyz-v2 werden beibehalten.

Durch Löschrichtlinien ausgelöste Löschungen werden auf Ihre Artifact Registry angerechnet pro Projekt Löschanfragekontingent.

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

gcr.io-Domainsupport

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 zur 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 mit dem Repository Verwaltung und Zugriff auf Repositorys in Ihrer gesamten Organisation.
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
Repositories in Projekten erstellen, 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 Sie 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 eignen sich jedoch möglicherweise nicht für Ihre Software. oder entspricht 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, damit interagieren.
  • Sie verwenden benutzerdefinierte IAM-Rollen mit dem Standarddienst Konten statt der vordefinierten Rolle.
  • Sie verwenden nicht das Standarddienstkonto für die Google Cloud .
  • 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. Prinzip der geringsten Sicherheit Gewähren Sie nur die erforderlichen Mindestberechtigungen. Beispiel:

  • Sie stellen Container-Images in Artifact Registry in GKE bereit in verschiedenen Projekten verwenden. Das Dienstkonto für Knoten in diesen Clustern nur Lesezugriff auf Repositories.
  • Sie haben ein Entwicklungs-Repository für Anwendungen, die sich in der Entwicklung befinden und 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. Nur Ihr Vertriebsteam benötigt Lesezugriff, um die Demos herunterzuladen.

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 zum Schutz Ihrer Daten, 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. für die CMEK zum Schutz von Ressourcen erforderlich sein kann.

Labels und Tags

Mit Labels können Sie Ressourcen für eine Google Cloud organisieren . In Artifact Registry können Sie Repositories Labels hinzufügen, können Sie sie gruppieren oder Repository-Listen nach Label filtern. Beispiel: können Sie mit Labels Repositories nach Entwicklungsphase oder Automatisierung oder Abrechnungszwecke. Weitere Informationen zum Erstellen und Verwenden Repository-Labels finden Sie unter Repositories mit Labels versehen.

Sie können auch Tags auf Repositories anwenden. Obwohl Labels hauptsächlich 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