java docker alpine java-11

¿Por qué es tan grande la imagen de Java 11 base Docker?(openjdk: 11-jre-slim)



alpine java-11 (2)

Java 11 se anuncia como la versión más reciente de LTS. Por lo tanto, estamos intentando iniciar nuevos servicios basados ​​en esta versión de Java.

Sin embargo, la imagen de Docker base para Java 11 es mucho más grande que el equivalente para Java 8:

(Estoy considerando solo el OpenJDK oficial y las imágenes más ligeras para cada versión de Java).

Una excavación más profunda descubrió las siguientes "cosas":

  • La imagen de openjdk:11-jre-slim usa la imagen base debian:sid-slim . Esto trae 2 cuestiones:

    • esto es 60 MB más grande que el alpine:3.8

    • Las versiones sid Debian son inestables.

  • El openjdk-11-jre-headless instalado en la imagen es 3 veces más grande que el openjdk8-jre (dentro del contenedor Docker).

    • openjdk:8-jre-alpine :

      / # du -hs /usr/lib/jvm/java-1.8-openjdk/jre/lib/ 57.5M /usr/lib/jvm/java-1.8-openjdk/jre/lib/

    • openjdk:11-jre-slim :

      # du -sh /usr/lib/jvm/java-11-openjdk-amd64/lib/ 179M /usr/lib/jvm/java-11-openjdk-amd64/lib/

      Profundizando, descubrí la "raíz" de esta pesadez: es el archivo de modules del JDK:

      # ls -lhG /usr/lib/jvm/java-11-openjdk-amd64/lib/modules 135M /usr/lib/jvm/java-11-openjdk-amd64/lib/modules

Entonces, ahora las preguntas que vinieron:

  • ¿Por qué ya no se utiliza alpine como imagen base para las imágenes delgadas de Java 11?

  • ¿Por qué se usa la versión sid inestable para imágenes LTS Java?

  • ¿Por qué el paquete slim / headless / JRE para OpenJDK 11 es tan grande en comparación con el paquete OpenJDK 8 similar?

    • ¿Qué es este archivo de módulos que trae 135 MB en OpenJDK 11?

UPD : como una solución para estos desafíos, se podría usar esta respuesta: la aplicación Java 11 como imagen docker

¿Por qué ya no se utiliza alpine como imagen base para las imágenes delgadas de Java 11?

Eso es porque, lamentablemente, no hay una versión oficial estable de OpenJDK 11 para Alpine actualmente.

Alpine usa musl libc, a diferencia del glibc estándar usado por la mayoría de los Linux, lo que significa que una JVM debe ser compatible con musl libc para admitir Vanilla Alpine. El puerto musl OpenJDK se está desarrollando bajo el proyecto Portola de OpenJDK.

El estado actual se resume en la página OpenJDK 11 :

  • La versión de Alpine Linux anteriormente disponible en esta página se eliminó a partir de JDK 11 GA. No está listo para la producción porque no se ha probado lo suficiente como para ser considerado una compilación GA. Por favor, use la versión de JDK 12 Alpine Linux de acceso anticipado en su lugar.

Las únicas versiones estables de OpenJDK para Alpine actualmente son 7 y 8, proporcionadas por el proyecto IcedTea .

Sin embargo, si está dispuesto a considerar otro OpenJDK oficial, Zulu OpenJDK de Azul ofrece una alternativa convincente:

  • Es compatible con Java 11 en Alpine musl (versión 11.0.2 en el momento de la escritura);
  • Es una compilación certificada de OpenJDK, verificada mediante el conjunto de cumplimiento de OpenJDK TCK;
  • Es gratis, de código abierto y listo para docker ( Dockerhub ).

Para conocer la disponibilidad de soporte y la hoja de ruta, consulte Azul hoja de ruta de soporte

Actualización, 6/6/19: ¡ A partir de ayer, openjdk11 está disponible en los repositorios de Alpine! Se puede agarrar en Alpine usando:

apk --no-cache add openjdk11 --repository=http://dl-cdn.alpinelinux.org/alpine/edge/community

El paquete se basa en la rama OpenJDK de jdk11u más arreglos portados del proyecto Portola, introducido con el siguiente PR . Felicitaciones y muchas gracias al equipo alpino.

¿Por qué se usa la versión sid inestable para imágenes LTS Java?

Esa es una pregunta / solicitud justa. En realidad, hay un ticket abierto para proporcionar Java 11 en una versión estable de Debian:
https://github.com/docker-library/openjdk/issues/237

Actualización, 26/12/18: El problema se ha resuelto, y ahora la imagen delgada de OpenJDK 11 se basa en OpenJDK 11, que se puso a disposición recientemente ( enlace PR ).

¿Por qué el paquete slim / headless / JRE para OpenJDK 11 es tan grande en comparación con el paquete OpenJDK 8 similar? ¿Qué es este archivo de módulos que trae 135 MB en OpenJDK 11?

Java 9 introdujo el sistema de módulos, que es un enfoque nuevo y mejorado para agrupar paquetes y recursos, en comparación con los archivos jar. Este artículo de Oracle ofrece una introducción muy detallada a esta característica:
modularized

El archivo de modules agrupa todos los módulos enviados con el JRE. La lista completa de módulos podría imprimirse con java --list-modules . modules son, de hecho, un archivo muy grande y, como se comentó, contiene todos los módulos estándar y, por lo tanto, está bastante hinchado.

Sin embargo, una cosa a tener en cuenta es que reemplaza rt.jar y tools.jar que quedaron en desuso, entre otras cosas, por lo que al considerar el tamaño de los modules al compararlos con las compilaciones de OpenJDK anteriores a 9, los tamaños de rt.jar y las tools.jar debe restar (deberían ocupar unos 80 MB combinados).

como para el 07.2019 https://adoptopenjdk.net/ tiene soporte oficial de Alpine para Java 11:

Sin embargo, los módulos ( jmods , jlink ) aún se deben considerar cuando uno ensambla la aplicación mínima.

Nota : las imágenes delgadas no contienen algunos módulos (como java.sql ); se excluyen explícitamente ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/lim-jsjp. sh # L233 )