Informazioni sui digest delle immagini container


Questa pagina descrive i digest delle immagini, inclusi che cosa sono, come trovarli e come imporne l'utilizzo nei cluster Kubernetes. Questa pagina è destinato a sviluppatori e operatori che creano ed eseguono il deployment in formato Docker.

R digest immagini container identifica in modo univoco e immutabile un'immagine container. Quando esegui il deployment delle immagini tramite digest, eviti i lati negativi del deployment tramite tag immagine.

I comandi in questa pagina presuppongono che tu abbia accesso a un sistema operativo Linux o macOS dell'ambiente shell con strumenti come Google Cloud CLI Docker, cURL jq, e pack è già installata. In alternativa, puoi utilizzare Cloud Shell che include questi strumenti sono preinstallate.

Immagini container e tag immagine

Quando lavori con le immagini container, hai bisogno di un modo per fare riferimento alle immagini che utilizzi. I tag immagine sono un modo comune per fare riferimento a revisioni diverse di un'immagine. Un comune consiste nel taggare le immagini con un identificatore di versione al momento della creazione. Ad esempio, v1.0.1 potrebbe fare riferimento a una versione chiamata 1.0.1.

I tag consentono di cercare facilmente le revisioni delle immagini tramite stringhe leggibili. Tuttavia, sono riferimenti mutabili, il che significa che l'immagine a cui fa riferimento un tag può come illustrato nel diagramma seguente:

Tag immagine che rimanda a un'immagine obsoleta.

Come mostrato nel diagramma precedente, se pubblichi una nuova immagine utilizzando lo stesso tag di un'immagine esistente, il tag smette di puntare all'immagine esistente e inizia a puntare alla nuova immagine.

Svantaggi dei tag immagine

Poiché i tag sono mutabili, presentano i seguenti svantaggi se li utilizzi per eseguire il deployment di un'immagine:

  • In Kubernetes, il deployment per tag può comportare risultati imprevisti. Per Ad esempio, supponiamo di avere una risorsa Deployment esistente fa riferimento a un'immagine container tramite il tag v1.0.1. Per correggere un bug o apportare modifiche modifica, il processo di compilazione crea una nuova immagine con lo stesso tag v1.0.1. I nuovi pod creati dalla risorsa Deployment possono finire per utilizzare l'immagine precedente o quella nuova, anche se non modifichi la specifica della risorsa Deployment. Questo problema si applica anche ad altre risorse Kubernetes come StatefulSet, DaemonSet, ReplicaSet e Job.

  • Se utilizzi strumenti per scansionare o analizzare le immagini, i risultati di questi strumenti sono validi solo per l'immagine sottoposta a scansione. Per assicurarti di eseguire il deployment l'immagine scansionata, non puoi fare affidamento sul tag perché a cui il tag fa riferimento.

  • Se utilizzi Autorizzazione binaria con Google Kubernetes Engine (GKE) l'implementazione basata su tag non è consentita perché è impossibile determinare l'immagine esatta utilizzata quando viene creato un pod.

Quando esegui il deployment delle immagini, puoi utilizzare un digest di immagini per evitare i svantaggi dell'utilizzo dei tag. Se vuoi, puoi comunque aggiungere tag alle immagini, ma non devi necessariamente farlo.

Struttura di un'immagine

Un'immagine è costituita dai seguenti componenti:

Questi componenti sono illustrati nel seguente diagramma:

Componenti di un'immagine che mostrano i dettagli di un manifest immagine, un oggetto di configurazione, i livelli del file system e un indice di immagini.

L'immagine precedente mostra ulteriori dettagli sui componenti dell'immagine:

  • Il manifest dell'immagine è un documento JSON che contiene un riferimento all'oggetto di configurazione, ai livelli del file system e ai metadati facoltativi.
  • Il file manifest dell'immagine fa riferimento all'oggetto di configurazione e a ciascuno dei i livelli del file system utilizzando i relativi attributi digest. Il valore di un attributo digest è un hash crittografico dei contenuti a cui fa riferimento il digest, in genere calcolato utilizzando l'algoritmo SHA-256.
  • I valori digest vengono utilizzati per creare indirizzi immutabili per gli oggetti. Questo processo è chiamato content-addressable storage, e significa che puoi recuperare manifest di immagini, indici di immagini, oggetti di configurazione e livelli in base ai relativi digest.
  • Il digest dell'immagine è l'hash del documento JSON dell'indice delle immagini o del manifest delle immagini.
  • L'oggetto di configurazione è un documento JSON che definisce le proprietà dell'immagine, come l'architettura della CPU, il punto di contatto, le porte esposte e le variabili di ambiente.
  • L'array del livello del file system definisce l'ordine utilizzato dal runtime del container per impilare i livelli. Gli strati sono distribuiti come file tar, in genere viene compresso utilizzando gzip: utilità.
  • L'indice di immagini facoltativo, a volte chiamato elenco manifest, si riferisce a uno o più manifest di immagini. Il riferimento è il digest manifest dell'immagine. Un indice di immagini è utile quando produci più immagini correlate per diverse piattaforme, come le architetture amd64 e arm64.

Per ulteriori informazioni, consulta la sezione Esplorazione di manifest, sintesi e tag delle immagini.

Ricerca di sintesi delle immagini

Per usare i digest delle immagini per il deployment, devi prima trovare il digest. Poi puoi utilizzare il digest con il comando di deployment o includerlo nel tuo e i file manifest.

Puoi ottenere il digest di un'immagine in diversi modi, a seconda della situazione attuale. Le seguenti sezioni contengono esempi di diversi prodotti e i nostri strumenti.

Nelle sezioni seguenti, esegui i comandi in Cloud Shell o in un ambiente shell con strumenti come l'interfaccia a riga di comando gcloud, Docker, cURL e jq già installati.

Artifact Registry

Container Registry

  • Per le immagini archiviate in Container Registry, puoi utilizzare il comando gcloud container images describe per ottenere il digest di un'immagine specificandone il nome e un tag. Utilizza il flag --format per visualizzare solo il riepilogo:

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

    L'output è simile al seguente, anche se il valore digest potrebbe differiscono:

    sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108
    

Cloud Build

Per le immagini create utilizzando Cloud Build, puoi ottenere il digest dell'immagine utilizzando il comando gcloud builds describe con il flag --format. Questo approccio funziona indipendentemente dal registry utilizzato per pubblicare l'immagine.

  • Per una build già completata:

    1. Visualizza un elenco di build per il tuo progetto:

      gcloud builds list
      

      Prendi nota di un BUILD_ID.

    2. Ottieni il digest dell'immagine:

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

      Sostituisci BUILD_ID con l'ID univoco che Cloud Build assegnato alla tua build.

  • Ottieni il nome e il digest dell'immagine per l'ultima compilazione da Cloud Build per il tuo progetto corrente:

    gcloud builds describe \
        $(gcloud builds list --limit 1 --format 'value(id)') \
        --format 'value[separator="@"](results.images[0].name,results.images[0].digest)'
    
  • Se la compilazione ha prodotto più immagini, filtra l'output e ottieni il digest di una delle immagini:

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

    Sostituisci YOUR_IMAGE_NAME con il nome di una delle immagini del tuo file cloudbuild.yaml.

  • Se invii una build a Cloud Build utilizzando il comando gcloud builds submit, puoi acquisire il digest dell'immagine dall'output in una variabile di ambiente:

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

Buildpack cloud-native

  • Se utilizzi Cloud Native Buildpacks e il builder Google Cloud per creare e pubblicare immagini, puoi acquisizione del nome e del digest dell'immagine utilizzando il flag --quiet con il comando pack:

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

    Sostituisci quanto segue:

    • LOCATION: a livello di una o più regioni località del repository
    • PROJECT_ID: il tuo ID progetto Google Cloud
    • REPOSITORY: il nome del repository
    • IMAGE: il nome della tua immagine

    Il file image-with-digest.txt contiene il nome e il digest dell'immagine.

    Utilizza il flag --tag se vuoi aggiungere tag all'immagine.

Client Docker

  • Il comando secondario manifest del client a riga di comando docker può recuperare manifest e liste di manifest delle immagini dai registry delle immagini dei container.

    Recupera il digest dall'elenco manifest dell'immagineregistry.k8s.io/pause:3.9, per l'architettura CPU amd64 e il sistema operativolinux:

    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'
    

    L'output è simile al seguente:

    sha256:8d4106c88ec0bd28001e34c975d65175d994072d65341f62a8ab0754b0fafe10
    
  • Per le immagini archiviate nel daemon Docker locale e che sono state esportate o importate in un registry di immagini, puoi utilizzare lo strumento a riga di comando Docker per ottenere il digest dell'immagine:

    1. Esegui il pull dell'immagine nella tua località Daemon Docker:

      docker pull docker.io/library/debian:bookworm
      
    2. Ottieni la sintesi dell'immagine:

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

      L'output è simile al seguente, sebbene il valore digest potrebbero essere diverse:

      sha256:3d868b5eb908155f3784317b3dda2941df87bbbbaa4608f84881de66d9bb297b
      
  • Elenca tutte le immagini e i digest nel daemon Docker locale:

    docker images --digests
    

    L'output mostra i digest per le immagini che hanno un valore digest. Le immagini hanno un valore digest solo se sono state esportate da un registry delle immagini o importate in un registry delle immagini.

crane e gcrane

Puoi usare l'open source crane e gcrane di strumenti a riga di comando ottenere il digest di un'immagine senza eseguirne il pull su un daemon Docker locale.

  1. Scarica crane e gcrane nella directory corrente:

    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. Visualizzare i digest delle immagini:

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

    crane e gcrane hanno altre funzionalità che non rientrano nell'ambito di questa pagina. Per ulteriori informazioni, consulta la documentazione su crane e gcrane.

Applicazione dell'uso dei digest delle immagini nei deployment Kubernetes

Se vuoi applicare in modo forzato l'uso dei digest per le immagini di cui esegui il deployment per i cluster Kubernetes, puoi utilizzare Policy Controller o Gatekeeper di Open Policy Agent (OPA). Policy Controller è basato sul progetto open source OPA Gatekeeper.

Policy Controller e OPA Gatekeeper si basano entrambi Motore dei criteri OPA. Policy Controller e OPA Gatekeeper offrono Convalida del webhook di ammissione da parte di Kubernetes per applicare i criteri definizioni di risorse personalizzate (CRD) della modelli di vincoli e vincoli.

I modelli di vincoli contengono la logica dei criteri espressa utilizzando un linguaggio dichiarativo di alto livello chiamato Rego. Di seguito è riportato un modello di vincolo che convalida i container, container init, e container temporanei in una specifica delle risorse Kubernetes, usa immagini con digest:

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)
          }

Il criterio precedente contiene un'espressione regolare come input per il Funzione re_match. Questa espressione regolare corrisponde al digest dell'immagine del contenitore e si basa sul formato del digest nella specifica dell'immagine Open Container Initiative.

I vincoli applicano il criterio alle risorse Kubernetes trovando corrispondenze con come kind e namespace. Il vincolo di esempio riportato di seguito applica il criterio del modello di vincolo a tutte le risorse Pod nello spazio dei nomi default.

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

Dopo aver creato il modello e il vincolo, tutti i nuovi pod lo spazio dei nomi default deve utilizzare digest delle immagini per fare riferimento alle immagini container.

Per l'esempio completo, consulta Norme relative a imagedigests nella libreria dei criteri di Gatekeeper.

Informazioni su manifest, sintesi e tag delle immagini

In questa sezione, imparerai a esplorare le immagini esistenti nei registri utilizzando riga di comando come curl e docker. Esegui i comandi in Cloud Shell o in un ambiente shell con strumenti come gcloud CLI, Docker, cURL e jq già installati. I comandi seguenti usano immagini pubbliche Artifact Registry.

  • Ottieni il manifest dell'immagine gcr.io/google-containers/pause-amd64:3.2 utilizzando cURL e URL manifest:

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

    L'output è simile al seguente:

    {
       "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"
          }
       ]
    }
    

    La sezione config ha un attributo digest e puoi utilizzare questo valore per recuperare l'oggetto di configurazione. Analogamente, ogni livello ha un attributo digest che puoi utilizzare per recuperare il file tar del livello.

  • Se l'immagine include l'indice facoltativo delle immagini, viene inviata una richiesta GET HTTP all'URL manifest utilizzando un tag, restituisce l'indice dell'immagine anziché manifest dell'immagine.

    Ottieni l'indice dell'immagine gcr.io/google-containers/pause:3.2:

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

    L'output è simile al seguente:

    {
       "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"
             }
          }
       ]
    }
    
  • Filtra il risultato per estrarre il digest immagine per la piattaforma desiderato. Ottieni il digest del manifest dell'immagine per l'architettura della CPU amd64 e il sistema operativo linux:

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

    Il filtro in questo comando imita il modo in cui i runtime dei container, come containerd, scelgono l'immagine corrispondente alla piattaforma di destinazione dall'indice delle immagini.

    L'output è simile al seguente:

    sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108
    

    Il digest dell'immagine è il risultato dell'applicazione di un hash resistente alle collisioni all'indice delle immagini o al manifest delle immagini, in genere l'algoritmo SHA-256.

  • Ottieni il digest dell'immagine gcr.io/google-containers/pause-amd64:3.2:

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

    L'output è simile al seguente:

    4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108
    

    Puoi fare riferimento a questa immagine utilizzando il valore del digest dell'immagine come segue:

    gcr.io/google-containers/pause-amd64@sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108
    
  • Utilizzando il concetto di content-addressable storage, recupera il manifest dell'immagine utilizzando il digest come riferimento:

    curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/sha256:4a1c4b21597c1b4415bdbecb28a3296c6b5e23ca4f9feeb599860a1dac6a0108
    
  • Molti registri di immagini container restituiscono il digest dei file manifest, indici, oggetti di configurazione e livelli di file system Intestazione Docker-Content-Digest in risposta alle richieste HTTP HEAD. Recupera il digest dell'indice immagine dell'immaginegcr.io/google-containers/pause-amd64:3.2:

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

    L'output è simile al seguente:

    sha256:927d98197ec1141a368550822d18fa1c60bdae27b78b0c004f705f548c07814f
    

    L'intestazione Docker-Content-Digest è non richiesto dalle specifiche della distribuzione Open Container Initiative, pertanto questo approccio potrebbe non funzionare con tutti i registri di immagini container. Puoi usarlo con Artifact Registry e Container Registry.

  • Per recuperare un oggetto di configurazione dell'immagine utilizzando il valore digest del manifest dell'immagine:

    1. Ottieni la sintesi della configurazione:

      CONFIG_DIGEST=$(curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2 \
          | jq -r '.config.digest')
      
    2. Utilizza il digest della configurazione per recuperare la configurazione e usa jq per formattare l'output in modo da facilitarne la lettura:

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

      L'output è simile al seguente:

      {
        "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"
          ]
        }
      }
      
  • Per recuperare i livelli del file system utilizzando i valori digest dal manifest dell'immagine:

    1. Recupera il digest del livello che vuoi recuperare:

      LAYER_DIGEST=$(curl -s https://gcr.io/v2/google-containers/pause-amd64/manifests/3.2 \
          | jq -r '.layers[0].digest')
      
    2. Utilizza il digest del livello per recuperare il file tar del livello e elencarne i contenuti:

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

      Questo livello ha un solo file, denominato pause.

  • Per cercare i tag associati a un digest immagine:

    1. Definisci il digest che vuoi cercare:

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

      La variabile di ambiente IMAGE_DIGEST contiene il digest dell'immagine a cui fa riferimento il tag 3.2.

    2. Utilizza la endpoint dell'elenco dei tag immagine, /tags/list, per elencare le informazioni dei tag ed estrarre i tag per il valore del digest:

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

      L'output è simile al seguente:

      [
        "3.2"
      ]
      
  • ottenere il manifest di un'immagine da un'immagine container Artifact Registry. repository utilizzando cURL, includi token di accesso nell'intestazione della richiesta Authorization:

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

    Sostituisci quanto segue:

    • LOCATION: a livello di una o più regioni località del repository
    • PROJECT_ID: il tuo ID progetto Google Cloud
    • REPOSITORY: il nome del tuo repository
    • IMAGE: il nome dell'immagine
    • DIGEST: il digest dell'immagine nel formato sha256:DIGEST_VALUE

Passaggi successivi