OpenCHAMI / smd

MIT License
0 stars 4 forks source link

Generalize container image build to target other CPU architectures #26

Closed bcfriesen closed 1 week ago

bcfriesen commented 3 months ago

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 commented 3 months ago

Partially addresses https://github.com/OpenCHAMI/bss/issues/24, but only for SMD.

alexlovelltroy commented 3 months ago

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 commented 3 months ago

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

bcfriesen commented 2 months ago

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 https://github.com/goreleaser/goreleaser/issues/4392.

bcfriesen commented 2 months ago

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 commented 1 week ago

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