Dlaczego podstawowy obraz platformy Docker Java 11 jest tak duży? (openjdk: 11-jre-slim)


145

Ogłoszono, że Java 11 będzie najnowszą wersją LTS. Więc staramy się uruchomić nowe usługi w oparciu o tę wersję Java.

Jednak podstawowy obraz platformy Docker dla języka Java 11 jest znacznie większy niż jego odpowiednik dla języka Java 8:

(Zastanawiam tylko oficjalnego OpenJDK oraz Najlżejszy obrazy dla każdej wersji Java).

Głębsze kopanie pozwoliło odkryć następujące „rzeczy”:

  • openjdk:11-jre-slimobrazu wykorzystuje obraz bazowej debian:sid-slim. Powoduje to 2 problemy:

    • jest to 60 MB większe niż alpine:3.8

    • że Debiansid wersje są niestabilne

  • openjdk-11-jre-headlesspakiet zainstalowany w obrazie jest 3 razy większa niż openjdk8-jre(wewnątrz pojemnika działa 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/

      Idąc głębiej, odkryłem „źródło” tego ciężaru - to modulesplik JDK:

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

A teraz pojawiły się pytania:

  • Dlaczego alpinenie jest już używany jako obraz podstawowy dla smukłych obrazów Java 11?

  • Dlaczego niestabilna wersja sid jest używana dla obrazów LTS Java?

  • Dlaczego pakiet slim / headless / JRE dla OpenJDK 11 jest tak duży w porównaniu z podobnym pakietem OpenJDK 8?

    • Co to za plik modułów , który daje 135 MB w OpenJDK 11?

UPD : jako rozwiązanie tych wyzwań można by użyć następującej odpowiedzi: aplikacja Java 11 jako obraz dockera


1
No cóż, nowe wersje (JDK 9+) Javy są zmodularyzowane , co wyjaśnia, dlaczego istnieją moduły w wersji 11 vs 8.
Zachary Craig

1
Powiązane możliwe do przeczytania - Benchmarking Debian vs Alpine jako podstawowy obraz
Dockera

13
Nie ma JRE 11, więc masz pełny JDK. Możesz tworzyć kompaktowe środowiska, nawet cieńsze niż JRE 8, ale wymaga to rzeczywistej aplikacji modułowej, aby zależności były znane.
Holger

1
Oprócz powyższego, nie wszystkie moduły, które uznasz za przyczynę wzrostu rozmiaru, są w rzeczywistości wymagane dla twoich aplikacji. Ale aby dowiedzieć się, które z nich należy przejść do stworzenia aplikacji modułowej. Możesz dowiedzieć się więcej o jlink (wprowadzonym w Javie9) w tym celu.
Naman

1
Czy może być lepszy czas na przeczytanie tego online - twitter.com/LogicTheoryIO/status/1064503559071371265
Naman

Odpowiedzi:


172

Dlaczego alpinenie jest już używany jako obraz podstawowy dla smukłych obrazów Java 11?

To dlatego, że niestety nie ma obecnie oficjalnej stabilnej wersji OpenJDK 11 dla Alpine.

Alpine używa musl libc, w przeciwieństwie do standardowego glibc używanego przez większość Linuksów, co oznacza, że ​​JVM musi być kompatybilny z musl libc, aby wspierać waniliowy Alpine. Musl port OpenJDK jest rozwijany w ramach projektu Portola OpenJDK .

Aktualny stan podsumowano na stronie OpenJDK 11 :

Kompilacja Alpine Linux poprzednio dostępna na tej stronie została usunięta z JDK 11 GA. Nie jest gotowy do produkcji, ponieważ nie został wystarczająco dokładnie przetestowany, aby można go było uznać za kompilację GA. Zamiast tego użyj wersji JDK 12 Alpine Linux z wczesnym dostępem.

Jedyne stabilne wersje OpenJDK dla Alpine to obecnie 7 i 8, dostarczone przez projekt IcedTea .

Jeśli jednak chcesz rozważyć inne rozwiązanie niż oficjalny OpenJDK, Zulu OpenJDK firmy Azul oferuje atrakcyjną alternatywę:

  • Obsługuje Java 11 na Alpine musl (wersja 11.0.2 w momencie pisania);
  • Jest to certyfikowana kompilacja OpenJDK, zweryfikowana przy użyciu pakietu zgodności OpenJDK TCK;
  • Jest darmowy, open source i gotowy na Docker ( Dockerhub ).

Aby uzyskać informacje o dostępności pomocy technicznej i harmonogramie, zobacz plan pomocy technicznej firmy Azul .

Aktualizacja, 06.03.19: Od wczoraj openjdk11jest dostępna w repozytoriach Alpine! Można go było złapać na Alpine za pomocą:

apk --no-cache add openjdk11

Pakiet jest oparty na jdk11ugałęzi OpenJDK plus przeniesione poprawki z projektu Portola, wprowadzone z następującym PR . Uznanie i wielkie podziękowania dla zespołu Alpine.

Dlaczego niestabilna wersja sid jest używana dla obrazów LTS Java?

To uczciwe pytanie / prośba. W rzeczywistości istnieje otwarte zgłoszenie do udostępnienia Java 11 w stabilnej wersji Debiana:
https://github.com/docker-library/openjdk/issues/237

Aktualizacja, 26.12.18: Problem został rozwiązany, a teraz szczupły obraz OpenJDK 11 jest oparty na stretch-backportsOpenJDK 11, który został niedawno udostępniony ( link PR ).

Dlaczego pakiet slim / headless / JRE dla OpenJDK 11 jest tak duży w porównaniu z podobnym pakietem OpenJDK 8? Co to za plik modułów , który daje 135 MB w OpenJDK 11?

Java 9 wprowadziła system modułów, który jest nowym i ulepszonym podejściem do grupowania pakietów i zasobów w porównaniu z plikami jar. Ten artykuł firmy Oracle zawiera bardzo szczegółowe wprowadzenie do tej funkcji:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

modulesPlik łączy wszystkie moduły dostarczane wraz z JRE. Pełną listę modułów można wydrukować za pomocą java --list-modules. modulesjest rzeczywiście bardzo dużym plikiem i jak skomentowano, zawiera wszystkie standardowe moduły i dlatego jest dość rozdęty.

Należy jednak zauważyć, że zastępuje rt.jari tools.jarstał się przestarzały, między innymi, więc biorąc pod uwagę rozmiar w modulesporównaniu do kompilacji OpenJDK starszych niż 9, rozmiary rt.jari tools.jarpowinny zostać odjęte (powinny zajmować około 80 MB łącznie) .


9

od 07.2019 https://adoptopenjdk.net/ ma oficjalne wsparcie Alpine dla Java 11:

Jednak moduły ( jmods , jlink) nadal uważa się, gdy jeden montuje minimalny aplikacji.

Uwaga : szczupłe obrazy nie zawierają niektórych modułów (takich jak java.sql) - są one wyraźnie wykluczone ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/s-java.sh#L2lim )


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.