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.

Sign up for GitHub

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

Jump to bottom

Multi-architecture image for non-homogenous environments #112

Open
npawelek opened this issue Apr 23, 2020 · 5 comments · May be fixed by #116 or #275
Open

Multi-architecture image for non-homogenous environments #112

npawelek opened this issue Apr 23, 2020 · 5 comments · May be fixed by #116 or #275
Labels
enhancement New feature or request

Comments

@npawelek
Copy link

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 architectures arm/v7, arm64, and amd64. To achieve this, I remove the explicit GOARCH=<arch> command from the base Dockerfile and build it with the multi-architecture platform flags in Docker. Here's the explicit command I use:

docker buildx create --name <builder-name>
docker buildx use <builder-name>
docker buildx build --push --no-cache \
    --platform linux/arm64,linux/arm/v7,linux/amd64 \
    -t <user>/<repo>:$(git describe --tags --abbrev=0) \
    -t <user>/<repo>:latest .

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.
@thomseddon thomseddon added the enhancement New feature or request label Apr 23, 2020
@thomseddon
Copy link
Owner

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.

@SuperSandro2000
Copy link
Contributor

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

@thomseddon
Copy link
Owner

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

@npawelek npawelek linked a pull request Apr 24, 2020 that will close this issue
Open
@Beanow Beanow mentioned this issue Aug 16, 2020
Closed
@ciffelia ciffelia linked a pull request Aug 21, 2021 that will close this issue
Open
@Beanow
Copy link

Beanow commented Jun 3, 2022

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.
Seems like #275 would resolve the issue, while moving to GH actions too. Any blockers that we might help with here?

@hagak
Copy link

hagak commented Feb 28, 2024

Checking on this as well. Looks like maybe this is a dead-end project?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
5 participants
@Beanow @thomseddon @npawelek @SuperSandro2000 @hagak