chainguard-dev
Images not being built with tags passed to build command
On an Alpine VM.
Built an apk with melange (pulled head of main today, not the docker tool). Build is successful and resulting apk has the files I'd expect where I'd expect them. This is the apk index file contents:
# cat APKINDEX
C:Q1L9nPt7DQGd4Wun74ih3oLzHep0k=
P:d-k-a
V:1.4.0-r1
A:x86_64
S:7182339
I:13068156
T:My description
L:Apache-2.0
o:d-k-a
D:so:ld-linux-x86-64.so.2 so:libc.so.6 so:libresolv.so.2
Now I build an image from that apk with apko (pulled head of main today, not the dockerized tool). APKO build also appears to be successful. I've got my tarball: d-k-a.tar Here's the apko build command I'm using:
apko build d-k-a.apko.yaml d-k-a:mine d-k-a.tar -k melange.rsa.pub
However, when I docker load that image, it loads as amd64:latest.
# docker load < d-k-a.tar
Loaded image: amd64:latest
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
amd64 latest 6b33af137922 53 years ago 19.6MB
And in the manifest.json:
# cat manifest.json
[{"Config":"sha256:0db429462b7151443899d684534444cf3392c5c25fc4ce11573abcc0686a418e","RepoTags":["amd64:latest"],"Layers":["ab073ba98a99cf93550f674277201c83c558710a9055a0d137ee54fe6fc6d663.tar.gz"]}]
[...]
I expect my image to be called d-k-a:mine.
@deitch @imjasonh @kaniini
Per kaniini - might be related to new support for native multi arch builds.
Might be. I didn't think we changed any of that, but I can walk it through and look.
Oh I think it is. This isn't related to all of the build work, but the support we added for multi-arch build. Going to fix that right away.
Question.
I pulled apko an hour ago from head of main.
apko build command:
apko build d-k-a.apko.yaml d-k-a:mine d-k-a.tar -k melange/melange.rsa.pub
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
d-k-a mine-amd64 232af14ca2f6 53 years ago 15.8MB
manifest.json:
[{"Config":"sha256:232af14ca2f64be261b919ab7593b210b48e4e61624496b18e83eec907bc6a5b","RepoTags":["index.docker.io/library/d-k-a:mine-amd64"],"Layers":["50821a15f4d34111b13eb781b1629fbe21fc47acb9e2de65f9c1950c6163b31f.tar.gz"]}
Is suffixing architecture to the user-specified tag name expected now?
Is suffixing architecture to the user-specified tag name expected now?
It is, until we can come up with a better way to do it. Docker engine does not (yet) support multiple architectures (the experimental containerd-based engine does, sort of). So you have to give it some way to distinguish between the two images, otherwise it is random as to which one will win.
docker load depends on manifest.json, which has specific image and layers. We are open to a better way to do this.
Status quo. https://kubernetes.io/docs/concepts/containers/images/#multi-architecture-images-with-image-indexes
Can this be closed now, @jr-chainguard?
