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

Multi-Arch image #102

Open
jakirkham opened this issue Jun 27, 2019 · 14 comments · May be fixed by #249
Open

Multi-Arch image #102

jakirkham opened this issue Jun 27, 2019 · 14 comments · May be fixed by #249

Comments

@jakirkham
Copy link
Member

Am interested in seeing how we can standardize the images here a bit and consolidate maintenance effort. In particular am curious how we can make a multi-arch image. There's a good blogpost on this topic. It would be good to determine what the current issues prompting the different images we have are and how we address those issues in a general way that benefits all of the images here.

@westurner
Copy link

westurner commented Apr 27, 2020

Could this include the arch string in the miniforge download URL?

RUN wget --no-hsts --quiet https://github.com/conda-forge/miniforge/releases/download/${MINIFORGE_VERSION}/Miniforge3-${MINIFORGE_VERSION}-Linux-x86_64.sh -O /tmp/miniforge.sh && \

https://github.com/conda-forge/miniforge/releases

  • Miniforge3-${MINIFORGE_VERSION}-Linux-x86_64.sh
  • Miniforge3-${MINIFORGE_VERSION}-Linux-aarch64.sh
  • Miniforge3-${MINIFORGE_VERSION}-Linux-ppe64le.sh
  • Miniforge3-${MINIFORGE_VERSION}-Linux-${DEB_TARGET_GNU_CPU}.sh
  • Miniforge3-${MINIFORGE_VERSION}-Linux-${TARGET_CPU_ARCH}.sh

How to make the Dockerfile pass the arch through to be templated into the miniforge release URL?

  • In docker experimental mode, the --platform flag works
  • In lieu of waiting for things to emerge from experimental mode in the moby project, specifying the CPU arch as a build ARG or ENV variable (TARGET_CPU_ARCH=x86_64 | aarch64 | ppe64le may be the most portable way to support multiple architectures (and any container builder) with the miniforge docker container.

...

@jakirkham
Copy link
Member Author

That seems like a question to raise on the miniforge issue tracker.

@westurner
Copy link

westurner commented Apr 27, 2020

FWIU, there's nothing that needs to change in miniforge to make this happen.
The question is how to specify the TARGET_CPU_ARCH for builds of the miniforge Dockerfile that's in this project (conda-forge/docker-images).

RUN wget --no-hsts --quiet https://github.com/conda-forge/miniforge/releases/download/${MINIFORGE_VERSION}/Miniforge3-${MINIFORGE_VERSION}-Linux-x86_64.sh -O /tmp/miniforge.sh && \

Multi-arch images (including miniforge images) could be created with docker build --build-arg.

This would default to x86_64:

ARG TARGET_CPU_ARCH="x86_64"
RUN wget --no-hsts --quiet "https://github.com/conda-forge/miniforge/releases/download/${MINIFORGE_VERSION}/Miniforge3-${MINIFORGE_VERSION}-Linux-${TARGET_CPU_ARCH}.sh" -O /tmp/miniforge.sh && \ 

We could specify a different arch by specifying a different value for TARGET_CPU_ARCH:

docker build --build-arg TARGET_CPU_ARG="aarch64" .

The new way to accomplish this (that only works with buildkit/docker AFAIU?) is with the --platform argument; which results in there being a number of env variables set at build time:

export DOCKER_BUILDKIT=1
docker build --platform linux/amd64
docker build --platform linux/arm64
docker build --platform=linux/amd64,linux/arm64,linux/arm/v7 .
docker build --platform=darwin .
RUN wget --no-hsts --quiet "https://github.com/conda-forge/miniforge/releases/download/${MINIFORGE_VERSION}/Miniforge3-${MINIFORGE_VERSION}-Linux-${TARGETARCH}.sh" -O /tmp/miniforge.sh && \ 

It looks like TARGETARCH is not quite what we're looking for in order to get x86_64 | aarch64 | ppe64le for the miniforge filename; so we may need a conditional on TARGETARCH or one of the other variables: moby/buildkit#499 (comment)

@isuruf
Copy link
Member

isuruf commented Apr 27, 2020

uname -m works

@westurner
Copy link

I'm assuming that uname -m is something like $BUILDARCH; which isn't what we want when cross-compiling?

@martin-g
Copy link

Is there still an interest to merge linux-anvil-cos7-x86_64, linux-anvil-aarch64 and linux-anvil-ppc64le into a multiarch image ?
Currently this is a blocker for bioconda/bioconda-containers#63 to provide multiarch image too.
I'd be happy to help here if there is an interest (and chance to be merged)!

@martin-g
Copy link

martin-g commented Nov 28, 2023

Here is PR in my fork that builds a multi-arch image for linux-anvil-cos7, i.e. CentOS 7 for AMD64, ARM64 and PPC64LE - https://github.com/martin-g/docker-images/pull/1/files
Here is the registry with the image: https://github.com/martin-g/docker-images/pkgs/container/condaforge%2Flinux-anvil-cos7

And a second PR that uses a matrix to build multi-arch images for CentOS 7 and AlmaLinux 8 - https://github.com/martin-g/docker-images/pull/2/files
Registry: https://github.com/martin-g?tab=packages&tab=packages&q=condaforge

@jakirkham
Copy link
Member Author

Thanks for your interest Martin! 🙏

Think what we would want to do is create a GHA step after the existing Docker builds that pulled the different architecture builds into multiarch images that also get pushed. IOW we could use docker manifest to combine them

That way users can still retrieve images under the existing names, we still are able to parallelize/separate arch builds, and the end result maps nicely on to our existing images

Am curious to hear your thoughts on this approach 🙂

@martin-g
Copy link

I've never done this before but I will be glad to learn something new! Let me investigate!

@martin-g
Copy link

Worked like a charm:
PR: https://github.com/martin-g/docker-images/pull/3/files
Docker registry: https://hub.docker.com/repository/docker/mtgrigorov/linux-anvil-cos7-manifest/general

I did it in a separate workflow file because I didn't want to wait for the whole build of all images in ci.yaml, but the build job must be in the ci.yaml and should declare a dependency on the build job.

@mbargull
Copy link
Member

Currently this is a blocker for bioconda/bioconda-containers#63 to provide multiarch image too.

No, this is not a blocker.
But it would make downstream uses easier.


There might be interest in keep arch-specific named-images, see #242 (comment) (cc @xhochy).
The clean way to do this is to provide, e.g., linux-anvil-cos7-x86_64, linux-anvil-cos7-aarch64, linux-anvil-cos7-ppc64le and collect them in a manifest linux-anvil-cos7 (meaning, we'd reuse the name for of the current x86 image for the manifest, but that shouldn't be a problem).

@jakirkham
Copy link
Member Author

Yep Marcel think we are proposing the same thing 🤝, which it appears Martin has done 👍

Given your working experiment Martin, would you be interested in submitting a PR? 🙂

@martin-g
Copy link

Given your working experiment Martin, would you be interested in submitting a PR?

Sure! I was waiting for confirmation that this is what is preferred!

@martin-g
Copy link

You can see an almost finished WIP at https://github.com/martin-g/docker-images/pull/4/files
At the moment it uses my accounts for DockerHub and Quay.io to fully test the jobs and deploys the images and manifests even for non-main branch, again only for testing!
Anyone is welcome to give feedback directly in the fork PR!
Once all is green I will create a PR here!

@martin-g martin-g linked a pull request Nov 30, 2023 that will close this issue
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants