spiffe-csi icon indicating copy to clipboard operation
spiffe-csi copied to clipboard

WIP: chore: use ko instead of docker to minimize the image size

Open developer-guy opened this issue 3 years ago • 5 comments

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

developer-guy avatar Oct 24 '22 14:10 developer-guy

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?

azdagron avatar Nov 21 '22 16:11 azdagron

Are we still interested in figuring out what our benefit is from this? If not, I will close it.

azdagron avatar Jan 12 '23 16:01 azdagron

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

developer-guy avatar Jan 12 '23 18:01 developer-guy

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.

azdagron avatar Jan 24 '23 21:01 azdagron

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.

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/passwd etc that some programs depend on -- though, if you're using scratch, 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 😄

imjasonh avatar Jan 25 '23 18:01 imjasonh