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

Build multiplatform docker #77

Closed
5 tasks done
meysam81 opened this issue Sep 30, 2024 · 5 comments · Fixed by #78
Closed
5 tasks done

Build multiplatform docker #77

meysam81 opened this issue Sep 30, 2024 · 5 comments · Fixed by #78
Labels
feat New feature or request.

Comments

@meysam81
Copy link

Preflight checklist

Ory Network Project

No response

Describe your problem

With the current release scripts, the final docker image ends up having the following tags1:

  • oryd/oathkeeper-maester:v0.1.10-amd64
  • oryd/oathkeeper-maester:v0.1.10-arm64

There is a lack of flexibility in the way these images are being distributed since it is not uncommon for people to have non-uniform workloads (a combination of ARM64 & AMD64 machines).

With the way things are at the moment, we have to explicitly specify the architecture in the image tag.

However, if you build one oryd/oathkeeper-maester:v0.1.10 for both platforms, then we can specify the version number and let the underlying OCI implementation take care of the rest.

These are the offending lines (trimmed for brevity):

dockers:
- image_templates:
- "oryd/oathkeeper-maester:{{ .Tag }}-amd64"
- "oryd/oathkeeper-maester:{{ .ShortCommit }}-amd64"
- "oryd/oathkeeper-maester:latest"
goarch: amd64
build_flag_templates:
- "--platform=linux/amd64"
dockerfile: ".docker/Dockerfile-release"
ids:
- "linux-amd64"
- image_templates:
- "oryd/oathkeeper-maester:{{ .Tag }}-arm64"
- "oryd/oathkeeper-maester:{{ .ShortCommit }}-arm64"
goarch: arm64
build_flag_templates:
- "--platform=linux/arm64"
dockerfile: ".docker/Dockerfile-release"
ids:
- "linux-arm64"

Describe your ideal solution

It would be awesome to build one docker image for multiple platforms1.

Workarounds or alternatives

None at the moment. We have to explicitly set the taints and tolerations to make it work across different node types.

Version

v0.1.10

Additional Context

I would be more than happy to contribute if you confirm that this is a desired outcome. I know where to modify to make the change and I only need your approval.

Cheers and thanks for the awesome products. 🥂

@meysam81 meysam81 added the feat New feature or request. label Sep 30, 2024
@meysam81
Copy link
Author

cc @aeneasr @Demonsthere

@Demonsthere
Copy link
Collaborator

Hello there!
As much as I understand your point, this is a design pattern that we have designed in the whole ory ecosystem. I don't feel confident in letting the OCI decide on the platform, as we have seen issues with it ourselves. Especially when combined with different base images like distroless vs alpine, which comes with a glibc vs musl discussion.

If you find some targets missing, we can add them to our process, but i would prefer to follow our patterns, and adding them explicitly :)

@meysam81
Copy link
Author

meysam81 commented Oct 14, 2024

@Demonsthere

I understand that you would like to keep the compatibility of your upstream images.

However, your other images are multiplatform, example:

I wonder how is this oathkeeper-maester any different in terms of design and implementation when it comes to providing official multiplatform docker images!?

@Demonsthere
Copy link
Collaborator

Huh, to be honest I was not aware of those changes 😅.
In that case, I think it should be rather straightforward, as if I understand the goreleaser structure, we can keep specific image_templates, but add a docker_manifest object that would join them 🤔

@meysam81
Copy link
Author

@Demonsthere

Appreciate your prompt action.

I believe there is a typo on latests (the trailing s is extra).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants