Repository-Übersicht

Mit Artifact Registry können Sie verschiedene Artefakttypen speichern, mehrere Repositories in einem einzelnen Projekt erstellen und jedem Repository eine bestimmte- oder multiregionalezuordnen. 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 einem bestimmten Artefaktformat zugeordnet. Ein Docker-Repository speichert beispielsweise Docker-Images. Sie können im selben Google Cloud-Projekt mehrere Repositories für jedes Format erstellen.

Repository-Modi

Es gibt mehrere Repository-Modi. Jeder Modus dient einem anderen Zweck. Sie können den Repository-Modus also nicht mehr ändern, nachdem Sie ein Repository erstellt haben.

Standard-Repository
Standard-Repositories sind reguläre Artifact Registry-Repositories für Ihre privaten Artefakte. Artefakte werden direkt mit diesen Repositories hoch- und heruntergeladen und Sie verwenden die Artefaktanalyse, um nach Sicherheitslücken und anderen Metadaten zu suchen.
Remote-Repository

Ein schreibgeschütztes Repository, das als Proxy zum Speichern von Artefakten aus voreingestellten externen Quellen wie Docker Hub, Maven Central, dem Python Package Index (PyPI), Debian oder CentOS sowie benutzerdefinierten Quellen für unterstützte Formate dient. Wenn Sie eine Artefaktversion zum ersten Mal anfordern, lädt das Repository sie von der externen Quelle herunter und speichert eine Kopie davon im Cache. Das Repository stellt die im Cache gespeicherte Kopie bereit, wenn dieselbe Version noch einmal angefordert wird.

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

Virtuelles Repository

Ein schreibgeschütztes Repository, das als einzelner Zugangspunkt zum Herunterladen, Installieren oder Bereitstellen von Artefakten desselben Formats aus einem oder mehreren vorgelagerten Repositories dient. 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 Angriffe durch Abhängigkeitsverwirrung abschwächen, indem Sie Ihre Upstream-Richtlinie so konfigurieren, dass Repositories mit Ihren privaten Artefakten gegenüber Remote-Repositories priorisiert werden, die öffentliche Artefakte im Cache speichern.

Beispiel für die Verwendung von Repositories

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 zwei Google Cloud-Projekte. In einem Entwicklungsprojekt erstellen Entwickler eine Java-Anwendung. In einem separaten Laufzeitprojekt erstellt ein anderer Build ein Container-Image mit der Anwendung zur Bereitstellung in Google Kubernetes Engine.

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

  1. Im Entwicklungsprojekt verwendet ein Java-Entwicklungsteam 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 vom Remote-Repository bereit, das ein Caching-Proxy für Maven Central ist.
    • Cloud Build lädt das Paket in das Maven-Standard-Repository im Komponentenprojekt hoch.

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

    Der Build verwendet das virtuelle Maven-Repository zum Herunterladen der Anwendung. Das virtuelle Repository stellt das Paket aus dem Standard-Repository im Entwicklungsprojekt bereit. Mit dem Build können auch öffentliche Java-Abhängigkeiten aus demselben virtuellen Repository heruntergeladen werden.

  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 vorgelagerte Docker-Standard-Repository stellt private Images wie die containerisierte Java-Anwendung bereit.
    • Das vorgelagerte 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 Standorts für Google Cloud-Dienste hat Vorteile, die unter Speicherort des Repositorys beschrieben werden.

Speicherort des Repositories

Sie können ein oder mehrere Repositories in einer unterstützten -Region oder einer multiregionalen erstellen. Ein guter Repository-Standort sorgt für ein Gleichgewicht zwischen Latenz, Verfügbarkeit und Bandbreitenkosten für Datennutzer. Ihre Organisation hat möglicherweise auch bestimmte Compliance-Anforderungen.

Überlegungen zum Standort

Ein Repository in derselben Region wie andere Google Cloud-Dienste zu erstellen, 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 auch GKE, Cloud Run, Cloud Build und andere Google Cloud-Dienste ausführen, die mit dem Repository interagieren. Für ausgehenden Traffic von Artifact Registry zu anderen Google Cloud-Diensten in derselben Region fallen keine Kosten an.

    Obwohl für ausgehenden Traffic von einem multiregionalen Standort zu einem Google Cloud-Dienst in einer entsprechenden Region keine Gebühren anfallen, gelten diese Preise nur für eine begrenzte Anzahl von Regionen.

    • Für den multiregionalen Standort us wird ausgehender Traffic in eine Region in den USA wie us-central nicht berechnet. Der ausgehende Traffic in eine Region in Kanada oder Südamerika wird in Rechnung gestellt.
    • Für den multiregionalen Standort asia wird der ausgehende Traffic zu Regionen in Asien, z. B. asia-northeast1, nicht berechnet. Ausgehender Traffic in Regionen in Australien wird hingegen in Rechnung gestellt.

  • Sie können Image-Streaming in GKE und Dataproc Serverless nur verwenden, wenn Ihre Container-Images in Artifact Registry-Repositories in derselben Region wie Ihre Arbeitslasten oder einer Multiregion gespeichert sind. Durch Image-Streaming kann die Initialisierungszeit der Arbeitslast erheblich reduziert werden, wenn Sie größere Container-Images verwenden, da Arbeitslasten gestartet werden können, bevor das gesamte Image heruntergeladen wurde.

  • Berücksichtigen Sie den Standort von Nutzern außerhalb von Google Cloud. Wenn Ihr Entwicklerteam in Australien beispielsweise Artefakte von Artifact Registry auf ihre lokalen Workstations herunterladen muss, reduziert ein Repository in einer australischen Region die Latenz und verursacht niedrigere Gebühren für ausgehenden Traffic als für ein Repository auf einem anderen Kontinent.

Repository-Standorte einschränken

Wenn Sie Vorschriften oder Richtlinien einhalten müssen, die das Speichern von Daten in bestimmten Regionen vorschreiben, können Sie eine Einschränkung für Ressourcenstandorte in Ihre Google Cloud-Organisationsrichtlinie aufnehmen, die das Erstellen 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 Standorten 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 nicht mehr benötigter Artefaktversionen definiert oder für die Beibehaltung von Artefakten, die Sie auf unbestimmte Zeit speichern möchten.

Bereinigungsrichtlinien sind nützlich, wenn Sie viele Versionen Ihrer Artefakte speichern, aber nur bestimmte Versionen beibehalten müssen, die Sie für die Produktion veröffentlichen. Sie können Löschrichtlinien mit Kriterien zum Löschen von Artefakten und Richtlinien zum Beibehalten mit Kriterien zum Beibehalten von Artefakten definieren.

Wenn eine Artefaktversion den Kriterien in einer Löschrichtlinie und einer Keep-Richtlinie entspricht, wendet Artifact Registry die Keep-Richtlinie an.

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 oder nicht getaggten Artefakten suchen soll. Artefakte werden mit Tags versehen, wenn ein Image in ein Repository oder aus einem Repository übertragen 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.
    • 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 bei Anwendung der 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äfixen. So würden die Präfixe test und staging z. B. Bilder mit den Tags testenv und staging-1.5 entsprechen. tagState muss auf TAGGED gesetzt sein, damit Tag-Präfixe verwendet werden können.
    • Versionspräfixe: – ist eine durch Kommas getrennte Liste von Präfixen für Artefaktversion. Beispielsweise würde v1, v2 den Versionen v1.5, v2.0alpha und v10.2 entsprechen.
  • Paketpräfixe: Eine Liste von Artefaktnamenspräfixen. Sie können mehrere Präfixe eingeben. Drücken Sie dazu Enter oder , zwischen den Präfixen. Zum Beispiel würde red, blue die beiden Präfixe red und blue erstellen und den Artefaktnamen red-team, redis und bluebird entsprechen.
  • Älter als: ist die Mindestzeit, die seit dem Hochladen einer Artefaktversion in das Repository vergangen ist. Sie wird als Dauer angegeben. Beispiel: 30d entspricht 30 Tagen. Sie können eine Dauer in Sekunden, Minuten, Stunden oder Tagen angeben, indem Sie s, m, h bzw. d anhängen.
  • Neuer als: ist die maximale Zeit, die seit dem Hochladen einer Artefaktversion in das Repository vergangen ist. Sie wird als Dauer angegeben. Beispiel: 30d entspricht 30 Tagen.

Richtlinien beibehalten

Mit Richtlinien lassen sich Artefakte, die dieselben Bedingungen wie Löschrichtlinien haben, oder eine bestimmte Anzahl der neuesten Versionen erfüllen.

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 festgelegt ist, dass drei Versionen von Paketen beibehalten werden, die den Paketpräfixen entsprechen: {release-xyz}, nur release-xyz-v1 und release-xyz-v2.

Durch Löschrichtlinien ausgelöste Löschungen werden auf Ihr Artifact Registry pro Projektkontingent für Löschanfragen angerechnet.

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

gcr.io-Domainsupport

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 Artifact Registry für gcr.io-Repositories so einrichten, dass Änderungen an Ihren vorhandenen Automatisierungen und Workflows minimiert werden. Diese Repositories bieten Folgendes:

  • Weiterleitung von Anfragen an die Domain gcr.io.
  • Erstellen von gcr.io-Repositories, wenn das erste Image an einen gcr.io-Hostnamen übertragen wird, um die Kompatibilität mit Container Registry-Verhalten zu gewährleisten.

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

Projektstruktur

Mit der Ressourcenhierarchie können Sie Ihre Ressourcen in Google Cloud-Projekten organisieren. Die von Ihnen gewählte Struktur hängt von Faktoren wie Data-Governance-Anforderungen, Vertrauensgrenzen und Teamstruktur ab.

Es gibt zwei allgemeine Ansätze zum Einrichten von Repositories in Organisationen mit mehreren Projekten.

Repositories zentralisieren
Sie erstellen alle Repositories in einem einzelnen Projekt und gewähren dann Zugriff auf Hauptkonten aus anderen Projekten auf Repository-Ebene. Dieser Ansatz kann effektiver sein, wenn eine einzelne Person oder ein einzelnes Team die Repository-Verwaltung und den Repository-Zugriff in Ihrer Organisation verwaltet.
Außerdem kann die Einrichtung von virtuellen Repositories oder Lösungen wie Software Delivery Shield vereinfacht werden, da Sie nur eine einzige Instanz von Artifact Registry aktivieren und verwalten müssen.
Projektspezifische Repositories
Repositories in Projekten erstellen, in denen Artefakte gespeichert und heruntergeladen werden Dieser Ansatz kann erforderlich sein, wenn Sie Data-Governance-Richtlinien 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 gewähren.

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 Ihrer Organisation. Ihr Repository-Administrator muss diesen Diensten in folgenden Fällen explizit Zugriff auf Repositories gewähren:

  • Artifact Registry befindet sich in einem anderen Projekt als der Dienst, der mit ihm 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 vorgelagerte Repositories gewähren.

Für andere Hauptkonten, die Zugriff auf Repositories benötigen, muss Ihr 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 für GKE-Cluster 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, die sich in der Entwicklung befinden, 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 für das Herunterladen der Demos nur Lesezugriff.

Datenverschlüsselung

Standardmäßig verschlüsselt Google Cloud ruhende Daten automatisch mit Schlüsseln, die Google gehören und von Google verwaltet werden. Wenn Sie bestimmte Compliance- oder regulatorische Anforderungen in Bezug auf die Schlüssel haben, die Ihre Daten schützen, 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, bei denen zum Schutz von Ressourcen ein CMEK erforderlich sein kann.

Labels und Tags

Mit Labels können Sie Ressourcen für einen Google Cloud-Dienst organisieren. In Artifact Registry können Sie Repositories Labels hinzufügen, um sie zu gruppieren oder Repository-Listen nach Label zu filtern. Beispielsweise können Sie Labels verwenden, um Repositories zu Automatisierungs- oder Abrechnungszwecken nach Entwicklungsphase oder nach Team zu gruppieren. Weitere Informationen zum Erstellen und Verwenden von Repository-Labels finden Sie unter Repositories mit Labels versehen.

Sie können auch Tags auf Repositories anwenden. Während Labels in erster Linie zum Organisieren und Filtern dienstspezifischer Ressourcen dienen, dienen Tags zur programmatischen Kontrolle von Richtlinien in einer Google Cloud-Organisation. Weitere Informationen finden Sie unter Repositories taggen.

Weitere Informationen