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

Generalize container image build to target other CPU architectures #26

Closed
wants to merge 3 commits into from

Conversation

bcfriesen
Copy link

With this change, the target architecture for the container image can be selected with environment variables in the build environment, rather than being hard-coded into the Makefile. If the GOOS and GOARCH environment variables are unspecified, the container image is built to target linux/amd64, which is the same behavior as before.

This has been tested with linux/arm64, which takes around 15 minutes to build the SMD image on a modern x86-based server.

One thing I don't like about this change is that the Dockerfile now downloads a golang container image from the internet, which seems to conflict with software provenance goals for the project. I am not sure what is the best approach to address that.

@bcfriesen
Copy link
Author

Partially addresses OpenCHAMI/bss#24, but only for SMD.

@alexlovelltroy
Copy link
Member

This PR is still marked as a WIP, but we have some relevant input given our previous forays into multiarch builds.

  1. We need to be able to build both binaries and containers with the pipeline using github actions and goreleaser. Check out https://goreleaser.com/cookbooks/multi-platform-docker-images/ for guidance.

  2. Where we're using CGO instead of pure GO, there are areas where building the binary may not work correctly because it links to existing C libraries that are built for only one architecture. Be sure to test that the binaries function before adding them to containers.

  3. The wolfi base image we rely on should be fine as a multi-arch base, but we had some errors a while ago that made me wonder if we were specifying it correctly.

@bcfriesen
Copy link
Author

Thanks! I'll work on all 3 of those.

With this change, the target architecture for the container image can be
selected with environment variables in the build environment, rather than being
hard-coded into the Makefile. If the `GOOS` and `GOARCH` environment variables
are unspecified, the container image is built to target `linux/amd64`, which is
the same behavior as before.

This has been tested with `linux/arm64`, which takes around 15 minutes to build
the SMD image on a modern x86-based server.
@bcfriesen bcfriesen force-pushed the friesen/arm64-quickstart branch from 112ee57 to 69f8b7d Compare August 24, 2024 21:59
@bcfriesen
Copy link
Author

Working on item 1, I ran into some problems testing goreleaser on my workstation - some issue with Docker contexts that I don't yet understand but which seems to be documented in goreleaser/goreleaser#4392.

@bcfriesen
Copy link
Author

Working on item 1, I ran into some problems testing goreleaser on my workstation - some issue with Docker contexts that I don't yet understand but which seems to be documented in goreleaser/goreleaser#4392.

That was fixed by updating goreleaser. On to the next problem:

 > [stage-1 3/8] RUN set -ex     && apk -U upgrade     && apk add --no-cache curl:
0.104 + apk -U upgrade
0.129 fetch https://packages.wolfi.dev/os/x86_64/APKINDEX.tar.gz
0.398 WARNING: opening from cache https://packages.wolfi.dev/os: No such file or directory
0.398 ERROR: Not continuing due to stale/unavailable repositories.Use --force-missing-repositories to continue.

@alexlovelltroy
Copy link
Member

closed because we found another way to address it in #40

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.

2 participants