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

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

developer-guy
Copy link

Signed-off-by: Batuhan Apaydın [email protected]

It requires ko => v0.12.0 to use the --bare option with the local daemon.

ko-build/ko#820

@azdagron
Copy link
Member

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
Copy link
Member

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

@developer-guy
Copy link
Author

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

@azdagron
Copy link
Member

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.

@imjasonh
Copy link

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 😄

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.

3 participants