2018-02-07 15:52:47 -05:00
package images // import "github.com/docker/docker/daemon/images"
import (
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
"context"
"encoding/json"
2018-02-07 15:52:47 -05:00
"fmt"
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
"io"
2018-02-07 15:52:47 -05:00
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
"github.com/containerd/containerd/content"
c8derrdefs "github.com/containerd/containerd/errdefs"
"github.com/containerd/containerd/images"
"github.com/containerd/containerd/leases"
2020-10-15 19:01:17 -04:00
"github.com/containerd/containerd/platforms"
2018-02-07 15:52:47 -05:00
"github.com/docker/distribution/reference"
2022-07-25 11:24:03 -04:00
imagetypes "github.com/docker/docker/api/types/image"
2018-02-07 15:52:47 -05:00
"github.com/docker/docker/errdefs"
"github.com/docker/docker/image"
2022-03-04 08:49:42 -05:00
"github.com/opencontainers/go-digest"
2020-03-19 16:54:48 -04:00
specs "github.com/opencontainers/image-spec/specs-go/v1"
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
"github.com/pkg/errors"
"github.com/sirupsen/logrus"
2018-02-07 15:52:47 -05:00
)
// ErrImageDoesNotExist is error returned when no image can be found for a reference.
type ErrImageDoesNotExist struct {
ref reference . Reference
}
func ( e ErrImageDoesNotExist ) Error ( ) string {
ref := e . ref
if named , ok := ref . ( reference . Named ) ; ok {
ref = reference . TagNameOnly ( named )
}
return fmt . Sprintf ( "No such image: %s" , reference . FamiliarString ( ref ) )
}
// NotFound implements the NotFound interface
func ( e ErrImageDoesNotExist ) NotFound ( ) { }
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
type manifestList struct {
Manifests [ ] specs . Descriptor ` json:"manifests" `
}
type manifest struct {
Config specs . Descriptor ` json:"config" `
}
2022-08-09 08:42:50 -04:00
func ( i * ImageService ) manifestMatchesPlatform ( ctx context . Context , img * image . Image , platform specs . Platform ) ( bool , error ) {
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
logger := logrus . WithField ( "image" , img . ID ) . WithField ( "desiredPlatform" , platforms . Format ( platform ) )
2022-08-09 08:33:07 -04:00
ls , leaseErr := i . leases . ListResources ( ctx , leases . Lease { ID : imageKey ( img . ID ( ) . Digest ( ) ) } )
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
if leaseErr != nil {
logger . WithError ( leaseErr ) . Error ( "Error looking up image leases" )
2022-08-09 08:42:50 -04:00
return false , leaseErr
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
}
2021-02-17 15:41:12 -05:00
// Note we are comparing against manifest lists here, which we expect to always have a CPU variant set (where applicable).
// So there is no need for the fallback matcher here.
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
comparer := platforms . Only ( platform )
var (
ml manifestList
m manifest
)
makeRdr := func ( ra content . ReaderAt ) io . Reader {
return io . LimitReader ( io . NewSectionReader ( ra , 0 , ra . Size ( ) ) , 1e6 )
}
for _ , r := range ls {
logger := logger . WithField ( "resourceID" , r . ID ) . WithField ( "resourceType" , r . Type )
logger . Debug ( "Checking lease resource for platform match" )
if r . Type != "content" {
continue
}
ra , err := i . content . ReaderAt ( ctx , specs . Descriptor { Digest : digest . Digest ( r . ID ) } )
if err != nil {
if c8derrdefs . IsNotFound ( err ) {
continue
}
logger . WithError ( err ) . Error ( "Error looking up referenced manifest list for image" )
continue
}
2021-08-24 06:10:50 -04:00
data , err := io . ReadAll ( makeRdr ( ra ) )
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
ra . Close ( )
if err != nil {
logger . WithError ( err ) . Error ( "Error reading manifest list for image" )
continue
}
ml . Manifests = nil
if err := json . Unmarshal ( data , & ml ) ; err != nil {
logger . WithError ( err ) . Error ( "Error unmarshalling content" )
continue
}
for _ , md := range ml . Manifests {
switch md . MediaType {
case specs . MediaTypeImageManifest , images . MediaTypeDockerSchema2Manifest :
default :
continue
}
p := specs . Platform {
Architecture : md . Platform . Architecture ,
OS : md . Platform . OS ,
Variant : md . Platform . Variant ,
}
if ! comparer . Match ( p ) {
logger . WithField ( "otherPlatform" , platforms . Format ( p ) ) . Debug ( "Manifest is not a match" )
continue
}
// Here we have a platform match for the referenced manifest, let's make sure the manifest is actually for the image config we are using.
ra , err := i . content . ReaderAt ( ctx , specs . Descriptor { Digest : md . Digest } )
if err != nil {
logger . WithField ( "otherDigest" , md . Digest ) . WithError ( err ) . Error ( "Could not get reader for manifest" )
continue
}
2021-08-24 06:10:50 -04:00
data , err := io . ReadAll ( makeRdr ( ra ) )
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
ra . Close ( )
if err != nil {
logger . WithError ( err ) . Error ( "Error reading manifest for image" )
continue
}
if err := json . Unmarshal ( data , & m ) ; err != nil {
logger . WithError ( err ) . Error ( "Error desserializing manifest" )
continue
}
if m . Config . Digest == img . ID ( ) . Digest ( ) {
logger . WithField ( "manifestDigest" , md . Digest ) . Debug ( "Found matching manifest for image" )
2022-08-09 08:42:50 -04:00
return true , nil
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
}
logger . WithField ( "otherDigest" , md . Digest ) . Debug ( "Skipping non-matching manifest" )
}
}
2022-08-09 08:42:50 -04:00
return false , nil
Fallback to manifest list when no platform match
In some cases, in fact many in the wild, an image may have the incorrect
platform on the image config.
This can lead to failures to run an image, particularly when a user
specifies a `--platform`.
Typically what we see in the wild is a manifest list with an an entry
for, as an example, linux/arm64 pointing to an image config that has
linux/amd64 on it.
This change falls back to looking up the manifest list for an image to
see if the manifest list shows the image as the correct one for that
platform.
In order to accomplish this we need to traverse the leases associated
with an image. Each image, if pulled with Docker 20.10, will have the
manifest list stored in the containerd content store with the resource
assigned to a lease keyed on the image ID.
So we look up the lease for the image, then look up the assocated
resources to find the manifest list, then check the manifest list for a
platform match, then ensure that manifest referes to our image config.
This is only used as a fallback when a user specified they want a
particular platform and the image config that we have does not match
that platform.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2021-02-01 14:09:09 -05:00
}
2018-02-14 15:19:37 -05:00
// GetImage returns an image corresponding to the image referred to by refOrID.
2022-08-09 08:42:50 -04:00
func ( i * ImageService ) GetImage ( ctx context . Context , refOrID string , options imagetypes . GetImageOpts ) ( retImg * image . Image , retErr error ) {
2020-03-19 16:54:48 -04:00
defer func ( ) {
2022-07-25 11:24:03 -04:00
if retErr != nil || retImg == nil || options . Platform == nil {
2020-03-19 16:54:48 -04:00
return
}
2020-10-15 19:01:17 -04:00
imgPlat := specs . Platform {
OS : retImg . OS ,
Architecture : retImg . Architecture ,
Variant : retImg . Variant ,
2020-03-19 16:54:48 -04:00
}
2022-07-25 11:24:03 -04:00
p := * options . Platform
2020-10-15 19:01:17 -04:00
// Note that `platforms.Only` will fuzzy match this for us
2022-10-05 11:31:45 -04:00
// For example: an armv6 image will run just fine on an armv7 CPU, without emulation or anything.
2021-02-17 15:41:12 -05:00
if OnlyPlatformWithFallback ( p ) . Match ( imgPlat ) {
2020-03-19 16:54:48 -04:00
return
}
2021-02-17 15:41:12 -05:00
// In some cases the image config can actually be wrong (e.g. classic `docker build` may not handle `--platform` correctly)
2022-10-05 11:31:45 -04:00
// So we'll look up the manifest list that corresponds to this image to check if at least the manifest list says it is the correct image.
2022-08-09 08:42:50 -04:00
var matches bool
matches , retErr = i . manifestMatchesPlatform ( ctx , retImg , p )
if matches || retErr != nil {
2021-02-17 15:41:12 -05:00
return
}
// This allows us to tell clients that we don't have the image they asked for
// Where this gets hairy is the image store does not currently support multi-arch images, e.g.:
// An image `foo` may have a multi-arch manifest, but the image store only fetches the image for a specific platform
// The image store does not store the manifest list and image tags are assigned to architecture specific images.
// So we can have a `foo` image that is amd64 but the user requested armv7. If the user looks at the list of images.
// This may be confusing.
2022-10-05 11:31:45 -04:00
// The alternative to this is to return an errdefs.Conflict error with a helpful message, but clients will not be
2021-02-17 15:41:12 -05:00
// able to automatically tell what causes the conflict.
retErr = errdefs . NotFound ( errors . Errorf ( "image with reference %s was found but does not match the specified platform: wanted %s, actual: %s" , refOrID , platforms . Format ( p ) , platforms . Format ( imgPlat ) ) )
2020-03-19 16:54:48 -04:00
} ( )
2018-02-07 15:52:47 -05:00
ref , err := reference . ParseAnyReference ( refOrID )
if err != nil {
2018-02-14 15:19:37 -05:00
return nil , errdefs . InvalidParameter ( err )
2018-02-07 15:52:47 -05:00
}
namedRef , ok := ref . ( reference . Named )
if ! ok {
digested , ok := ref . ( reference . Digested )
if ! ok {
2018-02-14 15:19:37 -05:00
return nil , ErrImageDoesNotExist { ref }
2018-02-07 15:52:47 -05:00
}
id := image . IDFromDigest ( digested . Digest ( ) )
if img , err := i . imageStore . Get ( id ) ; err == nil {
2018-02-14 15:19:37 -05:00
return img , nil
2018-02-07 15:52:47 -05:00
}
2018-02-14 15:19:37 -05:00
return nil , ErrImageDoesNotExist { ref }
2018-02-07 15:52:47 -05:00
}
if digest , err := i . referenceStore . Get ( namedRef ) ; err == nil {
// Search the image stores to get the operating system, defaulting to host OS.
id := image . IDFromDigest ( digest )
if img , err := i . imageStore . Get ( id ) ; err == nil {
2018-02-14 15:19:37 -05:00
return img , nil
2018-02-07 15:52:47 -05:00
}
}
// Search based on ID
if id , err := i . imageStore . Search ( refOrID ) ; err == nil {
img , err := i . imageStore . Get ( id )
if err != nil {
2018-02-14 15:19:37 -05:00
return nil , ErrImageDoesNotExist { ref }
2018-02-07 15:52:47 -05:00
}
2018-02-14 15:19:37 -05:00
return img , nil
2018-02-07 15:52:47 -05:00
}
2018-02-14 15:19:37 -05:00
return nil , ErrImageDoesNotExist { ref }
2018-02-07 15:52:47 -05:00
}
2021-02-17 15:41:12 -05:00
// OnlyPlatformWithFallback uses `platforms.Only` with a fallback to handle the case where the platform
2022-07-08 12:27:07 -04:00
// being matched does not have a CPU variant.
2021-02-17 15:41:12 -05:00
//
// The reason for this is that CPU variant is not even if the official image config spec as of this writing.
// See: https://github.com/opencontainers/image-spec/pull/809
// Since Docker tends to compare platforms from the image config, we need to handle this case.
func OnlyPlatformWithFallback ( p specs . Platform ) platforms . Matcher {
return & onlyFallbackMatcher { only : platforms . Only ( p ) , p : platforms . Normalize ( p ) }
}
type onlyFallbackMatcher struct {
only platforms . Matcher
p specs . Platform
}
func ( m * onlyFallbackMatcher ) Match ( other specs . Platform ) bool {
if m . only . Match ( other ) {
// It matches, no reason to fallback
return true
}
if other . Variant != "" {
// If there is a variant then this fallback does not apply, and there is no match
return false
}
otherN := platforms . Normalize ( other )
otherN . Variant = "" // normalization adds a default variant... which is the whole problem with `platforms.Only`
return m . p . OS == otherN . OS &&
m . p . Architecture == otherN . Architecture
}