Prefer platform that is currently running #646
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 22, 2019
Closed
13 tasks
tejal29
reviewed
Sep 13, 2019
pkg/util/util.go
Outdated
| Config v1.Config | ||
| } | ||
|
|
||
| func ReproducibleDigest(img partial.WithManifestAndConfigFile) (string, error) { |
There was a problem hiding this comment.
I dont think this function is used anywhere.
|
@lisa Are you still interested in pursuing this PR? Thanks |
Apologies, yes, I am. I'll try and tend to it this weekend. |
|
@tejal29 The conflicts should be resolved. |
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>
tejal29
force-pushed
the
set-platform-to-current-platform
branch
from
e8af7d5
to
add7222
Compare
|
I am running Kaniko on arm64 and building images for arm64. Without the changes of this Diff applied, a simple build of the following Dockerfile: ...results in a successful build but the following error when starting the resulting image on arm64: However, with the changes to |
|
I noticed this needs another rebase, so I'll take care of that when I have an opportunity. |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prefer platform that is currently running
The goal of this changeset is to prefer the current platform (
v1.Platform, andGOARCH) 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.GOARCHtoamd64, which is problematic for portability. Setting it to the value ofgo env GOARCHif 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
Makefileand code will support the Platform and GOARCH "auto-detection", the Dockerfiles still do not. All this section does is make aGOARCHkaniko binary.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 thelinux/amd64, image manifest if it exists.This change uses
runtimeto construct av1.Platformreference which is used as a platform option toremote.Imageso 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.