Java-buildpack: Mendukung (atau mendokumentasikan cara menggabungkan/menggunakan) Agen Java kustom

Tidak ada yang dibangun ke dalam buildpack yang memperlakukan ini sebagai konsep kelas satu. Di sisi lain, melakukan cf set-env <APP> JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf' akan berhasil tanpa dukungan khusus apa pun dari buildpack.

Merupakan ide yang menarik untuk mengarahkan dukungan untuk ini, tetapi apa yang ada dalam pikiran Anda untuk mengidentifikasi agen dan konfigurasi yang _tidak_ menyetel semacam variabel lingkungan?

Untuk menggunakan agen java kustom, Anda dapat mempertahankan repo agen internal Anda sendiri dan mengarahkan ke agen java kustom itu.
Dalam file manifest.yml Anda dapat mengarahkan ke repo internal Anda seperti di bawah ini.

env:
  JBP_CONFIG_APP_DYNAMICS_AGENT: '{version: "4.2.15_6", repository_root: "http://youdomain:8082/AppDAgentRepo"}'

@vijayantony Tapi itu hanya untuk agen yang sudah kami dukung. Pertanyaan ini lebih tentang dukungan untuk agen non-publik apa pun tanpa forking dan menambahkan komponen baru untuk mendukungnya.

@nebhale ya persis seperti yang dikatakan @vijayantony

@CAFXX Saya khawatir saya tidak mengikuti. Anda hanya ingin versi alternatif dari agen yang sudah kami dukung, atau Anda ingin mekanisme "agen" generik?

@nebhale yang terakhir. Beberapa pengguna kami memiliki agen java non-publik yang ingin mereka gunakan dengan java buildpack, tetapi tanpa menggunakan forking (dan pemeliharaan fork) buildpack.

Sekedar memperjelas, dalam komentar saya sebelumnya, saya mengacu pada bagian komentar @vijayantony ini:

Pertanyaan ini lebih tentang dukungan untuk agen non-publik apa pun tanpa forking dan menambahkan komponen baru untuk mendukungnya.

Saya menulis itu , bukan @vijayantony. Senang melihat kita berada di halaman yang sama.

Itulah yang saya dapatkan karena mengomentari hal pertama setelah bangun tidur. ️ Maaf.

@nebhale ada pemikiran tentang ini? Apakah penjelasan saya tentang use case sudah cukup?

Maaf, ini telah jatuh dari radar saya. Saya pikir pertanyaan luar biasa yang saya miliki adalah

tetapi apa yang ada dalam pikiran Anda untuk mengidentifikasi agen dan konfigurasi yang tidak mengatur semacam variabel lingkungan?

Saran Anda

Idealnya, sebagai pengguna, saya ingin dapat mengatakan: Saya telah menggabungkan path/to/my_agent.jar di application.jar saya, menambahkannya ke JVM saat memulai dan (opsional) juga mengatur sesuatu seperti berikut terkait JAVA_OPTS: -Dmyagent.config_file=path/to/my_agent.conf , di mana path/to/myagent.conf berisi konfigurasi yang akan digunakan oleh agen.

sudah dapat dicapai dengan cf set-env <APP> JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf' . Jika rencananya adalah untuk mengemas agen dan konfigurasi dalam setiap aplikasi, ini tampaknya sama bagusnya dengan sesuatu di mana Anda akan mengatakan cf set-env <APP> JBP_CONFIG_AGENT "{path: 'path/to/my_agent.jar', java_opts: '-Dmyagent.config_file=app/META-INF/my_agent.conf'}"

Pikiran tentang pro dan kontra dari apa yang tersedia saat ini versus apa yang Anda lebih suka lakukan?

sudah dapat dicapai dengan cf set-env <APP> JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf'

Hebat, jika demikian maka kita baik-baik saja. Dalam hal ini kita dalam kasus 2 dari posting asli saya:

Jika saya melewatkannya dan ini sudah didukung, maka saya pikir akan sangat membantu jika dokumen buildpack atau tips java menyertakan contoh bagaimana melakukan ini.

Beberapa pertanyaan:

• Apakah ini cara yang didukung secara resmi untuk menyuntikkan agen yang disediakan pengguna? (Saya kira ini akan berarti sesuatu di sepanjang baris "apakah itu dicakup oleh tes penerimaan?")
• Dengan asumsi jawaban untuk pertanyaan sebelumnya adalah ya, dapatkah kita menambahkan ini ke dokumen sehingga pengguna tidak ragu tentang cara melakukan ini?

Saya akan menganggap ini didukung secara resmi karena saya secara teratur merekomendasikannya. Ini sebenarnya kasus yang lebih umum yang mencakup hal-hal seperti "bagaimana cara saya menyertakan KeyStore pribadi dalam aplikasi saya" juga. Pola "menempel barang di META-INF sehingga tidak dapat terekspos secara tidak sengaja, dan kemudian merujuknya dengan JAVA_OPTS ” diuji sebagai kasus umum dan saya akan menambahkan beberapa dokumentasi tentang strategi .

Apakah Anda memiliki rekomendasi di mana dalam dokumentasi yang Anda harapkan untuk menemukan ini?

Saya akan menambahkannya ke bagian kerangka kerja standar README (sudah berisi bagian tentang opsi Java dan tentang semua agen bawaan) dan idealnya di suatu tempat di https://docs.cloudfoundry.org/buildpacks/java/java-tips. html (misalnya contoh di https://docs.cloudfoundry.org/buildpacks/java/java-tips.html#extension tampaknya menyiratkan bahwa "cara" menggunakan agen adalah dengan forking/extending)