Java-buildpack: bin/supply untuk dukungan multi buildpack yang lebih baik

Kami sedang mengerjakan perpindahan ke kontrak buildpack yang diperluas termasuk /bin/finalize dan /bin/supply sebagai API utama (dengan /bin/compile mendelegasikan). Namun, saat ini tidak jelas seperti apa /bin/supply dalam buildpack non-final. Khususnya, kecuali sistem file terlihat seperti file JAR yang meledak, kami tidak melakukan apa pun di buildpack hari ini. Jika sistem file terlihat seperti file JAR yang meledak, itu juga akan menjadi aplikasi utama yang dijalankan, dan Java Buildpack akan menjadi buildpack terakhir.

Jadi jawaban singkatnya adalah meskipun pada akhirnya akan ada skrip /bin/supply , yang memungkinkan buildpack berjalan sebagai buildpack non-final, itu mungkin tidak akan melakukan apa pun, yang menurut saya bukan itu yang Anda harapkan .

apa yang ada dalam pikiran saya, adalah dapat menggunakan buildpack perantara untuk menyiapkan lebih banyak runtime + deps yang mungkin dibutuhkan aplikasi akhir.

contoh:
jika aplikasi non-java (ruby? nodejs? apa pun!) perlu menggunakan beberapa toples, maka alangkah baiknya untuk dapat memanfaatkan buildpack jave sebagai langkah perantara untuk menginstal versi Java yang diperlukan + kemungkinan deps (mungkin kami bahkan sedang membuat toples itu), sehingga ketika aplikasi terakhir berjalan, ia memiliki semua yang dibutuhkannya.

ini tentu saja dimungkinkan dengan membuat buildpack kustom, tetapi ini cenderung sangat tidak fleksibel, dengan versi runtime bawaan yang tidak dapat dikonfigurasi.
akan sangat bagus jika kita dapat memanfaatkan kekuatan multi-buildpacks (dengan buildpack yang sudah mengagumkan) untuk membuat pengaturan semacam ini.

Masalahnya seperti yang saya lihat, adalah bagaimana mengidentifikasi perilaku ini sambil memastikan /bin/detect berfungsi. Mengingat bahwa tidak akan ada JAR yang meledak pada sistem file (apa yang kita cari hari ini), bagaimana tepatnya buildpack tahu bahwa ia perlu menyumbangkan JRE? Kriteria apa yang dapat dipenuhi dalam kasus ini yang tidak menyebabkan /bin/detect memiliki positif palsu dalam skenario lain?

Kedua, karena default JRE, menjalankan JVM dengan java -jar ... naif dan tidak ada konfigurasi memori hampir pasti akan menyebabkan batas memori container terlampaui dan container didaur ulang. Bagaimana cara memastikan bahwa semua penelepon JRE non-primer ini mengonfigurasinya dengan benar agar tetap berada dalam batas wadah, dengan mempertimbangkan jumlah variabel memori yang digunakan oleh runtime utama? Selain itu, bagaimana kami memastikan bahwa pengguna menyadari bahwa JVM membutuhkan _ratusan_ megabita memori untuk berjalan dengan aman.

Secara umum, mengingat struktur Diego hari ini, saya cukup skeptis bahwa dua proses dapat dijalankan dengan aman di dalam wadah tanpa melebihi batas memori wadah itu. Kami telah melakukan banyak pekerjaan untuk memastikan bahwa JVM tidak akan pernah melebihi batas memori wadahnya, tetapi semua itu tidak valid jika ada proses lain di dalam wadah yang menghabiskan memori. Kami tahu dari umpan balik pelanggan bahwa bahkan dengan kemampuan CF dengan cepat memulai ulang instans daur ulang, restart yang tidak terduga adalah keluhan besar dan tidak dapat diterima dalam banyak skenario produksi.

Untuk lebih jelasnya, saya benar-benar memahami kasus penggunaan di sini, saya hanya tidak yakin bagaimana kami dapat dengan aman mengirimkan sesuatu yang tidak membuka kemungkinan kuat daur ulang wadah pada penggunaan.

/bin/detect hanya diterapkan dalam kasus single-buildpack.

Bisakah kita meminta /bin/supply menyediakan JRE + deps, dan menyerahkannya ke aplikasi (mungkin non-Java) untuk menggunakan dependensi yang disediakan dengan benar dalam wadah (dengan proses sespan yang persisten secara eksplisit tidak didukung hingga fitur platform membuat sespan menjadi lebih baik pengalaman)?

/bin/detect hanya digunakan dalam kasus buildpack tunggal, tetapi ada hubungan yang melekat antara itu dan /bin/compile . Menurut cara berpikir saya (dan implementasi kami), /bin/compile hanya berjalan dalam situasi yang sama di mana /bin/detect akan cocok; kami benar-benar menggunakan logika yang sama untuk menentukan komponen apa yang akan menyala untuk ketiga fase. Anggap saja sebagai pemeriksaan ulang ketika Anda menentukan Java Buildpack secara tidak sengaja dengan aplikasi Go.

Seperti yang ada sekarang, saya tidak nyaman dengan kontrak di mana buildpack akan secara eksplisit _not_ cocok dengan /bin/detect , tetapi masih akan mencoba memodifikasi tetesan selama /bin/compile . Itu sepertinya cara yang pasti untuk memotong-motong aplikasi non-Java.

Jika Java buildpack dijalankan sebagai buildpack non-final, hanya /bin/supply akan dijalankan. /bin/supply tidak diizinkan untuk menulis ke direktori aplikasi (hanya direktori kotak pasir khusus di <dep>/<idx> ), jadi seharusnya tidak merusak aplikasi pengguna.

Tetapi jika /bin/compile diimplementasikan sebagai delegasi ke /bin/supply dan /bin/finalize , pemisahan itu tidak ada. Itu sepertinya langkah mundur untuk mendukung kontrak sebelumnya.

Bagaimana jika /bin/supply hanya menyediakan JRE atau JDK, dan proses selanjutnya terjadi di /bin/finalize ? Saya setuju bahwa hal lain selain itu (mis. menginstal dependensi khusus aplikasi) akan sulit untuk didukung mengingat JBP bekerja pada JAR yang meledak, dan aplikasi non-JAR akan sulit untuk dianalisis.

@dgodd membuat buildpack yang hanya memasok JDK untuk tujuan ini.

Saya tidak akrab dengan semua internal dari java buildpack, tetapi setelah mengikuti percakapan saya memahaminya jauh lebih rumit daripada yang saya bayangkan.
Dari apa yang saya pahami, pengaturan jre semacam ini (+ mungkin deps dari maven gradel apa pun) lebih mudah dan lebih baik dilakukan dalam buildpack terpisah (& lagi, sayangnya semua yang sudah ada memiliki versi hardcoded ...).

untuk @nebhale kekhawatiran tentang manajemen memori: 2 sen saya tentang ini adalah bahwa kasus multibuildpack semacam ini adalah yang canggih, jelas tidak umum, dan siapa pun yang harus menjalankan kasing semacam ini harus mempertimbangkan implikasi memori sendiri dan merencanakannya dengan tepat!

tempat saya bekerja, kami memiliki waktu luang 10%, jadi saya berharap mendapat kesempatan untuk menulis dan berkontribusi buildpack seperti itu untuk menginstal java env (dengan konfigurasi versi dan banyak lagi ...).

lanjutkan dan tutup masalah jika Anda mau.

Saya tahu ini ditutup, tetapi memberi +1 untuk cara memasukkan jre untuk aplikasi non-Java (aplikasi yang terkadang meluncurkan Java untuk menjalankan toples).

Akan lebih baik, jika ini mungkin karena dengan java buildpack sebagai non-final dan misalnya binary-buildpack sebagai buildpack terakhir, saya dapat mengonfigurasi jre dan menjalankan skrip yang bergantung pada jre.

+1 lainnya - ingin "menjalankan tugas" dengan JRE meskipun buildpack utama bukan Java. Misalnya menggunakan jalur terbang untuk memigrasikan perubahan basis data untuk aplikasi Node.

Hai @nebhale
kami memiliki persyaratan di mana kami dapat mengambil java-buildpack upstream secara langsung dan memiliki satu buildpack khusus yang dapat mengonfigurasi perubahan (seperti tautan sumber daya s3 dan penyesuaian appdynamics dll). Jadi di sini ketika kita push, buildpack pertama harus java buildpack karena kita memiliki semua kustomisasi yang harus buildpack final. Saya tahu itu perlu bin/pasokan jika itu non final. apakah ada cara untuk melakukan pengaturan semacam ini?