m1k1o / neko

A self hosted virtual browser that runs in docker and uses WebRTC.
https://neko.m1k1o.net/
Apache License 2.0
7.11k stars 524 forks source link

Multiarch images #394

Open clementgineste opened 4 months ago

clementgineste commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.