-
Notifications
You must be signed in to change notification settings - Fork 774
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
Supporting building multi-platform images (podman buildx) #1590
Comments
I like to explain more context about this ticket. Why is this feature important for me now?First, below announcement from Docker is April, 30, 2019. Just 20 days ago.
It's something like people who do not know a smart phone in a old era. And people might say "We want to build and run a multi arch container like multiarch projectLet me share about multiarch project too that I am working for now.
multiarch project https://github.com/multiarch is to give people the below multi arch experience.
It enables people to add multi arch testing cases to their current CI, and it has a role to promote the multiarch container use cases. Here are the cases to add the multi arch cases to Travis CI. https://github.com/BenLangmead/bowtie2/blob/master/.travis.yml#L22-L41 It seems that adding multi arch cases on their existing x86_64 base CI is more casual for them rather than adding new native much arch supporting CI newly like "Shippable CI', in my experience of pull-requests on some projects. Shippable CI supports native 64/32 bit ARM environment like this. There are some challenges for this multiarch project's current technology. And |
If the community wants to work on this, then we would consider it. Currently we don't have the resources or the priority to work on it. |
@rhatdan you mean "the community" in "the community wants to work on this" means multarch project? |
Yes, we need contributors opening PR's to make this happen, it is not as high as other features in the priority list of the core maintainers. |
@rhatdan sure. thanks for considering keeping the possibility. |
Working on at least part of this with #1368 (comment). This covers the build side of I see |
Wow, great work, @grooverdan |
@grooverdan Thanks for looking into this. |
@grooverdan Any progress? |
Yes: Current resolving issues:
I'm making the fetching of the last FROM image in a docker file to fetch using the --platform arguments. For nicely handling multi-stages on cross builds I think the following is needed: Its needed as in multistage it not clear if a Is this an acceptable extension? Currently only see the platform Variant being used in the Push/Pull/Manifest protocols and not an Image metadata. I'm I missing anything in this respect? |
I am fine with extending the FROM command. |
As a rule, I lean away from making up our own extensions to Dockerfile instructions and syntax. |
When you have a multiple FROM statements in a multi-stage image its fairly obvious that the last one is of the target. Earlier stages however are more ambiguous, they could be of the build (native) architecture to cross-compile some artefacts, or build architecture agnostic artefacts (which is faster not emulated), or they could be of the target architecture to have components. For now I'll follow the implementation of docker, leave this as a separate feature. @nalind, seems docker buildx is already using the platform extension: |
Interestingly (perversely?), docker --platform takes the first FROM as the target architecture and others at the native architecture: Dockerfile.platformargs:
|
Hi @grooverdan
Your latest program is still the above branch right? I thought I wanted to try to run your program. |
Yep its the latest. About to get back to this really soon. Plan was to normalize it its behaviour to be consistent with the buildkit issue comment above, see what was working and what needs to be fixed. I also need to see how far on disk libraries have come with respect to storing architecture information. Please have a try, report anything you like/dislike. If you want changes in my tree I'm happy to take PRs and I'll merge them somehow. |
@grooverdan sure. alright. Let me try to run your program.
Sure, I recognized My environment.
Build a ppc64le image with your
Run it with QEMU and binfmt_misc
|
I just compared the result beween
|
The
|
I think I've completed: Exposure of args in build process. Less sure: Ensuing args are declared before use (or not) in the same way as docker buildkit/buildx. Known gaps: Passing Image on filesystem detection of platform (not sure its even there). Extending Dockerfile "FROM xxx" to |
@grooverdan Congratulations! I have a few questions.
According, above "moby/buildkit" ticket, did you implement above current docker's behavior to podman, to keep the consistency with docker, right?
What does it mean? https://github.com/moby/buildkit/blob/master/util/binfmt_misc/Dockerfile You meant Podman does not have this kind of logic internally right? |
I tested buildah on my chroot mock environment (Fedora rawhide), getting the source from your branch, referring https://src.fedoraproject.org/rpms/buildah/blob/master/f/buildah.spec , I could not run. Maybe it's not the new feature specific issue, but my environment's issue. ;<
Below is just from the ~/.config/mock.cfg
I used below file.
Then
As I got below error, I did put the file to the path.
As I got below error, I commented out the lines.
Then run again, I got below error.
|
Buildah requires you to have runc (Runc package in fedora) and /etc/containers/policy.json file installed. container-commons in Fedora world. |
Thanks for the info! I missed below in
I installed the required RPM packages.
On mock environment again.
Any idea to fix this issue? Thanks. |
Looking at the code, it looks like this is blowing up.
|
Very excited for this. It's the only thing holding me back from jumping to podman/buildah from docker buildx. Thanks for the hard work here @grooverdan, filing the issue and testing @junaruga, and supporting the effort @rhatdan. |
@kevinelliott Below can be an alternative way to build multiarch-platform images with podman until podman implement this feature.
|
Uh, I already installed the one from f34. But it's not working: $ buildah bud --arch aarch64 --no-cache
STEP 1: FROM docker.io/fedora:33
STEP 2: RUN touch /testfile
STEP 3: COMMIT
--> 61d523dbf7b
61d523dbf7bcd8cf660ab1201ac8949c7531ee5c762f6174388220eece852e01
$ podman run -it --rm 61d523dbf7bcd8cf660ab1201ac8949c7531ee5c762f6174388220eece852e01 rpm -q coreutils
coreutils-8.32-12.fc33.x86_64 I'd expect the aaaarch64 rpm to be installed, not x86_64. |
hmm, maybe aarch64 is spelled arm64 today. |
$ buildah bud --arch arm64 --no-cache
STEP 1: FROM docker.io/fedora:33
Getting image source signatures
Copying blob be581a95d832 done
Copying config 4d2e61f132 done
Writing manifest to image destination
Storing signatures
STEP 2: RUN touch /testfile
exec container process `/bin/sh`: Exec format error
error building at STEP "RUN touch /testfile": error while running runtime: exit status 1
ERRO exit status 1 I guess I need some qemu-user magic. |
I installed qemu-user-binfmt, but it still fails: $ buildah bud --arch arm64 --no-cache
STEP 1: FROM docker.io/fedora:33
STEP 2: RUN touch /testfile
exec container process (missing dynamic library?) `/bin/sh`: No such file or directory
error building at STEP "RUN touch /testfile": error while running runtime: exit status 1
ERRO exit status 1 |
Works for me. You need qemu-user-static
|
Thanks! works for me too. |
I believe we have the componants to do this now, in current buildah. Reopen if I am mistaken. |
@rhatdan do you know if multi-arch manifests are covered? Might be relevant for this issue. Docker build (or buildx, whatever) has a
Should we expect a similar command from buildah? Or are users supposed to do something else? Maybe use skopeo to create the multi-arch manifests after pushing images to different tags? |
@yangm97 you can use buildah to create multiarch manifests. See |
Thanks for the work and congrats!! I appreciate it. ❤️ |
I am working on fixing bugs in this area. But you should be able to do buildah bud --manifest mymanifest --arch (or --platform) /contextdir. In buildah 1.19.4 and podman 3.0. |
Since buildah now supports multi arch image built support (ref: containers/buildah#1590) This feature will allow building images based on multiple architectures Signed-off-by: divyansh42 <diagrawa@redhat.com>
Since buildah now supports multi arch image built support (ref: containers/buildah#1590) This feature will allow building images based on multiple architectures Signed-off-by: divyansh42 <diagrawa@redhat.com>
Since buildah now supports multi arch image support (ref: containers/buildah#1590) This feature will allow building images for multiple architectures. Signed-off-by: divyansh42 <diagrawa@redhat.com>
I am trying to build a multi-arch image without using |
Have you worked with the buildah manifest command? Should be all you need. |
Yes, I did this way. However, when I did this with containerfile everything worked perfectly. edit: I don't think there is any problem with quay, as I successfully pushed manifest consisting of images built with containerfile. |
Please open a new issue with the exact steps you are doing rather then discussion here in a closed issue. |
Description
Supporting building multi-platform images (
podman buildx
)Detail
This ticket is a request for feature, originally from containers/podman#3063 .
docker buildx
[1][2] is to enable building and running multi-platform container images.I would like to see that
podman
has like the feature.RHEL 8 started supporting multi arch including ARM 64 bit.
Quay 3 started supporting multi arch including ARM 64-bit. [3]
So, it might be a good timing for
podman
to support this feature.docker buildx
is using QEMU internally to do it.As an another way to achieve this, there is
qemu-user-static
[4] also using QEMU.According to the
docker buildx
's article [2], maybe both have similar logic in it.But
docker buildx
looks much easier thanqemu-user-static
.The text was updated successfully, but these errors were encountered: