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
Switch to a slimmer distroless base image #738
Conversation
Codecov Report
@@ Coverage Diff @@
## main #738 +/- ##
==========================================
- Coverage 79.89% 79.30% -0.59%
==========================================
Files 124 127 +3
Lines 8369 8636 +267
==========================================
+ Hits 6686 6849 +163
- Misses 1464 1563 +99
- Partials 219 224 +5
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will fix these minor issues in a follow-up since Moyer is OOO.
At a high level, it switches us to a distroless base container image, but that also includes several related bits: - Add a writable /tmp but make the rest of our filesystems read-only at runtime. - Condense our main server binaries into a single pinniped-server binary. This saves a bunch of space in the image due to duplicated library code. The correct behavior is dispatched based on `os.Args[0]`, and the `pinniped-server` binary is symlinked to `pinniped-concierge` and `pinniped-supervisor`. - Strip debug symbols from our binaries. These aren't really useful in a distroless image anyway and all the normal stuff you'd expect to work, such as stack traces, still does. - Add a separate `pinniped-concierge-kube-cert-agent` binary with "sleep" and "print" functionality instead of using builtin /bin/sleep and /bin/cat for the kube-cert-agent. This is split from the main server binary because the loading/init time of the main server binary was too large for the tiny resource footprint we established in our kube-cert-agent PodSpec. Using a separate binary eliminates this issue and the extra binary adds only around 1.5MiB of image size. - Switch the kube-cert-agent code to use a JSON `{"tls.crt": "<b64 cert>", "tls.key": "<b64 key>"}` format. This is more robust to unexpected input formatting than the old code, which simply concatenated the files with some extra newlines and split on whitespace. - Update integration tests that made now-invalid assumptions about the `pinniped-server` image. Signed-off-by: Matt Moyer <moyerm@vmware.com>
At a high level, it switches us to a distroless base container image (see #448), but that also includes several related bits:
Add a writable /tmp but make the rest of our filesystems read-only at runtime.
Condense our main server binaries into a single pinniped-server binary. This saves a bunch of space in the image due to duplicated library code (see Merge all Pinniped servers into a single binary to save image size #449). The correct behavior is dispatched based on
os.Args[0]
, and thepinniped-server
binary is symlinked topinniped-concierge
andpinniped-supervisor
.Strip debug symbols from our binaries. These aren't really useful in a distroless image anyway and all the normal stuff you'd expect to work, such as stack traces, still does.
Add a separate
pinniped-concierge-kube-cert-agent
binary with "sleep" and "print" functionality instead of using builtin /bin/sleep and /bin/cat for the kube-cert-agent. This is split from the main server binary because the loading/init time of the main server binary was too large for the tiny resource footprint we established in our kube-cert-agent PodSpec. Using a separate binary eliminates this issue and the extra binary adds only around 1.5MiB of image size.Switch the kube-cert-agent code to use a JSON
{"tls.crt": "<b64 cert>", "tls.key": "<b64 key>"}
format. This is more robust to unexpected input formatting than the old code, which simply concatenated the files with some extra newlines and split on whitespace.Update integration tests that made now-invalid assumptions about the
pinniped-server
image.Overall this trims our container image size from 254 MB (in v0.9.2) to roughly 54 MB!
Release note: