Repository-Übersicht

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 Artefaktformat verknüpft. 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 können Sie den Repository-Modus nach dem Erstellen eines Repositorys nicht mehr ändern.

Standard-Repository

Standard-Repositories sind reguläre Artifact Registry-Repositories für Ihre privaten Artefakte. Sie laden Artefakte direkt in diese Repositorys hoch und herunter 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 zum Speichern von Artefakten aus den folgenden Upstream-Quellen dienen:

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

Wenn Sie zum ersten Mal eine Artefaktversion anfordern, wird sie vom Repository aus der Upstream-Quelle heruntergeladen und eine Kopie davon wird im Cache gespeichert. Das Remote-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 auf Google Cloud. Sie können die Artefaktanalyse auch verwenden, um im Cache gespeicherte Pakete nach Sicherheitslücken und anderen Metadaten zu durchsuchen.

Weitere Informationen zu Remote-Repositories finden Sie unter Übersicht über Remote-Repositories. Wenn Sie Remote-Repositories erstellen möchten, folgen Sie der Anleitung unter Remote-Repositories erstellen.

Virtuelles Repository

Ein schreibgeschütztes Repository, das als zentraler Zugriffspunkt zum Herunterladen, Installieren oder Bereitstellen von Artefakten desselben Formats aus einem oder mehreren Upstream-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 Verwechslung von Abhängigkeiten abwehren, indem Sie Ihre Upstream-Richtlinie so konfigurieren, dass Repositories mit Ihren privaten Artefakten gegenüber Remote-Repositories, in denen öffentliche Artefakte zwischengespeichert werden, priorisiert werden.

Weitere Informationen zu virtuellen Repositories finden Sie unter Virtuelle Repositories. So erstellen Sie virtuelle Repositories

Beispiel für die Verwendung des Repositorys

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

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

   Beim Build wird das virtuelle Maven-Repository verwendet, um die Anwendung herunterzuladen. Das virtuelle Repository stellt das Paket aus dem Standardrepository im Entwicklungsprojekt bereit. Beim 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 Upstream-Standard-Docker-Repository bietet private Images, z. B. die containerisierte Java-Anwendung.
   • Das Upstream-Remote-Repository enthält Images, die von GKE von Docker Hub angefordert werden.

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

Speicherort des Repositories

Überlegungen zum Standort

In diesem Abschnitt wird beschrieben, warum Sie möglicherweise ein Repository in derselben Region wie andere Google Cloud -Dienste erstellen möchten.

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 ausgehenden Traffic von Artifact Registry zu anderen Google Cloud -Diensten in derselben Region fallen keine Kosten an.

Obwohl für ausgehenden Traffic von einer multiregionalen zu einerGoogle Cloud -Dienstinstanz in einer entsprechenden Region keine Gebühren anfallen, gilt diese Preisgestaltung nur für eine begrenzte Anzahl von Regionen.

• Für die Multiregion us wird ausgehender Traffic zu einer Region in den USA wie us-central nicht berechnet, zu einer Region in Kanada oder Südamerika jedoch schon.
• Für die multiregionale asia-Region wird für ausgehenden Traffic zu Regionen in Asien wie asia-northeast1 keine Gebühr berechnet, für ausgehenden Traffic zu Regionen in Australien jedoch schon.

Berücksichtigen Sie den Standort von Verbrauchern außerhalb von Google Cloud. Wenn Ihr Entwicklerteam in Australien beispielsweise Artefakte aus Artifact Registry auf seine lokalen Workstations herunterladen muss, werden durch ein Repository in einer australischen Region die Latenzzeit und die Egress-Gebühren im Vergleich zu einem Repository auf einem anderen Kontinent reduziert.

Repository-Speicherorte einschränken

Wenn Sie Vorschriften oder Richtlinien einhalten müssen, die die Speicherung von Daten in bestimmten Regionen vorschreiben, können Sie eine Einschränkung für Ressourcenstandorte in Ihre Google Cloud-Organisationsrichtlinie aufnehmen, die die Erstellung von Repositorys 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 Standort verschieben und das nicht konforme Repository dann löschen.

Bereinigungsrichtlinien

In einer Bereinigungsrichtlinie für Artifact Registry werden Kriterien für das automatische Löschen von Artefaktversionen definiert, die Sie nicht mehr benötigen, oder für das Beibehalten 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 behalten müssen, die Sie für die Produktion freigeben. Sie können Löschrichtlinien mit Kriterien zum Löschen von Artefakten und Aufbewahrungsrichtlinien mit Kriterien zum Beibehalten von Artefakten definieren.

Wenn eine Artefaktversion den Kriterien sowohl einer Löschrichtlinie als auch einer Aufbewahrungsrichtlinie entspricht, wendet Artifact Registry die Aufbewahrungsrichtlinie an.

Richtlinien löschen

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

• Tag-Status: Gibt an, ob die Richtlinie nach Artefakten mit oder ohne Tag suchen soll. Artefakte werden beim Pushen oder Pullen eines Images in bzw. aus einem Repository getaggt. Weitere Informationen zu Docker-Tags finden Sie unter Containerkonzepte.

  • Beliebiger Tag-Status: Der Tag-Status wird ignoriert. Die Option gilt sowohl für Artefakte mit als auch ohne Tag.
  • Getaggt: Gilt nur für getaggte Artefakte.
  • Nicht getaggt: Gilt nur für nicht getaggte Artefakte.

  Formate, die keine Tags unterstützen, werden als untagged behandelt. Artefakte mit Tags in Repositories, in denen unveränderliche Tags aktiviert sind, können nicht gelöscht werden.

  Weitere Informationen zum Tag-Status in Bezug auf Bereinigungsrichtlinien finden Sie in der TagState-Referenz.

Sie haben folgende optionale 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: - ist eine durch Kommas getrennte Liste von Artefaktversionspräfixen. Beispiel: v1, v2 würde mit den Versionen v1.5, v2.0alpha und v10.2 übereinstimmen.
• Paketpräfixe: Eine Liste mit Präfixen für Artefaktnamen. 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. Sie stimmen mit den Artefaktnamen red-team, redis und bluebird überein.
• Älter als: Gibt die Mindestzeit seit dem Hochladen einer Artefaktversion in das Repository als Dauer an. Beispiel: 30d entspricht 30 Tagen. Sie können die Dauer in Sekunden, Minuten, Stunden oder Tagen angeben, indem Sie s, m, h oder d anhängen.
• Newer than (Jünger als): Gibt die maximale Zeit seit dem Hochladen einer Artefaktversion in das Repository als Dauer an. Beispiel: 30d entspricht 30 Tagen.

Richtlinien beibehalten

Mit Richtlinien zur Datenbeibehaltung werden Artefakte beibehalten, die denselben Bedingungen wie Richtlinien zum Löschen entsprechen, oder eine bestimmte 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 festgelegt ist, dass drei Versionen von Paketen beibehalten werden, die mit den Paketpräfixen {release-xyz} übereinstimmen, werden nur release-xyz-v1 und release-xyz-v2 beibehalten.

Löschungen, die durch Löschrichtlinien ausgelöst werden, werden auf Ihr Kontingent für Löschanträge pro Projekt für Artifact Registry angerechnet.

Informationen zum Erstellen und Anwenden von Bereinigungsrichtlinien für 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 Ihrer vorhandenen Automatisierung und Ihren Workflows zu minimieren. Diese Repositories bieten:

• Weiterleitung von Anfragen an die Domain gcr.io.
• Erstellung von gcr.io-Repositories, wenn das erste Image per Push-Befehl an einen gcr.io-Hostname gesendet wird, um die Kompatibilität mit dem Verhalten von Container Registry zu gewährleisten.

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. Welche Struktur Sie auswählen, hängt von Faktoren wie Data Governance-Anforderungen, Vertrauensgrenzen und der Teamstruktur ab.

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

Repositories zentralisieren

Erstellen Sie alle Repositories in einem einzigen Projekt und gewähren Sie dann Zugriff auf Prinzipale aus anderen Projekten auf Repository-Ebene. Dieses Vorgehen kann effektiver sein, wenn eine einzelne Person oder ein Team die Repository-Administration und den Repository-Zugriff in Ihrer Organisation übernimmt.

Außerdem kann die Einrichtung virtueller Repositories 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 auf Projektebene und eine bessere Kontrolle von Ressourcen erfordern.

Zugriffssteuerung

Auf Repositories kann nur mit den entsprechenden Berechtigungen zugegriffen werden, es sei denn, Sie konfigurieren das Repository für ö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 explizit Zugriff auf Repositories gewähren, wenn:

• Artifact Registry befindet sich in einem anderen Projekt als der Dienst, der mit ihr 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.

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

• Sie stellen Container-Images in Artifact Registry in GKE-Clustern in verschiedenen Projekten bereit. Das Dienstkonto für Knoten in diesen Clustern benötigt nur Lesezugriff auf Repositories.
• Sie haben ein Entwicklungsrepository für Anwendungen, die sich in der Entwicklung befinden, und ein Produktionsrepository für veröffentlichte Anwendungen. Entwickler benötigen Lese- und Schreibzugriff auf das Entwicklungs-Repository und nur 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 Artefaktdownloads mit Downloadregeln einschränken. Mit Downloadregeln können Sie das Herunterladen 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 Artefaktdownloads einschränken in der Übersicht unter „Zugriff steuern und Artefakte schützen“.

Datenverschlüsselung

Standardmäßig Google Cloud automatisch verschlüsseltDaten im inaktiven Zustand mit von Google verwalteten Verschlüsselungsschlüsseln. Wenn Sie bestimmte Compliance- oder gesetzliche Anforderungen für die Schlüssel zum Schutz Ihrer Daten erfüllen müssen, 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 CMEK zum Schutz von Ressourcen erfordern können.

Labels und Tags

Mit Labels können Sie Ressourcen organisieren, die für einen bestimmten Google Cloud-Dienst relevant sind. In Artifact Registry können Sie Repositories Labels hinzufügen, um sie zu gruppieren oder Repository-Listen nach Label zu filtern. Sie können beispielsweise Labels verwenden, um Repositorys nach Entwicklungsphase oder nach Team für Automatisierungs- oder Abrechnungszwecke 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. Labels dienen in erster Linie zum Organisieren und Filtern dienstspezifischer Ressourcen, während Tags für die programmatische Steuerung von Richtlinien in einer Google Cloud -Organisation verwendet werden. 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