Mengapa gambar Java 11 base Docker begitu besar? (openjdk: 11-jre-slim)


145

Java 11 diumumkan sebagai versi LTS terbaru. Jadi, kami mencoba memulai layanan baru berdasarkan versi Java ini.

Namun, gambar Docker dasar untuk Java 11 jauh lebih besar daripada yang setara untuk Java 8:

(Saya hanya mempertimbangkan OpenJDK resmi dan gambar paling ringan untuk setiap versi Java.)

Penggalian yang lebih dalam mengungkap "hal-hal" berikut:

  • yang openjdk:11-jre-slimgambar menggunakan gambar dasar debian:sid-slim. Ini membawa 2 masalah:

    • ini 60 MB lebih besar dari alpine:3.8

    • yang Debiansid versi yang tidak stabil

  • yang openjdk-11-jre-headlesspaket dipasang di gambar adalah 3 kali lebih besar daripada openjdk8-jre(dalam menjalankan Docker kontainer):

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

      Lebih dalam saya menemukan "root" dari berat ini - itu adalah modulesfile JDK:

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

Jadi, sekarang pertanyaan yang datang:

  • Mengapa alpinetidak digunakan lagi sebagai gambar dasar untuk gambar tipis Java 11?

  • Mengapa versi sid yang tidak stabil digunakan untuk gambar LTS Java?

  • Mengapa paket slim / headless / JRE untuk OpenJDK 11 begitu besar dibandingkan dengan paket OpenJDK 8 yang serupa?

    • Apa file modul ini yang membawa 135 MB di OpenJDK 11?

UPD : sebagai solusi untuk tantangan ini orang dapat menggunakan jawaban ini: aplikasi Java 11 sebagai docker image


1
Nah untuk satu versi baru (JDK 9+) Java dimodulasi , yang menjelaskan mengapa ada modul dalam 11 vs 8.
Zachary Craig


13
Tidak ada JRE 11, jadi yang Anda miliki, adalah JDK penuh. Anda dapat membuat lingkungan yang ringkas, bahkan lebih ramping dari JRE 8, tetapi membutuhkan aplikasi modular yang sebenarnya, sehingga ketergantungannya diketahui.
Holger

1
Selain hal di atas, tidak semua modul yang Anda temukan sebagai alasan peningkatan ukuran sebenarnya diperlukan untuk aplikasi Anda. Tetapi untuk mencari tahu yang mana Anda harus melanjutkan membuat aplikasi modular. Anda dapat mengetahui lebih lanjut tentang jlink (diperkenalkan di Java9) untuk itu.
Naman

1
Apa yang bisa menjadi waktu yang lebih baik untuk membaca ini secara online - twitter.com/LogicTheoryIO/status/1064503559071371265
Naman

Jawaban:


172

Mengapa alpinetidak digunakan lagi sebagai gambar dasar untuk gambar tipis Java 11?

Itu karena, sayangnya, tidak ada OpenJDK 11 build stabil resmi untuk Alpine saat ini.

Alpine menggunakan musl libc, berbeda dengan glibc standar yang digunakan oleh kebanyakan Linux di luar sana, yang berarti bahwa JVM harus kompatibel dengan musl libc untuk mendukung vanilla Alpine. Port OpenJDK musl sedang dikembangkan di bawah proyek Portola OpenJDK .

Status saat ini dirangkum pada halaman OpenJDK 11 :

Bangunan Alpine Linux yang sebelumnya tersedia di halaman ini telah dihapus pada JDK 11 GA. Ini belum siap produksi karena belum diuji cukup menyeluruh untuk dianggap sebagai pengembangan GA. Silakan gunakan JDK 12 Alpine Linux build awal sebagai gantinya.

Satu-satunya versi OpenJDK yang stabil untuk Alpine saat ini adalah 7 dan 8, disediakan oleh proyek IcedTea .

Namun - jika Anda ingin mempertimbangkan selain OpenJDK resmi, Zulu OpenJDK Azul menawarkan alternatif yang menarik:

  • Ini mendukung Java 11 pada Alpine musl (versi 11.0.2 pada saat penulisan);
  • Ini adalah bangunan OpenJDK bersertifikasi, diverifikasi menggunakan suite kepatuhan OpenJDK TCK;
  • Ini gratis, open source dan buruh pelabuhan siap ( Dockerhub ).

Untuk ketersediaan dan peta jalan dukungan , lihat Peta jalan dukungan Azul .

Pembaruan, 3/6/19: Sampai kemarin, openjdk11tersedia di repositori Alpine! Itu bisa diambil di Alpine menggunakan:

apk --no-cache add openjdk11

Paket ini didasarkan pada jdk11ucabang OpenJDK plus perbaikan porting dari proyek Portola, diperkenalkan dengan PR berikut . Kudos dan terima kasih yang sebesar-besarnya kepada tim Alpine.

Mengapa versi sid yang tidak stabil digunakan untuk gambar LTS Java?

Itu pertanyaan / permintaan yang adil. Sebenarnya ada tiket terbuka untuk menyediakan Java 11 pada rilis Debian yang stabil:
https://github.com/docker-library/openjdk/issues/237

Pembaruan, 26/12/18: Masalah ini telah diatasi, dan sekarang gambar ramping OpenJDK 11 didasarkan pada stretch-backportsOpenJDK 11 yang baru-baru ini tersedia ( tautan PR ).

Mengapa paket slim / headless / JRE untuk OpenJDK 11 begitu besar dibandingkan dengan paket OpenJDK 8 yang serupa? Apa ini file modul yang membawa 135 MB di OpenJDK 11?

Java 9 memperkenalkan sistem modul, yang merupakan pendekatan baru dan lebih baik untuk pengelompokan paket dan sumber daya, dibandingkan dengan file jar. Artikel dari Oracle ini memberikan pengantar yang sangat rinci untuk fitur ini:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

The modulesberkas bundel semua modul dikirimkan dengan JRE. Daftar lengkap modul dapat dicetak denganjava --list-modules . modulesmemang file yang sangat besar, dan seperti dikomentari, itu berisi semua modul standar, dan karena itu cukup membengkak.

Satu hal yang perlu diperhatikan adalah bahwa itu menggantikan rt.jardan tools.jaryang menjadi usang, antara lain, jadi ketika menghitung ukuran modulesketika membandingkan dengan pra-9 OpenJDK build, ukuran rt.jardan tools.jarharus dikurangi (mereka harus mengambil sekitar 80MB gabungan) .


9

untuk 07.2019 https://adoptopenjdk.net/ memiliki dukungan Alpine resmi untuk Java 11:

Namun, modul ( jmods ,jlink ) masih harus dipertimbangkan ketika seseorang mengumpulkan aplikasi minimal.

Catatan : gambar ramping tidak mengandung beberapa modul (seperti java.sql) - mereka dikecualikan secara eksplisit ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L233 )


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.