astefanutti commented on issue #2007: URL: https://github.com/apache/camel-k/issues/2007#issuecomment-776543672
It sounds like a sensible proposition. The decision to use `adoptopenjdk/openjdk11:slim` was primarily taken based on the size criteria, as we moved away from a large image. Here are the listing of few Java 11 image candidates (sizes are _uncompressed_): ``` REPOSITORY TAG IMAGE ID SIZE adoptopenjdk/openjdk11 ubi-minimal dab86988d321 454MB adoptopenjdk/openjdk11 ubi-slim 49f5b9a9c785 557MB adoptopenjdk/openjdk11 slim c6089e7f0313 370MB adoptopenjdk/openjdk11 debian-slim 03e78c06ffc5 426MB gcr.io/distroless/java 11 681cb422d023 197MB ``` I think `adoptopenjdk/openjdk11:ubi-minimal` size increase is acceptable, compared to `adoptopenjdk/openjdk11:slim`. Obviously, size is a debatable criteria. Some argue that _distroless_ images reduce the attack surface. There is an interesting discussion to move Kubernetes images to using _distroless_ images: https://github.com/kubernetes/enhancements/issues/1729. One benefit that I see is to reduce CVE noise. Lots of rebuilds can be triggered because of CVEs, while they affected unused libraries. For Goland operators, it seems "troubleshooting" may be the only use case that requires an operator system in the image. That is however alleviated with `kubectl debug` and ephemeral containers. I'm not sure how easy that is to be _distroless_ for the JDK, though, ideally AdoptOpenJDK would provide _distroless_ images. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
