spiffe-csi
spiffe-csi copied to clipboard
WIP: chore: use ko instead of docker to minimize the image size
Signed-off-by: Batuhan Apaydın [email protected]
It requires ko => v0.12.0 to use the --bare option with the local daemon.
https://github.com/ko-build/ko/pull/820
Can you help me understand the advantage here? Our image already just contains the single spiffe-csi-driver binary. How big is the image size reduction and where is it coming from?
Are we still interested in figuring out what our benefit is from this? If not, I will close it.
ah sorry, I forgot that ☝️ This is not a multi-stage build, this is the reason why I do this TBH, as it uses the go image for the final image, which makes it quite heavy for the run-time, and it causes to increase in the time while loading it into the kind node itself, ko will take care of everything for us for free, it uses distroless base image, and it includes only the binary it builds. does that make sense? PTAL @imjasonh
as it uses the go image for the final image, which makes it quite heavy for the run-time, and it causes to increase in the time while loading it into the kind node itself
This is not the case. The Dockerfile uses a multi-stage build. The final produced image uses scratch as the base and copies in the built binary from the "base" stage (which is the golang-alpine image). The final image only has a single binary in it.
This is not the case. The Dockerfile uses a multi-stage build. The final produced image uses
scratchas the base and copies in the built binary from the "base" stage (which is the golang-alpine image). The final image only has a single binary in it.
That's great to hear! Minimal images are definitely a good practice, and they don't get much more minimal than scratch 😆
I think there could still be a benefit to using ko, though I understand any change is hard to justify, so if you stick with a multi-stage Dockerfile build I think you're still in a good place.
Some of the benefits of ko are:
- not requiring Docker to be running on your machine when you build the image locally (or in CI, though most CI environments do provide Docker regardless)
- generated SBOMs of your image, including the Go modules included in the actual built binary
- easy multi-platform builds, without the need for
docker buildx - by default, the base image is the minimal
cgr.dev/chainguard/static, which includes a few things like ca-certs, timezone data, and placeholder files for/etc/passwdetc that some programs depend on -- though, if you're usingscratch, you probably don't 😆
If those sound worth exploring, let me know. If you'd prefer to stick with Dockerfiles, that's fine too. Thanks for starting this conversation @developer-guy 😄