Containerkonzepte

In diesem Dokument werden wichtige Konzepte im Zusammenhang mit Container-Images vorgestellt, darunter Registries, Repositories und Artefakte. Außerdem sind einige grundlegende Informationen dazu enthalten, wie diese Konzepte auf Artifact Registry und Container Registry angewendet werden.

Die Artifact Registry-Beispiele auf dieser Seite beziehen sich hauptsächlich auf Docker-Format- und gcr.io-Repositories. Weitere Informationen finden Sie unter Unterstützte Formate und die 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 oder mehrere Repositories enthalten und öffentlich oder privat sein.

Registry-Dienste wie Docker Hub und Artifact Registry bieten Optionen zum Erstellen öffentlicher oder privater Repositories. Beim Herunterladen öffentlicher Images ist es wichtig, die möglichen Sicherheitsbedenken zu kennen. Weitere Informationen zur Überwachung von Sicherheitslücken und zur Reduzierung der Abhängigkeiten finden Sie unter Abhängigkeitsverwaltung.

Registries sind in Repositories organisiert, 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 mit 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 Images wird durch ihren Image-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 werden in der Regel Teile des Pfads zu einem Image verwendet, um das Projekt, den regionalen oder multiregionalen Standort, und den Namen des Images sowie den Tag oder den 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 Standort des Repositorys.
  • docker.pkg.dev ist der Hostname für Repositories im Docker-Format.
  • PROJECT ist der Namespace, der von Ihrer Google Cloud Projekt-ID erstellt wurde.
  • quickstart-docker-repo ist der Namespace unter Ihrem Projekt, in dem Sie Images 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 Image bezeichnet.
  • tag1 ist das Tag, das die Version des Images 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 hochgeladen oder per Push übertragen und aus Repositories heruntergeladen oder abgerufen. Um das richtige Image und die richtige Version anzugeben, müssen die eindeutige Registry und das eindeutige Artefakt angegeben werden.

Weitere Informationen zu Repository- und Image-Namen in Artifact Registry, finden Sie unter Repository- und Image-Namen.

Ebenen

Container-Images, die in Repositories gespeichert sind, werden inkrementell mit Ebenen erstellt. Verschiedene Images können einige der gleichen Ebenen verwenden. Ebenen werden je nach Image-Typ unterschiedlich definiert. Beispielsweise entspricht jede Anweisung in einer Dockerfile einer Ebene im Docker-Image. In einer Registry verwenden Images mit gemeinsamen Ebenen diese Ebenen gemeinsam, wodurch die Speichereffizienz erhöht wird. Aus Sicherheitsgründen werden Ebenen nicht über verschiedene Registries hinweg gemeinsam genutzt.

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

Tags

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

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

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

Das Tag latest ist ein spezielles Tag, das angehängt wird, wenn Images ohne Tag hochgeladen werden.

Beispiel:

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

lädt das Image in hello-app:latest hoch.

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

ruft das Image hello-app:latest ab.

Wenn ein Image mit einem anderen Tag als latest in ein Repository hochgeladen wird, wird das Tag latest nicht hinzugefügt. Daher kann es vorkommen, dass das latest-Image nicht die neuesten Änderungen enthält. Wir empfehlen, für Releases andere Tags als latest zu verwenden.

Manifeste

Image-Manifeste identifizieren und geben die Ebenen in jedem Image eindeutig 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 hochgeladen werden können. Dadurch haben einige Images keine Tags, während jedes Image eindeutig durch seinen Manifest-Digest angegeben wird.

Wenn Sie Tools zum Scannen oder Analysieren von Images verwenden, sind die Ergebnisse dieser Tools nur für das gescannte Image 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.

Image-Prewarming

Bei latenzempfindlichen Anwendungen, die Image-Streaming verwenden, kann es zu unerwünschten Verzögerungen kommen, wenn Sie warten müssen, bis ein Image zum ersten Mal auf einem neuen Knoten oder einer neuen Instanz abgerufen wird. Dies wird oft als „Kaltstart“ bezeichnet. Mit Prewarming können Sie das Herunterladen von Images in den Cache für Image-Streaming explizit starten, bevor sie angefordert werden. So ist Ihr Image schnell verfügbar, 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