Hello Tal, Interesting thread. First of all, I totally agree with you on the last sentence : base image overhead is __too much__ of a concern (even though you’ll have to download it once per kubernetes nodes but the real gain of size reduction effort is more on the application dependent layer). But I think we should have a unique “ONAP base image” (which will derive from any real base image) especially for java as most (all?) of the java based project in ONAP requires only “java” binary. We don’t even need JDK for the run time. With that, it would be easier for anyone to choose its own base image (from dockerhub or even company base image), change only one Dockerfile and be able to build all the containers based on java for ONAP.
It would be more complicated (maybe with “ONBUILD” and clear state that every project has a “requirements.txt” file) to do the same with Python based projects but still it would be a huge win for companies wanting to package ONAP their own way. On the OpenJDK issue, it’s important to remember that moving to jdk11 is not really optional as jdk8 supports ends soon and the next LTS is jdk11. So there are several way to have an image with OpenJDK: * Use an “official” openjdk image from dockerhub (https://hub.docker.com/_/openjdk). Choice is limited to oraclelinux (but with 6months support so not an option), Debian or WindowsServer. The “11-jre” is based on Debian stretch and takes 479MB (again it’s more for information than anything else) and the 11-jdk takes 821Mb So it would be based on Debian (which is very fine for me 😉) * Take an image (like Debian, centos, …) and install java11 (jre or jdk) with the package manager As far as I understand threads from Jenkins thread, Centos seems to be the best choice. Quick test (sure Centos experts can do better) shows 428Mb for JRE (again, it’s not the most important) and no clue for JDK (don’t know how to do sorry) on Centos. * Use “adoptopenjdk” image They’re based on ubuntu or alpine Alpine JRE is 137Mb, JDK is 334Mb Ubuntu JRE is 245Mb, JDK is 442Mb. Support for arm64 is claimed but not sure they’re using fat files… Also, as stated in their github (https://github.com/AdoptOpenJDK/openjdk-docker) “The Alpine Linux and the slim images are not yet TCK certified”. * Use “distroless” java packages from google (https://github.com/GoogleContainerTools/distroless) which already has a java 11 version (gcr.io/distroless/java:11) and its sized 189Mb. This distroless comes with the minimum minimum for the application run (so no shell for example) and I don’t know if there’s arm based images So it seems for me that the easiest solution would be to use the official one or centos based one and the best for security would be distroless (but we would have to change a lot of our habits). Regards, --- Sylvain Desbureaux De : <[email protected]> au nom de Tal Liron <[email protected]> Répondre à : "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Date : mercredi 6 mars 2019 à 20:12 À : onap-discuss <[email protected]> Objet : [onap-discuss] [cia] Alpine might not be the best choice It's worth looking at the experience of other open source projects. For example, the Jenkins project is moving away from Alpline<https://issues.jenkins-ci.org/browse/JENKINS-55547>. The issue specifically is OpenJDK support moving forward. At this moment, it's not clear that the OpenJDK project will publish Alpine-based images, so the Jenkins project cannot rely on that path. This is also being discussed in the mailing list<https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-dev/9kIJFrk9vRA/S3bcVNzKAAAJ>. It's worth following the conversation there. Also note that Alpine's reputation of being smallest is not necessarily deserved. Here are some observations from our own research on OpenJDK images: * Red Hat Minimal + OpenJDK = 313 MB * Alpine based OpenJDK = 340 MB * Red Hat based OpenJDK 8 image = 456 MB * Debian based OpenJDK = 839 MB As I keep reiterating, as long as all ONAP images derive from the same base, as they eventually will, the actual size of that base is a non issue and we should be choosing our reference implementation based on other criteria such as community health, stability, security, ongoing maintenance, developer mindshare, etc. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15915): https://lists.onap.org/g/onap-discuss/message/15915 Mute This Topic: https://lists.onap.org/mt/30288909/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
