Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer platform that is currently running #646

Open
wants to merge 5 commits into
base: master
from

Conversation

@lisa
Copy link

commented Apr 22, 2019

Prefer platform that is currently running

The goal of this changeset is to prefer the current platform (v1.Platform, and GOARCH) to better support multiple (non-amd64) architectures. There are two targets for this: 1) the Makefile (and Dockerfiles), and 2) select the appropriate image manifest where possible.

  1. Makefile section Previously, the Makefile had set GOARCH to amd64, which is problematic for portability. Setting it to the value of go env GOARCH if not already set seems a good compromise.

Note: This changeset does not address the other inherent portability issues in the Dockerfiles (a separate PR may be forthcoming), but be aware that while the Makefile and code will support the Platform and GOARCH "auto-detection", the Dockerfiles still do not. All this section does is make a GOARCH kaniko binary.

  1. For container images that have multiple manifests, select the one for my platform

If an image has multiple manifests (such as debian:stretch, whose manifest list is linux/amd64, linux/arm/v5, linux/arm/v7, linux/arm64, linux/386, linux/ppc64le, linux/s390x), the previous behaviour was that kaniko, by way of go-containerregistry's current implementation, is to use the linux/amd64, image manifest if it exists.

This change uses runtime to construct a v1.Platform reference which is used as a platform option to remote.Image so that go-containerregistry will attempt to use the current platform's manifest, if it exists.

Motivation behind this change is to bring arm64 support to kaniko.

Prefer platform that is currently running
The goal of this changeset is to prefer the current platform
(`v1.Platform`, and `GOARCH`) to better support multiple (non-amd64)
architectures. There are two targets for this: 1) the Makefile (and
Dockerfiles), and 2) select the appropriate image manifest where
possible.

1. Makefile section Previously, the Makefile had set `GOARCH` to
`amd64`, which is problematic for portability. Setting it to the value
of `go env GOARCH` if not already set seems a good compromise.

**Note**: This changeset does *not* address the other inherent
portability issues in the Dockerfiles (a separate PR may be
forthcoming), but be aware that while the `Makefile` and code will
support the Platform and GOARCH "auto-detection", the Dockerfiles still
do not. All this section does is make a `GOARCH` kaniko binary.

2. For container images that have multiple manifests, select the one for
my platform

If an image has multiple manifests (such as debian:stretch, whose
manifest list is `linux/amd64, linux/arm/v5, linux/arm/v7, linux/arm64,
linux/386, linux/ppc64le, linux/s390x`), the previous behaviour was that
kaniko, by way of go-containerregistry's
[current](https://github.com/google/go-containerregistry/blob/8621d738a07bc74b2adeafd175a3c738423577a0/pkg/v1/remote/image.go#L92-L97)
[implementation](https://github.com/google/go-containerregistry/blob/8621d738a07bc74b2adeafd175a3c738423577a0/pkg/v1/remote/image.go#L36-L39),
is to use the `linux/amd64`, image manifest if it exists.

This change uses `runtime` to construct a `v1.Platform` reference which
is used as a [platform
option](https://github.com/google/go-containerregistry/blob/8621d738a07bc74b2adeafd175a3c738423577a0/pkg/v1/remote/options.go#L59-L64)
to `remote.Image` so that go-containerregistry will attempt to use the
current platform's manifest, if it exists.

Motivation behind this change is to bring arm64 support to kaniko.

Signed-off-by: Lisa Seelye <lisa@users.noreply.github.com>
@lisa lisa referenced this pull request May 13, 2019
0 of 10 tasks complete

lisa added some commits May 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.