openzipkin-attic
Capture rationale and impact for using the debug images
In a recent pull request to zipkin, @devinsba noticed we are using the debug distroless image. We should be aware if this is adding heft to our based image which has grown substantially since moving off JDK 1.8
In other repos, we are starting to add RATIONALE.md, and this could be a good thing to start with.
We are about to cut a new zipkin version, but for starters here's where we are > 250MiB. The last version prior to distroless (2.12.3) was < 150MiB.
openzipkin/zipkin 2.12.3 69d91daa0839 6 months ago 147MB
openzipkin/zipkin 2.16.2 b4a4e6e796ee 10 days ago 253MB
We definitely grew otherwise, some of it I aim to cleanup in the next release or so. Ex 2.16.2 is dramatically larger than 2.12.3: however it isn't a hundred megs larger.
zipkin-server-2.12.3-exec.jar 2019-03-01 16:06 39726640
zipkin-server-2.16.2-exec.jar 2019-08-24 15:08 56548977
I tried to build w/o the -debug and it seems busybox isn't there.. No idea the space saving if we were able to avoid it.
Step 11/17 : RUN ["/busybox/sh", "-c", "adduser -g '' -h /zipkin -D zipkin"]
---> Running in e50ea9179b1f
OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/busybox/sh\": stat /busybox/sh: no such file or directory": unknown
Can get the numbers into a RATIONALE next week. The debug image just adds BusyBox which was just a couple megabytes or so and is definitely good to keep. Looks like the Java image is getting larger by adding dependencies for swing type libraries, which I remember our old image was explicitly deleting since we don't have a gui. We'll probably need to go back to manual trimming in a base image to get those bytes back.
https://github.com/GoogleContainerTools/distroless/commits/master/java
