Open npawelek opened 4 years ago
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 buildx
system you can auto generate all three arches and auto create manifests for them and push them.
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 https://github.com/thomseddon/traefik-forward-auth/issues/157#issuecomment-841819182
Currently the manifest for v2.2.0's arm image still specifies amd64, meaning it won't deploy on arm Docker Swarm nodes. Seems like #275 would resolve the issue, while moving to GH actions too. Any blockers that we might help with here?
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"
$ docker pull thomseddon/traefik-forward-auth:2-arm64
$ docker image inspect thomseddon/traefik-forward-auth:2-arm64 | grep Arch
"Architecture": "amd64",
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.