Containerkonzepte

Mit Artifact Registry können Sie Container-Images und andere Artefakte in Repositories speichern und organisieren, um Arbeitslasten in verschiedenen Umgebungen zu verwalten und bereitzustellen. Sie können Image-Ebenen, Tags und Manifest-Digests verwenden, um die Versionsverwaltung von Images zu steuern und Bereitstellungen zu verwalten.

Die Artifact Registry-Beispiele auf dieser Seite beziehen sich hauptsächlich auf Repositorys im Docker-Format. Weitere Informationen finden Sie unter Unterstützte Formate und in der Repository-Übersicht.

Registries

In einer Registry werden Container-Images und Artefakte gespeichert und verteilt, die nach Namen in Repositories organisiert sind. Eine Registry kann ein einzelnes oder mehrere Repositories enthalten und öffentlich oder privat sein.

Registrierungsdienste wie Docker Hub und Artifact Registry bieten Optionen zum Erstellen öffentlicher oder privater Repositories. Beim Abrufen öffentlicher Bilder ist es wichtig, die möglichen Sicherheitsrisiken zu kennen. Weitere Informationen zur Überwachung von Sicherheitslücken und zur Reduzierung des Abhängigkeitsumfangs finden Sie unter Abhängigkeitsverwaltung.

Registries sind in Repositories unterteilt, in denen einzelne Container-Images gespeichert werden. Mit Artifact Registry können Sie mehrere Repositories in einem einzelnen Projekt erstellen und jedem Repository einen bestimmten regionalen oder multiregionalen Standort zuweisen. Zugehörige Repositories können nach Labels gruppiert werden.

Artifact Registry-Repositories und Image-Verwaltung

In Artifact Registry-Repositories im Docker-Format können Sie mehrere Container-Images mit unterschiedlichen Namen im selben Repository speichern. Jede Version eines Bildes wird durch ihren Digest identifiziert und kann mit einem Tag verknüpft werden. Tags können veränderlich oder unveränderlich sein. Weitere Informationen zu Container-Image-Versionen und ‑Tags finden Sie unter Container-Image-Versionen.

In Artifact Registry wird in der Regel auf Teile des Pfads zu einem Image verwiesen, um das Projekt, den regionalen oder multiregionalen Speicherort und den Namen des Images zusammen mit dem Tag oder Manifest-Digest zu identifizieren, um die richtige Version zu finden.

Beispiel:

docker push us-west1-docker.pkg.dev/PROJECT/quickstart-docker-repo/quickstart-image:tag1

  • us-west1 ist der Speicherort des Repositorys.
  • docker.pkg.dev ist der Hostname für Repositories im Docker-Format.
  • PROJECT ist der Namespace, der von IhrerGoogle Cloud-Projekt-ID erstellt wurde.
  • quickstart-docker-repo ist der Namespace in Ihrem Projekt, in dem Sie Bilder speichern. In Artifact Registry wird dieser Teil des Pfads als Repository bezeichnet.
  • quickstart-image ist der Name für alle Versionen von quickstart-image und wird oft als das Bild bezeichnet.
  • tag1 ist das Tag, das die Version des Bildes angibt.

Bilder

Sowohl Artefakte als auch Images können in Artifact Registry gespeichert werden. Ein Artefakt kann alles sein: eine Textdatei, ein Docker-Image oder ein Helm-Diagramm. Ein Image bezieht sich in der Regel auf ein Container-Image. Container-Images sind Softwarepakete, die alle Elemente enthalten, die zur Ausführung in beliebigen Umgebungen erforderlich sind. Weitere Informationen finden Sie unter Was sind Container?.

Images werden in Repositories gepusht oder hochgeladen und aus Repositories gezogen oder heruntergeladen. Damit das richtige Image und die richtige Version angegeben werden, müssen die eindeutige Registry und das eindeutige Artefakt angegeben werden.

Weitere Informationen zu Repository- und Imagenamen in Artifact Registry finden Sie unter Repository- und Imagenamen.

Ebenen

In Repositories gespeicherte Container-Images werden inkrementell mithilfe von Ebenen erstellt. Verschiedene Bilder können einige der gleichen Ebenen verwenden. Ebenen werden je nach Bildtyp unterschiedlich definiert. Beispielsweise entspricht jede Anweisung in einem Dockerfile einer Ebene im Docker-Image. In einer Registry werden Images mit gemeinsamen Layern gemeinsam genutzt, was die Speichereffizienz erhöht. Aus Sicherheitsgründen werden Ebenen nicht für verschiedene Registrierungen freigegeben.

Wenn Sie ein Container-Image löschen, werden die Ebenen nicht sofort gelöscht. Ebenen, auf die in der Registry nicht verwiesen wird, werden täglich gelöscht.

Tags

Nutzer fügen Tags hinzu, wenn sie ein Image in ein Repository übertragen oder daraus abrufen, um die Version eines Images anzugeben. Ein Bild kann ein oder mehrere Tags oder gar keine Tags haben. Wenn Sie veränderliche Tags verwenden und ein Image zweimal mit demselben Tag übertragen, wird das Tag aus dem ersten Image entfernt und in das zweite Image verschoben. Das erste Image hat dann kein Tag mehr. Auf das nicht getaggte Image kann weiterhin über die Manifest-Digests zugegriffen werden.

Wenn Sie unveränderliche Tags verwenden, sind die folgenden Aktionen nicht zulässig:

  • Ein getaggtes Bild löschen Das Löschen von Bildern ohne Tag ist weiterhin zulässig.
  • Tag aus einem Bild entfernen
  • Sie pushen ein Image mit einem Tag, das bereits von einer anderen Version des Images im Repository verwendet wird.

Das latest-Tag ist ein spezielles Tag, das angehängt wird, wenn Bilder ohne Tag gepusht werden.

Beispiel:

docker push us-west1-docker.pkg.dev/my-project/my-repo/hello-app

überträgt das Bild per Push an hello-app:latest

docker pull us-west1-docker.pkg.dev/my-project/my-repo/hello-app

ruft das Image hello-app:latest ab.

Wichtig: Wenn ein Image mit einem anderen Tag als latest in ein Repository übertragen wird, wird das Tag latest nicht hinzugefügt. Daher kann es sein, dass das latest-Image nicht auf dem neuesten Stand ist. Wir haben empfohlen, für Releases andere Tags als latest zu verwenden.

Manifeste

Image-Manifeste identifizieren die Layer in jedem Image eindeutig und geben sie an. Manifeste werden durch eindeutige SHA‑256-Hashes identifiziert, die als Manifest-Digests bezeichnet werden. Manifest-Digests sind zuverlässiger und sicherer als Tags, da in Repositories mit veränderlichen Tags mehrere Versionen desselben Images mit demselben Tag gepusht werden können. Dadurch bleiben einige Images ohne Tags, während jedes Image eindeutig durch seinen Manifest-Digest angegeben wird.

Wenn Sie Tools zum Scannen oder Analysieren von Bildern verwenden, sind die Ergebnisse dieser Tools nur für das gescannte Bild gültig. Um sicherzustellen, dass Sie das gescannte Image bereitstellen, können Sie sich nicht auf das Tag verlassen, da sich das Image, auf das das Tag verweist, möglicherweise ändert.

Weitere Informationen zu Artifact Registry-spezifischen Tags und Manifesten finden Sie unter Images verwalten und Container-Images verwenden.

Vorab-Aufwärmen von Bildern

Bei latenzempfindlichen Anwendungen, die Image-Streaming verwenden, kann das Warten auf das erste Abrufen eines Images auf einem neuen Knoten oder einer neuen Instanz, das oft als „Kaltstart“ bezeichnet wird, zu unerwünschten Verzögerungen führen. Mit Prewarming können Sie das Herunterladen von Bildern in den Image-Streaming-Cache explizit starten, bevor sie angefordert werden. So wird sichergestellt, dass Ihr Image für die schnelle Bereitstellung verfügbar ist, wenn es von Ihrem GKE-Cluster angefordert wird.

Verwenden Sie die Artifact Registry API, um Images vorzubereiten. Eine Anleitung finden Sie unter Latenz mit Image-Prewarming reduzieren.

Nächste Schritte