build our docker images for multiple platforms #1059
Conversation
Following this documentation: https://docs.docker.com/build/ci/github-actions/multi-platform/ This clears up a warning in our build, and makes it easier for folks on arm64 (like us macOS people) to pull and use the images. Along the way, I also fixed the warnings about using lowercase `as` when we use uppercase commands in our Dockerfile.
| - name: Set up QEMU | ||
| uses: docker/setup-qemu-action@v3 | ||
|
|
There was a problem hiding this comment.
I think this is optional if we want to support more platforms and it's recommended we use multiple native nodes or cross-compilation.
It seems the cross-compilation might be better here and it was what we were attempting but having problems. Wondering if:
Set the GOOS and GOARCH environment variables to the values of TARGETOS and TARGETARCH. The Go compiler uses these variables to do cross-compilation.
would have resolved that (example code)?
There was a problem hiding this comment.
Oh just checked the errors and they are:
5 warnings found (use docker --debug to expand):
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 59)
- FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" (line 7)
- JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals (line 86)
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 7)
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 41)
- FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" (line 7)
It's complaining because we should be using pre-defined BUILDPLATFORM variable
There was a problem hiding this comment.
Considered it, but it would require us to also be using arm64 libraries and os in the container itself.
First, we'd have to build libkmsp11 ourselves. The pre-built binary library Google releases has only amd64 builds. Building it ourself would mean having the team learn bazel and good bit more code in the Dockerfile.
Second, even though we don't have any other libraries that we build by hand, we don't actually run in arm64 in production right now. So, we'd have a different arch in our images on our local machines than what we use in prod. Bugs or just different behavior could lurk there.
Third, even with a pre-built arm library, we'd have to special case the dockerfile to work with it.
You didn't mention this, but the docs say the qemu stuff might slow our builds but I don't actually see that when comparing this PR's build image step vs a previous pr's.
So, I think we should stick with the qemu stuff until we have a good reason to move to arm64 (and there are some energy considerations we could make in the future! But we'd need some arm64 nodepools added to Mozilla's kubernetes cluster)
There was a problem hiding this comment.
Cool, thanks for the explanation. Yes, I did read that the recommendation came with dealing with the slowness, but your other reasons and there being no build time difference makes sense to move forward 
This is a port of mozilla-services/autograph#1063 (and mozilla-services/autograph#1060). Currently, we're doing a deploy to one of our staging environments on every merge to main this repo. That wasn't desired. Along the way, we also build arm64 versions of the docker image for convenience. See mozilla-services/autograph#1059
This is a port of mozilla-services/autograph#1063 (and mozilla-services/autograph#1060). Currently, we're doing a deploy to one of our staging environments on every merge to main this repo. That wasn't desired. Along the way, we also build arm64 versions of the docker image for convenience. See mozilla-services/autograph#1059
Following this documentation:
https://docs.docker.com/build/ci/github-actions/multi-platform/
This clears up a warning in our build, and makes it easier for folks on
arm64 (like us macOS people) to pull and use the images.
Along the way, I also fixed the warnings about using lowercase
aswhenwe use uppercase commands in our Dockerfile.