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

ci: publish multi-arch image manifest lists #4254

Merged
merged 1 commit into from
Jan 24, 2022

Conversation

ngraef
Copy link
Contributor

@ngraef ngraef commented Jan 20, 2022

This change adds linux/arm64 binaries to the release. It also publishes an arm64 container image for all variants (standard, debug, rootless, static) and releases (dev, edge, latest).

The build and push process uses buildx to push the individual images by digest (i.e. untagged) and reference them in a single, tagged manifest list. This avoids cluttering Docker Hub's tag list with <tag>-<arch> tags.

Fixes #2233

Copy link
Contributor

@srenatus srenatus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for looking into this!

I've got a few questions, please bear with me, I've never used buildx before.

  1. With the manifest list, can you still pull images by tag as before? I.e. openpolicyagent/opa:0.36.1, openpolicyagent/opa:latest, ``openpolicyagent/opa:edge`?
  2. What does it look like on dockerhub? I'm sure you've got some example of the desired end state...
  3. Our docker image smoke tests fail on the PR, it seems like we're missing something there: https://github.com/open-policy-agent/opa/runs/4879113973?check_suite_focus=true#step:4:59

Finally, do you have an idea how we could (smoke) test the produced binaries and images, preferable from github actions...? Are there any handy tools to emulate linux/arm64...?

Makefile Show resolved Hide resolved
@ngraef
Copy link
Contributor Author

ngraef commented Jan 20, 2022

  1. With the manifest list, can you still pull images by tag as before? I.e. openpolicyagent/opa:0.36.1, openpolicyagent/opa:latest, openpolicyagent/opa:edge?

Yes! Clients continue to pull images the same way. docker pull openpolicyagent/opa:0.36.1 defaults to pulling the image from the manifest list that matches the client architecture (linux/amd64 in most cases). You can force pulling a specific architecture using the --platform option, like docker pull --platform linux/arm64 openpolicyagent/opa:0.36.1.

If you're curious to see what a manifest list contains, run docker manifest inspect golang:1.17 or docker buildx imagetools inspect golang:1.17.

  1. What does it look like on dockerhub? I'm sure you've got some example of the desired end state...

You've probably seen it on most of the "official" images, like the example from golang below. In our case, it will just be two architectures rather than the 10 shown.

Screen Shot 2022-01-20 at 2 58 16 AM

  1. Our docker image smoke tests fail on the PR, it seems like we're missing something there: https://github.com/open-policy-agent/opa/runs/4879113973?check_suite_focus=true#step:4:59

Already fixed it before seeing your review 😀

Finally, do you have an idea how we could (smoke) test the produced binaries and images, preferable from github actions...? Are there any handy tools to emulate linux/arm64...?

Docker has setup-quemu-action that is helpful. It allows you to build and run images for different architectures. We don't need it to build in this case because we're cross-compiling, but we could use it to test the built arm64 images.

@srenatus
Copy link
Contributor

Thanks for your replies there, it's very helpful to me. 😃

but we could use it to test the built arm64 images.

Would you mind looking into that, too? It would be great if we had some assurance in our pipeline before publishing arm64 images.

@ngraef ngraef marked this pull request as draft January 21, 2022 04:37
@ngraef ngraef marked this pull request as ready for review January 21, 2022 21:44
@ngraef
Copy link
Contributor Author

ngraef commented Jan 21, 2022

but we could use it to test the built arm64 images.

Would you mind looking into that, too? It would be great if we had some assurance in our pipeline before publishing arm64 images.

I added smoke tests for arm64 images. I also added the platform string to the version command output.

@ngraef ngraef requested a review from srenatus January 21, 2022 21:47
@anderseknert
Copy link
Member

Wow, this is an awesome contribution @ngraef 👏

Just tried it and for the first time I can run OPA containerized on my M1 without the dreaded:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Nice! 👍

Copy link
Contributor

@srenatus srenatus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 This looks great and I'm thankful for you both taking on this decent amount of work on our build processes, and taking the time to explain the changes.

I haven't played with it locally yet, I'm about to do that next.

Dockerfile Show resolved Hide resolved
Makefile Show resolved Hide resolved
Makefile Show resolved Hide resolved
Makefile Show resolved Hide resolved
version/version.go Show resolved Hide resolved
@srenatus
Copy link
Contributor

Could you please rebase and squash this, so we can get it merged?

This change adds linux/arm64 binaries to the release. It also publishes an arm64
container image for all variants (standard, debug, rootless, static) and releases
(dev, edge, latest).

The build and push process uses buildx in order to push the individual
images by digest (i.e. untagged) and reference them in a single, tagged manifest
list. This avoids cluttering Docker Hub's tag list with `<tag>-<arch>` tags.

Fixes open-policy-agent#2233

Signed-off-by: Nick Graef <[email protected]>
@srenatus srenatus merged commit db4d987 into open-policy-agent:main Jan 24, 2022
msorens pushed a commit to msorens/opa that referenced this pull request Jan 30, 2022
This change adds linux/arm64 binaries to the release. It also publishes an arm64
container image for all variants (standard, debug, rootless, static) and releases
(dev, edge, latest).

The build and push process uses buildx in order to push the individual
images by digest (i.e. untagged) and reference them in a single, tagged manifest
list. This avoids cluttering Docker Hub's tag list with `<tag>-<arch>` tags.

Fixes open-policy-agent#2233

Signed-off-by: Nick Graef <[email protected]>
@bencooper222
Copy link

I don't think this is happening in practice? This image was released 25 days ago and is x86-only.

https://hub.docker.com/layers/opa/openpolicyagent/opa/0.42.0/images/sha256-83ee526b78c6204ccc1fce0021d6c2eacfc2393e402a88260a994875448195ad?context=explore

@anderseknert
Copy link
Member

@bencooper222 you’ll need to use the static image https://hub.docker.com/layers/opa/openpolicyagent/opa/latest-static/images/sha256-b14bf57a46c2d73f117f8bab45788581cf2fddd87f16a888ba4e1d05d347b34d?context=explore

@ngraef
Copy link
Contributor Author

ngraef commented Jul 29, 2022

@bencooper222 This was partially reverted. See #4282 for more context.

@timlaroche
Copy link

Hi all, just wondering if #4282 will be reversed as it seems that the issue in #4280 regarding bytecodealliance/wasmtime#3183 has been closed as fixed? It would be nice to have the manifests for the non-static images also.

@srenatus
Copy link
Contributor

We still have problems testing it. There are not arm64 runners in Github, and we don't have the bandwidth to maintain our own arm-based runners on any other hardware. So we'd either have to ship something untested; or don't ship it at all

It could be worth retrying to test the images in Qemu. Last time I tried it, I ran into SIGILL exceptions.

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

Successfully merging this pull request may close these issues.

Publish arm64 binaries and container images
5 participants