Container-Image-Digests

In diesem Dokument werden Image-Digests beschrieben. Es wird auch dargelegt, was Image-Digests sind, wie Sie sie finden und wie Sie deren Verwendung in Kubernetes-Clustern durchsetzen. Dieses Dokument richtet sich an Entwickler und Operatoren, die Container-Images erstellen und bereitstellen.

Ein Container-Image-Digest identifiziert ein Container-Image eindeutig und unveränderlich. Wenn Sie Images per Digest bereitstellen, vermeiden Sie die Nachteile der Bereitstellung durch Image-Tags.

Bei den Befehlen in diesem Dokument wird davon ausgegangen, dass Sie Zugriff auf eine Linux- oder macOS-Shell-Umgebung haben, auf der bereits Tools wie die Google Cloud CLI, Docker, cURL, jq und pack installiert sind. Alternativ können Sie Cloud Shell verwenden, wo diese Tools bereits vorinstalliert sind.

Container-Images und Image-Tags

Wenn Sie mit Container-Images arbeiten, benötigen Sie eine Möglichkeit, auf die von Ihnen verwendeten Images zu verweisen. Image-Tags sind eine gängige Methode, um auf verschiedene Überarbeitungen eines Images zu verweisen. Ein gängiger Ansatz besteht darin, Images beim Erstellen mit einer Versionskennung zu taggen. Beispielsweise kann sich v1.0.1 auf eine Version beziehen, die Sie 1.0.1 nennen.

Mit Tags können Sie Ihre Images ganz einfach anhand von menschenlesbaren Strings nachschlagen. Tags sind jedoch änderbare Verweise. Das bedeutet, dass sich das von einem Tag referenzierte Image ändern kann, wie im folgenden Diagramm dargestellt:

Image-Tag, das auf ein veraltetes Image verweist

Wie im vorherigen Diagramm gezeigt: Wenn Sie ein neues Image mit demselben Tag wie ein vorhandenes Image veröffentlichen, verweist das Tag nicht mehr auf das vorhandene Image sondern auf Ihr neues Image.

Nachteile von Image-Tags

Da Tags änderbar sind, haben sie folgende Nachteile, wenn Sie sie zum Bereitstellen eines Images verwenden:

  • In Kubernetes kann das Bereitstellen über Tags zu unerwarteten Ergebnissen führen. Angenommen, Sie haben eine vorhandene Deployment-Ressource, die auf ein Container-Image mit dem Tag v1.0.1 verweist. Zur Behebung eines Fehlers oder zur Durchführung einer kleinen Änderung erstellt der Build-Prozess ein neues Image mit dem gleichen Tag v1.0.1. Neue Pods, die aus Ihrer Deployment-Ressource erstellt werden, können entweder das alte oder das neue Image verwenden, auch wenn Sie die Deployment-Ressourcenspezifikation nicht ändern. Dieses Problem betrifft auch andere Kubernetes-Ressourcen wie StatefulSets, DaemonSets, ReplicaSets und Jobs.

  • Wenn Sie zum Scannen oder Analysieren von Images Tools 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 geändert hat.

  • Wenn Sie die Binärautorisierung mit Google Kubernetes Engine (GKE) verwenden, ist die Tag-basierte Bereitstellung nicht zulässig, da das genaue Image, das beim Erstellen eines Pods verwendet wird, nicht ermittelt werden kann.

Wenn Sie Ihre Images bereitstellen, können Sie einen Image-Digest verwenden, um die Nachteile von Tags zu vermeiden. Sie können Ihren Images auch bei Bedarf Tags hinzufügen. Dies ist jedoch nicht erforderlich.

Struktur eines Images

Ein Image besteht aus den folgenden Komponenten:

Diese Komponenten werden im folgenden Diagramm dargestellt:

Komponenten eines Images mit Informationen für ein Image-Manifest, ein Konfigurationsobjekt, Dateisystem-Layern und einen Image-Index.

Das vorherige Image zeigt zusätzliche Details zu Image-Komponenten:

  • Das Image-Manifest ist ein JSON-Dokument, das einen Verweis auf das Konfigurationsobjekt, die Dateisystem-Layers und optionale Metadaten enthält.
  • Das Image-Manifest verweist auf das Konfigurationsobjekt und die einzelnen Dateisystem-Layer mithilfe ihrer digest-Attribute. Der Wert eines digest-Attributs ist ein kryptografischer Hash der Inhalte, auf die sich der Digest bezieht, und die normalerweise mit dem SHA-256-Algorithmus berechnet werden.
  • Die Digest-Werte werden verwendet, um unveränderliche Adressen für die Objekte zu erstellen. Dieser Vorgang wird als Content-Addressed Storage bezeichnet und bedeutet, dass Sie Image-Manifeste, Image-Indexe, Konfigurationsobjekte und Layer anhand ihrer Digests abrufen können.
  • Der Image-Digest ist der Hash des des Image-Index oder des Image-Manifest-JSON-Dokuments.
  • Das Konfigurationsobjekt ist ein JSON-Dokument, das Attribute des Images definiert, z. B. CPU-Architektur, Einstiegspunkt, verfügbare Ports und Umgebungsvariablen.
  • Das Dateisystemarray definiert die Reihenfolge, in der die Containerlaufzeit die Layer stapelt. Die Layer werden als TAR-Dateien verteilt und in der Regel mit dem Dienstprogramm gzip komprimiert.
  • Der optionale Image-Index, auch als Manifestliste bezeichnet, bezieht sich auf ein oder mehrere Image-Manifeste. Die Referenz ist der Digest des Image-Manifests. Ein Image-Index ist nützlich, wenn Sie mehrere verwandte Images für verschiedene Plattformen wie amd64- und arm64-Architekturen erstellen.

Weitere Informationen finden Sie im Abschnitt Image-Manifeste, -Digests und -Tags kennenlernen.

Image-Digests finden

Sie müssen zuerst den Digest suchen, um Image-Digests für die Bereitstellung zu verwenden. Anschließend können Sie den Digest mit Ihrem Bereitstellungsbefehl verwenden oder in Ihre Kubernetes-Manifeste einfügen.

Sie können den Digest eines Images je nach aktueller Situation auf unterschiedliche Weise abrufen. Die folgenden Abschnitte enthalten Beispiele für verschiedene Produkte und Tools.

Führen Sie in den folgenden Abschnitten die Befehle in Cloud Shell oder in einer Shell-Umgebung aus, in der die gcloud CLI, Docker, cURL und jq bereits installiert sind.

Artifact Registry

  • Für Images, die in Artifact Registry gespeichert sind, können Sie den Befehl gcloud artifacts docker images describe verwenden.

    gcloud artifacts docker images describe \
    LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE:TAG \
    --format 'value(image_summary.digest)'

    Ersetzen Sie Folgendes:

    • LOCATION: der regionale oder multiregionale Standort Ihres Repositorys
    • PROJECT: Ihre Google Cloud-Projekt-ID
    • REPOSITORY: Name Ihres Repositorys
    • IMAGE: Name Ihres Images
    • TAG: Ihr Image-Tag

Container Registry

  • Für Images, die in der Container Registry gespeichert sind, können Sie den Befehl gcloud container images describe verwenden, um den Digest für ein Image abzurufen. Geben Sie dazu den Namen und ein Tag an. Verwenden Sie das Flag --format, um nur den Digest anzuzeigen:

    gcloud container images describe \
    gcr.io/google-containers/pause-amd64:3.2 \
    --format 'value(image_summary.digest)'

    Die Ausgabe sieht etwa so aus, wobei der Digest-Wert variieren kann:

    sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108

Cloud Build

Für Images, die mit Cloud Build erstellt wurden, können Sie den Image Digest mithilfe des Befehls gcloud builds describe mit dem Flag --format abrufen. Dieser Ansatz funktioniert unabhängig von der Registry, die Sie zum Veröffentlichen des Images verwendet haben.

  • Führen Sie für einen bereits abgeschlossenen Build die folgenden Schritte aus:

    1. Rufen Sie eine Liste der Builds für Ihr Projekt ab:

      gcloud builds list

      Notieren Sie sich eine BUILD_ID.

    2. Rufen Sie den Image-Digest ab:

      gcloud builds describe BUILD_ID \
    --format 'value(results.images[0].digest)'

      Ersetzen Sie BUILD_ID durch die eindeutige ID, die Cloud Build Ihrem Build zugewiesen hat.

  • Rufen Sie den Image-Namen und den Digest für den neuesten Build von Cloud Build für Ihr aktuelles Projekt ab:

    gcloud builds describe \
    $(gcloud builds list --limit 1 --format 'value(id)') \
    --format 'value[separator="@"](results.images[0].name,results.images[0].digest)'

  • Wenn Ihr Build mehrere Images erstellt hat, filtern Sie die Ausgabe und erhalten Sie den Digest eines der Images:

    gcloud builds describe BUILD_ID --format json \
    | jq -r '.results.images[] | select(.name=="YOUR_IMAGE_NAME") | .digest'

    Ersetzen Sie YOUR_IMAGE_NAME durch den Namen eines der Images aus der Datei cloudbuild.yaml.

  • Wenn Sie einen Build mit dem Befehl gcloud builds submit an Cloud Build senden, können Sie den Image-Digest der Ausgabe in einer Umgebungsvariablen erfassen:

    IMAGE_DIGEST=$(gcloud builds submit \
    --format 'value(results.images[0].digest)' | tail -n1)

Cloud Native Buildpacks

  • Wenn Sie Cloud Native Buildpacks und den Google Cloud-Builder verwenden, um Images zu erstellen und zu veröffentlichen, können Sie den Image-Namen und den Digest mit dem Flag --quiet und dem Befehl pack erfassen:

    pack build --builder gcr.io/buildpacks/builder:v1 --publish --quiet \
    LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE \
    > image-with-digest.txt

    Ersetzen Sie Folgendes:

    • LOCATION: der regionale oder multiregionale Standort Ihres Repositorys
    • PROJECT_ID: Ihre Google Cloud-Projekt-ID
    • REPOSITORY: Name Ihres Repositorys
    • IMAGE: Name Ihres Images

    Die Datei image-with-digest.txt enthält den Image-Namen und den Digest.

    Verwenden Sie das Flag --tag, wenn Sie dem Image Tags hinzufügen möchten.

Docker-Client

  • Der Unterbefehl manifest des docker-Befehlszeilenclients kann Image-Manifeste und Manifestlisten aus Container-Image-Registries abrufen.

    Rufen Sie den Digest aus der Manifestliste des registry.k8s.io/pause:3.9-Images für die CPU-Architektur amd64 und das Betriebssystem linux ab:

    docker manifest inspect --verbose registry.k8s.io/pause:3.9 | \
    jq -r 'if type=="object"
        then .Descriptor.digest
        else .[] | select(.Descriptor.platform.architecture=="amd64" and
        .Descriptor.platform.os=="linux") | .Descriptor.digest
        end'

    Die Ausgabe sieht dann ungefähr so aus:

    sha256:8d4106c88ec0bd28001e34c975d65175d994072d65341f62a8ab0754b0fafe10

  • Für Images, die in Ihrem lokalen Docker-Daemon gespeichert sind und aus einer Image-Registry abgerufen oder in eine Image-Registry übertragen wurden, können Sie das Docker-Befehlszeilentool zum Abruf des Image-Digest nutzen:

    1. Laden Sie das Image in Ihren lokalen Docker-Daemon herunter:

      docker pull docker.io/library/debian:bookworm

    2. Rufen Sie den Image-Digest ab:

      docker inspect docker.io/library/debian:bookworm \
    | jq -r '.[0].RepoDigests[0]' \
    | cut -d'@' -f2

      Die Ausgabe sieht etwa so aus, wobei der Digest-Wert variieren kann:

      sha256:3d868b5eb908155f3784317b3dda2941df87bbbbaa4608f84881de66d9bb297b

  • Listen Sie alle Images und Digests in Ihrem lokalen Docker-Daemon auf:

    docker images --digests

    Die Ausgabe zeigt Digests für Images mit einem Digest-Wert. Images haben nur dann einen Digest-Wert, wenn sie von einer Image-Registry abgerufen oder in diese verschoben wurden.

crane und gcrane

Mit den Open-Source-Befehlszeilentools crane und gcrane können Sie den Digest eines Images abrufen, ohne das Image an einen lokalen Docker-Daemon zu übertragen.

  1. Laden Sie crane und gcrane in Ihr aktuelles Verzeichnis herunter:

    VERSION=$(curl -sL https://api.github.com/repos/google/go-containerregistry/releases/latest | jq -r .tag_name)
curl -L "https://github.com/google/go-containerregistry/releases/download/${VERSION}/go-containerregistry_$(uname -s)_$(uname -m).tar.gz" | tar -zxf - crane gcrane

  2. Image-Digests abrufen:

    ./gcrane digest gcr.io/distroless/static-debian11:nonroot

    crane und gcrane haben weitere Funktionen, die in diesem Dokument nicht behandelt werden. Weitere Informationen finden Sie in der Dokumentation zu crane und gcrane.

Verwendung von Image-Digests in Kubernetes-Deployments erzwingen

Wenn Sie die Verwendung von Digests für Images, die Sie in Ihren Kubernetes-Clustern bereitstellen, erzwingen möchten, verwenden Sie Policy Controller oder Open Policy Agent (OPA) Gatekeeper, um die Option zu aktivieren. Policy Controller basiert auf dem Open-Source-Projekt OPA Gatekeeper.

Policy Controller und OPA Gatekeeper bauen beide auf der OPA-Richtlinien-Engine auf. Policy Controller und OPA Gatekeeper bieten einen validierenden Zulassungs-Webhooks von Kubernetes zur Durchsetzung von Richtlinien sowie benutzerdefinierte Ressourcendefinitionen (CRDs) für Einschränkungsvorlagen und Einschränkungen.

Einschränkungsvorlagen enthalten Richtlinienlogiken, die mit einer deklarativen Sprache namens Rego ausgedrückt werden. Im Folgenden finden Sie eine Einschränkungsvorlage, die prüft, ob Container, init-Container und sitzungsspezifische Container in einer Kubernetes-Ressourcenspezifikation Images mit Digests nutzen:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8simagedigests
  annotations:
    metadata.gatekeeper.sh/title: "Image Digests"
    metadata.gatekeeper.sh/version: 1.0.1
    description: >-
      Requires container images to contain a digest.

      https://kubernetes.io/docs/concepts/containers/images/
spec:
  crd:
    spec:
      names:
        kind: K8sImageDigests
      validation:
        openAPIV3Schema:
          type: object
          description: >-
            Requires container images to contain a digest.

            https://kubernetes.io/docs/concepts/containers/images/
          properties:
            exemptImages:
              description: >-
                Any container that uses an image that matches an entry in this list will be excluded
                from enforcement. Prefix-matching can be signified with `*`. For example: `my-image-*`.

                It is recommended that users use the fully-qualified Docker image name (e.g. start with a domain name)
                in order to avoid unexpectedly exempting images from an untrusted repository.
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8simagedigests

        import data.lib.exempt_container.is_exempt

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not is_exempt(container)
          not regex.match("@[a-z0-9]+([+._-][a-z0-9]+)*:[a-zA-Z0-9=_-]+", container.image)
          msg := sprintf("container <%v> uses an image without a digest <%v>", [container.name, container.image])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.initContainers[_]
          not is_exempt(container)
          not regex.match("@[a-z0-9]+([+._-][a-z0-9]+)*:[a-zA-Z0-9=_-]+", container.image)
          msg := sprintf("initContainer <%v> uses an image without a digest <%v>", [container.name, container.image])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.ephemeralContainers[_]
          not is_exempt(container)
          not regex.match("@[a-z0-9]+([+._-][a-z0-9]+)*:[a-zA-Z0-9=_-]+", container.image)
          msg := sprintf("ephemeralContainer <%v> uses an image without a digest <%v>", [container.name, container.image])
        }
      libs:
        - |
          package lib.exempt_container

          is_exempt(container) {
              exempt_images := object.get(object.get(input, "parameters", {}), "exemptImages", [])
              img := container.image
              exemption := exempt_images[_]
              _matches_exemption(img, exemption)
          }

          _matches_exemption(img, exemption) {
              not endswith(exemption, "*")
              exemption == img
          }

          _matches_exemption(img, exemption) {
              endswith(exemption, "*")
              prefix := trim_suffix(exemption, "*")
              startswith(img, prefix)
          }

Die vorherige Richtlinie enthält einen regulären Ausdruck als Eingabe für die Funktion re_match. Dieser reguläre Ausdruck entspricht dem Container-Image-Digest und basiert auf dem Digest-Format in der Open Container Initiative Image-Spezifikation.

Einschränkungen wenden die Richtlinie auf Kubernetes-Ressourcen an. Dazu werden sie mit Attributen wie kind und namespace abgeglichen. Die folgende Beispieleinschränkung wendet die Richtlinie aus der Einschränkungsvorlage auf alle Pod-Ressourcen im Namespace default an.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sImageDigests
metadata:
  name: container-image-must-have-digest
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "default"

Nachdem Sie die Einschränkungsvorlage und die Einschränkung erstellt haben, müssen alle neuen Pods im default-Namespace Image Digests verwenden, um auf Container-Images zu verweisen.

Das vollständige Beispiel finden Sie in der Richtlinie der Gatekeeper-Richtlinie in der Richtlinie imagedigests.

Image-Manifeste, -Digests und -Tags

In diesem Abschnitt erfahren Sie, wie Sie vorhandene Images in Registries mit Befehlszeilentools wie curl und docker untersuchen. Führen Sie die Befehle in Cloud Shell oder in einer Shell-Umgebung aus, in der Tools wie gcloud CLI, Docker, cURL und jq bereits installiert sind. Die folgenden Befehle verwenden öffentliche Images in Artifact Registry.

  • Rufen Sie das Manifest des Images gcr.io/google-containers/pause-amd64:3.2 mithilfe von cURL und der Manifest-URL ab:

    curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2

    Die Ausgabe sieht etwa so aus:

    {
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "config": {
      "mediaType": "application/vnd.docker.container.image.v1+json",
      "size": 759,
      "digest": "sha256:80d28bedfe5dec59da9ebf8e6260224ac9008ab5c11dbbe16ee3ba3e4439ac2c"
   },
   "layers": [
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "size": 296534,
         "digest": "sha256:c74f8866df097496217c9f15efe8f8d3db05d19d678a02d01cc7eaed520bb136"
      }
   ]
}

    Der Abschnitt config hat ein Digest-Attribut, mit dem Sie das Konfigurationsobjekt abrufen können. Ebenso hat jedes Layer ein digest-Attribut, mit dem Sie die TAR-Datei für diese Ebene abrufen können.

  • Wenn das Image den optionalen Image-Index enthält, gibt eine HTTP-GET-Anfrage an die Manifest-URL unter Verwendung eines Tags den Image-Index anstelle des Image-Manifests zurück.

    Rufen Sie den Image-Index des Images gcr.io/google-containers/pause:3.2 ab:

    curl -s https://gcr.io/v2/google-containers/pause/manifests/3.2

    Die Ausgabe sieht etwa so aus:

    {
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 526,
         "digest": "sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 526,
         "digest": "sha256:bbb7780ca6592cfc98e601f2a5e94bbf748a232f9116518643905aa30fc01642",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 526,
         "digest": "sha256:31d3efd12022ffeffb3146bc10ae8beb890c80ed2f07363515580add7ed47636",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 526,
         "digest": "sha256:7f82fecd72730a6aeb70713476fb6f7545ed1bbf32cadd7414a77d25e235aaca",
         "platform": {
            "architecture": "ppc64le",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 526,
         "digest": "sha256:1175fd4d728641115e2802be80abab108b8d9306442ce35425a4e8707ca60521",
         "platform": {
            "architecture": "s390x",
            "os": "linux"
         }
      }
   ]
}

  • Filtern Sie das Ergebnis, um den Image-Digest für die gewünschte Plattform zu extrahieren. Rufen Sie den Digest des Image-Manifests für die CPU-Architektur amd64 und das Betriebssystem linux ab:

    curl -s https://gcr.io/v2/google-containers/pause/manifests/3.2 | \
    jq -r '.manifests[] | select(.platform.architecture=="amd64" and .platform.os=="linux") | .digest'

    Durch das Filtern in diesem Befehl wird simuliert, wie Containerlaufzeiten wie containerd das Image auswählen, das mit der Zielplattform aus dem Image-Index übereinstimmt.

    Die Ausgabe sieht etwa so aus:

    sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108

    DerImage-Digest ist das Ergebnis der Anwendung eines kollisionssicheren Hash auf das Image-Index oder Image-Manifest, typischerweise ist das der SHA-256-Algorithmus.

  • Rufen Sie den Digest des Images gcr.io/google-containers/pause-amd64:3.2 ab:

    curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2 \
    | shasum -a 256 \
    | cut -d' ' -f1

    Die Ausgabe sieht etwa so aus:

    4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108

    Anhand des Image-Digest-Werts können Sie auf dieses Image verweisen:

    gcr.io/google-containers/pause-amd64@sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108

  • Verwenden Sie das Konzept inhaltsadressierbarer Speicher, um das Image-Manifest abzurufen. Verwenden Sie dazu den Digest als Referenz:

    curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108

  • Viele Container Image Registries geben den Digest von Manifesten, Image-Indexen, Konfigurationsobjekten und Dateisystemebenen im Docker-Content-Digest-Header als Antwort auf HTTP-HEAD-Anfragen zurück. Ruft den Digest des Image-Indexes des Image gcr.io/google-containers/pause-amd64:3.2 ab:

    curl -s --head https://gcr.io/v2/google-containers/pause/manifests/3.2 \
    | grep -i Docker-Content-Digest \
    | cut -d' ' -f2

    Die Ausgabe sieht etwa so aus:

    sha256:927d98197ec1141a368550822d18fa1c60bdae27b78b0c004f705f548c07814f

    Der Header Docker-Content-Digest wurde nicht von Spezifikationen der Open Container Initiative Distribution vorgegeben, sodass dieser Ansatz möglicherweise nicht mit allen Container Image Registries funktioniert. Die Verwendung mit der Artifact Registry und der Container Registry ist möglich.

  • So rufen Sie ein Image-Konfigurationsobjekt mithilfe des Digest-Werts aus dem Image-Manifest ab:

    1. Rufen Sie den Konfigurations-Digest ab:

      CONFIG_DIGEST=$(curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2 \
    | jq -r '.config.digest')

    2. Verwenden Sie den Konfigurations-Digest, um das Konfigurationsobjekt abzurufen, und formatieren Sie die Ausgabe mit jq, um sie leichter lesbar zu machen:

      curl -sL https://gcr.io/v2/google-containers/pause-amd64/blobs/$CONFIG_DIGEST \
    | jq

      Die Ausgabe sieht etwa so aus:

      {
  "architecture": "amd64",
  "config": {
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "Entrypoint": [
      "/pause"
    ],
    "WorkingDir": "/",
    "OnBuild": null
  },
  "created": "2020-02-14T10:51:50.60182885-08:00",
  "history": [
    {
      "created": "2020-02-14T10:51:50.60182885-08:00",
      "created_by": "ARG ARCH",
      "comment": "buildkit.dockerfile.v0",
      "empty_layer": true
    },
    {
      "created": "2020-02-14T10:51:50.60182885-08:00",
      "created_by": "ADD bin/pause-amd64 /pause # buildkit",
      "comment": "buildkit.dockerfile.v0"
    },
    {
      "created": "2020-02-14T10:51:50.60182885-08:00",
      "created_by": "ENTRYPOINT [\"/pause\"]",
      "comment": "buildkit.dockerfile.v0",
      "empty_layer": true
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:ba0dae6243cc9fa2890df40a625721fdbea5c94ca6da897acdd814d710149770"
    ]
  }
}

  • Gehen Sie so vor, um Dateisystem-Layer mithilfe von Digest-Werten aus dem Image-Manifest abzurufen:

    1. Rufen Sie den Digest des Layers ab, das Sie abrufen möchten:

      LAYER_DIGEST=$(curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2 \
    | jq -r '.layers[0].digest')

    2. Rufen Sie mit dem Layer-Digest die TAR-Datei des Layers ab und listen Sie die Inhalte auf:

      curl -sL https://gcr.io/v2/google-containers/pause-amd64/blobs/$LAYER_DIGEST \
    | tar --list

      Dieses Layer hat nur eine Datei namens pause.

  • So suchen Sie Tags, die mit einem Image-Digest verknüpft sind:

    1. Definieren Sie den Digest, den Sie aufrufen möchten:

      IMAGE_DIGEST=$(curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2 \
    | shasum -a 256 \
    | cut -d' ' -f1)

      Die Umgebungsvariable IMAGE_DIGEST enthält den Digest des Images, auf das das Tag 3.2 verweist.

    2. Verwenden Sie den Endpunkt der Image-Tags-Liste /tags/list, um Tag-Informationen aufzulisten und die Tags für den Digest-Wert zu extrahieren:

      curl -s "https://gcr.io/v2/google-containers/pause-amd64/tags/list?n=1" \
    | jq ".manifest.\"sha256:$IMAGE_DIGEST\".tag"

      Die Ausgabe sieht etwa so aus:

      [
  "3.2"
]

  • Fügen Sie ein Zugriffstoken in den Authorization-Anfrageheader ein, um das Manifest eines Images mithilfe von cURL aus einem Artifact Registry-Container-Image-Repository abzurufen:

    curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://LOCATION-docker.pkg.dev/v2/PROJECT_ID/REPOSITORY/IMAGE/manifests/DIGEST

    Ersetzen Sie Folgendes:

    • LOCATION: der regionale oder multiregionale Standort Ihres Repositorys
    • PROJECT_ID: Ihre Google Cloud-Projekt-ID
    • REPOSITORY: Name Ihres Repositorys
    • IMAGE: Name Ihres Images
    • DIGEST: Ihr Image-Digest im Format sha256:DIGEST_VALUE.

Nächste Schritte