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

Multiarch images #394

Open
clementgineste opened this issue May 27, 2024 · 5 comments
Open

Multiarch images #394

clementgineste opened this issue May 27, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@clementgineste
Copy link

clementgineste commented May 27, 2024

DH & GHCR don't seem to support multiarch for Neko, I found separate images do and I checked the GH Actions workflow and it adds an “arm” prefix.
Wouldn't it be more logical and practical to use the same image name with the different architectures available?

The goal for me is to put something like ghcr.io/neko:firefox and get the right image for AMD64 and ARM64 with the same compose file.

++

@m1k1o
Copy link
Owner

m1k1o commented May 27, 2024

Yes, that would be really great to have. But we have different dockerfiles for different architectures because of the complexity of the environment. At the time of writing the CI/CD there was no support (or just i was not able to find a way) for this in docker buildx.

PR to rework CI/CD to support this functionality are welcome, maybe things habe changed over the years.

@clementgineste
Copy link
Author

I started to look into .docker and GHA workflows, i see there is a base image used as base (hihi) for later images and a lot of version for intel or other thing.
Nowadays to generate an image multiarch it's pretty simple :

     - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: user/app:latest

How's the overhead for different image (VAAPI/Nvidia, ..) ? Could it be reunite in one image for the sake of simplicity ?

Anyway if i'll find time i'll try to make something and upgrade action version at the same time. Is every Dockerfile up to date ?

@clementgineste
Copy link
Author

Actually i think base image is not needed, we can directly build final image and avoid another step. And in the mean time step-up to Bookworm.

@m1k1o
Copy link
Owner

m1k1o commented May 28, 2024

Not having base image would mean, the build provides needs to be copied over to every single image that we are building. I can think of some dockerfile generator that would prepare such dockerfiles without having code duplication. But on the other hand i would like to keep the build process as simple as it can be.

@ehfd
Copy link

ehfd commented May 29, 2024

https://github.com/selkies-project/selkies-gstreamer/blob/main/.github/actions/build_and_publish_image/action.yaml

Check this.

The second way to do it is to manually create manifests with docker manifest (this allows to build arm64 and amd64 separately in different jobs but more complicated):
https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/
https://medium.com/@life-is-short-so-enjoy-it/docker-how-to-build-and-push-multi-arch-docker-images-to-docker-hub-64dea4931df9

Note that arm64 (or any other architecture built with GitHub Actions using QEMU emulation) is 6 times slower than amd64.

@m1k1o m1k1o added the enhancement New feature or request label Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants