Por que a imagem do Java 11 base Docker é tão grande? (openjdk: 11-polegadas)

145

O Java 11 é anunciado como a versão mais recente do LTS. Então, estamos tentando iniciar novos serviços com base nesta versão Java.

No entanto, a imagem base do Docker para Java 11 é muito maior que o equivalente ao Java 8:

(Estou considerando apenas o OpenJDK oficial e as imagens mais leves para cada versão do Java.)

Uma escavação mais profunda descobriu as seguintes "coisas":

  • a openjdk:11-jre-slimimagem usa a imagem base debian:sid-slim. Isso traz 2 questões:

    • isso é 60 MB maior que alpine:3.8

    • as versões do Debiansid são instáveis

  • o openjdk-11-jre-headlesspacote instalado na imagem é 3 vezes maior que openjdk8-jre(dentro do contêiner do Docker em execução):

    • 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/

      Aprofundando, descobri a "raiz" desse peso - é o modulesarquivo do JDK:

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

Então, agora as perguntas que vieram:

  • Por que alpinenão é mais usado como imagem base para imagens slim do Java 11?

  • Por que a versão sid instável é usada para imagens Java LTS?

  • Por que o pacote slim / headless / JRE para o OpenJDK 11 é tão grande em comparação com o pacote OpenJDK 8 semelhante?

    • O que é esse arquivo de módulos que traz 135 MB no OpenJDK 11?

UPD : como solução para esses desafios, pode-se usar esta resposta: Aplicativo Java 11 como imagem do docker

radistao
fonte
1
Bem, para uma nova versão (JDK 9+) do Java são modularizadas , o que explica por que existem módulos 11 ou 8.
Zachary Craig
1
Leitura relacionada possivelmente - Comparação entre o Debian e o Alpine como uma base Docker Image
Naman
13
Não há JRE 11, então o que você tem é um JDK completo. É possível criar ambientes compactos, ainda mais finos que o JRE 8, mas isso requer uma aplicação modular real, para que as dependências sejam conhecidas.
Holger
1
Além do exposto, nem todos os módulos encontrados como motivo de aumento de tamanho são realmente necessários para seus aplicativos. Mas, para descobrir quais você deve avançar para a criação de um aplicativo modular. Você pode descobrir mais sobre o jlink (introduzido no Java9) por esse motivo.
Naman
1
Qual seria o melhor momento para ler isso on-line - twitter.com/LogicTheoryIO/status/1064503559071371265
Naman

Respostas:

172

Por que alpinenão é mais usado como imagem base para imagens slim do Java 11?

Isso porque, infelizmente, não existe atualmente nenhuma compilação oficial estável do OpenJDK 11 para a Alpine.

O Alpine usa o musl libc, em oposição ao glibc padrão usado pela maioria dos Linuxs, o que significa que uma JVM deve ser compatível com o musl libc para suportar o baunilha Alpine. A porta principal do OpenJDK está sendo desenvolvida no projeto Portola do OpenJDK .

O status atual é resumido na página do OpenJDK 11 :

A versão do Alpine Linux anteriormente disponível nesta página foi removida a partir do JDK 11 GA. Não está pronto para produção, porque não foi testado completamente o suficiente para ser considerado uma compilação do GA. Por favor, use a versão JDK 12 Alpine Linux de acesso antecipado em seu lugar.

As únicas versões estáveis ​​do OpenJDK para o Alpine atualmente são 7 e 8, fornecidas pelo projeto IcedTea .

No entanto - se você quiser considerar outro que não seja o OpenJDK oficial, o Zulu OpenJDK da Azul oferece uma alternativa atraente:

  • Ele suporta Java 11 no site Alpine (versão 11.0.2 até o momento da redação);
  • É uma compilação OpenJDK certificada, verificada usando o conjunto de conformidade OpenJDK TCK;
  • É gratuito, de código aberto e pronto para o docker ( Dockerhub ).

Para disponibilidade e roteiro de suporte , consulte Roteiro de suporte da Azul .

Atualização, 06/03/19: A partir de ontem, openjdk11está disponível nos repositórios Alpine! Pode ser acessado no Alpine usando:

apk --no-cache add openjdk11

O pacote é baseado na jdk11uramificação do OpenJDK, além de correções portadas do projeto Portola, introduzido com o seguinte PR . Muitos elogios e muito obrigado à equipe Alpine.

Por que a versão sid instável é usada para imagens Java LTS?

Essa é uma pergunta / solicitação justa. Na verdade, existe um ticket aberto para o fornecimento do Java 11 em uma versão estável do Debian:
https://github.com/docker-library/openjdk/issues/237

Atualização, 26/12/18: o problema foi resolvido e agora a imagem slim do OpenJDK 11 é baseada no stretch-backportsOpenJDK 11, que foi disponibilizado recentemente ( link para PR ).

Por que o pacote slim / headless / JRE para o OpenJDK 11 é tão grande em comparação com o pacote OpenJDK 8 semelhante? O que é esse arquivo de módulos que traz 135 MB no OpenJDK 11?

O Java 9 introduziu o sistema de módulos, que é uma abordagem nova e aprimorada para agrupar pacotes e recursos, em comparação aos arquivos jar. Este artigo da Oracle fornece uma introdução muito detalhada a esse recurso:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

O modulesarquivo agrupa todos os módulos fornecidos com o JRE. A lista completa de módulos pode ser impressa com java --list-modules. modulesé realmente um arquivo muito grande e, como comentado, contém todos os módulos padrão e, portanto, é bastante inchado.

Uma coisa a ser observada, no entanto, é que ela substitui rt.jare tools.jarficou obsoleta, entre outras coisas, portanto, ao considerar o tamanho de modulesquando comparado com compilações anteriores ao OpenJDK, os tamanhos de rt.jare tools.jardevem ser subtraídos (eles devem ocupar 80 MB combinados) .

valiano
fonte
9

como em 07.2019, https://adoptopenjdk.net/ possui suporte oficial da Alpine para Java 11:

No entanto, os módulos ( jmods , jlink) ainda devem ser considerados quando se monta a aplicação mínima.

Nota : as imagens slim não contêm alguns módulos (como java.sql) - elas são excluídas explicitamente ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L233 )

radistao
fonte