-
-
Notifications
You must be signed in to change notification settings - Fork 417
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-architecture image for non-homogenous environments #112
Comments
Hi! At the moment, the builds are done automatically on docker hub - I like this as it then links to the source from the repo and, IMO, gives the user more assurance as to the true origin and nature of the image they're pulling. I hope that docker hub will support this natively at some point (I assume they will), I will see if it's possible to automate with github actions, if not then this is probably only something I'd take on if there was sufficient demand as it would be a manual step required for every release. |
If you tag releases it is a one time effort to setup github actions and then you don't to worry about it ever again. Also with the new Such a command would like this: sudo --preserve-env=DOCKER_BUILDKIT,DOCKER_CLI_EXPERIMENTAL,COMPOSE_DOCKER_CLI_BUILD,HOME,PWD DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build --platform linux/amd64 --platform linux/arm/v7 -t docker.io/supersandro2000/mopidy:latest -t docker.io/supersandro2000/mopidy:3 -t docker.io/supersandro2000/mopidy:3.0 -t docker.io/supersandro2000/mopidy:3.0.2 -t docker.io/supersandro2000/mopidy:3.0.2-1 --build-arg BUILD_DATE=2020-04-23 --build-arg REVISION=6a6f452 --build-arg VERSION=3.0.2-1 --pull --push . Setup requires those two lines to build all supported arches: sudo docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
sudo docker buildx create --use --name build --node build --driver-opt network=host |
I had a quick look yesterday and it looks like there are some good github actions we could leverage for this - I'd be happy to accept a PR for it, otherwise it's something I'll probably look at after the 2.2 release |
Just circling back to this issue, as well as #157 (comment) Currently the manifest for v2.2.0's arm image still specifies amd64, meaning it won't deploy on arm Docker Swarm nodes. |
Checking on this as well. Looks like maybe this is a dead-end project? |
Still the same: image tagged as "arm64", is in reality built for arch "amd64"
|
any feed here? or advice? |
Hi, registry.gitlab.com/opencity-labs/traefik-forward-auth:latest-arm |
I just wanted to say thank you for up-keeping this project. Its been amazing so far!
I was wondering if there was a particular reason behind the decision to have independent Dockerfiles specific to each architecture? To provide some context, I run a k8s cluster with non-homogenous workers (amd64 and arm64). As a result, I have resorted to building a container so that the identical image can be used across all nodes. I've noticed that it's received quite a few downloads in a short period of time and figured it might be a result of your arm and arm64 containers having separate tags and being listed as amd64 architecture in Docker Hub.
In order to facilitate the seamless experience for myself, I've been using
docker buildx
to build a container that works across architecturesarm/v7
,arm64
, andamd64
. To achieve this, I remove the explicitGOARCH=<arch>
command from the baseDockerfile
and build it with the multi-architecture platform flags in Docker. Here's the explicit command I use:I figure this might also help some other folks out that arrive here for the same reason as I. I just wasn't sure if there was a specific intent, or if this might be a simple change to solve the issue for non-homogenous environments. I figure this would also add extensibility to other platforms in the future.
The text was updated successfully, but these errors were encountered: