Hi,
I did some quick prototyping on the slimmed down docker images, and I was
able to cut the docker image size by ~40% with a minimum effort [1] (using
a multi-stage build + trimming examples / opt + using slimmed down JRE
image).
I think this might be a low hanging fruit for reducing MTTR in some
scenarios, but I'd like to hear other opinions on the topic.
Pushing this forward would require us to release twice as many images as we
do now (the current images + slimmed down versions).
Using /opt dependencies + /examples, would look something like this from an
user perspective:
FROM flink:1.14.0-scala_2.12-slim
COPY --from=flink:1.14.0-scala_2.12
/opt/flink/opt/flink-s3-fs-presto-1.15-SNAPSHOT.jar /opt/flink/plugins/s3
COPY --from=flink:1.14.0-scala_2.12
/opt/flink/examples/streaming/TopSpeedWindowing.jar /opt/flink/usrlib
Size of the 1.15 images (java 11):
~/Workspace/apache/flink-docker> docker images | grep flink | grep 1.15
flink 1.15
e96a3a3eaab2 15 minutes ago 702MB
flink 1.15-slim
e417b7665522 17 minutes ago 427MB
Do you see a benefits of this effort? Should image size / distribution size
be a concern with the modern deployments [2] ?
[1]
https://github.com/dmvk/flink-docker/commit/f866b3e57eacd0e6534b80fd0a1618cb30bbb36a
[2]
https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-how-and-why-to-build-small-container-images
Best,
D.
