Java-buildpack: Unterstützung (oder Dokumentation der Bündelung/Verwendung) benutzerdefinierter Java-Agenten

Es ist nichts in das Buildpack eingebaut, was dies als erstklassiges Konzept behandelt. Andererseits würde ein cf set-env <APP> JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf' ohne besondere Unterstützung durch das Buildpack funktionieren.

Es ist eine interessante Idee, den Support dafür zu lenken, aber was hatten Sie im Sinn, um Agenten und Konfigurationen zu identifizieren, die _keine_ Umgebungsvariablen setzen?

Um einen benutzerdefinierten Java-Agenten zu verwenden, können Sie Ihr eigenes internes Agent-Repository verwalten und auf diesen benutzerdefinierten Java-Agenten verweisen.
In der Datei manifest.yml können Sie wie unten auf Ihr internes Repo verweisen.

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

@vijayantony Aber das gilt nur für Agenten, die wir bereits unterstützen. Bei dieser Frage geht es mehr um die Unterstützung für jeden nicht öffentlichen Agenten, ohne zu forken und eine neue Komponente hinzuzufügen, um ihn zu unterstützen.

@nebhale ja, es ist genau so, wie @vijayantony sagt

@CAFxX Ich fürchte, ich folge nicht. Sie möchten nur alternative Versionen von Agenten, die wir bereits unterstützen, oder möchten einen generischen „Agent“-Mechanismus?

@nebhale letzteres. Einige unserer Benutzer haben nicht-öffentliche Java-Agenten, die sie mit dem Java-Buildpack verwenden möchten, ohne jedoch auf das Forken (und die Wartung des Forks) des Buildpacks zurückzugreifen.

Nur zur Verdeutlichung, in meinem vorherigen Kommentar bezog ich mich auf diesen Teil von @vijayantonys Kommentar:

Bei dieser Frage geht es mehr um die Unterstützung für jeden nicht öffentlichen Agenten, ohne zu forken und eine neue Komponente hinzuzufügen, um ihn zu unterstützen.

Das habe ich geschrieben 😄, nicht @vijayantony. Gut zu sehen, dass wir auf derselben Seite stehen.

Das bekomme ich, wenn ich die ersten Dinge nach dem Aufwachen kommentiere. 🤦‍♂️ Entschuldigung.

@nebhale irgendwelche Gedanken dazu? War meine Erläuterung des Anwendungsfalls ausreichend?

Entschuldigung, das war von meinem Radar verschwunden. Ich denke, die ausstehende Frage, die ich habe, ist

Aber was hatten Sie im Sinn, um Agenten und Konfigurationen zu identifizieren, die keine Umgebungsvariablen setzen?

Ihr Vorschlag bzgl

Idealerweise möchte ich als Benutzer sagen können: Ich habe path/to/my_agent.jar in meinem application.jar gebündelt, füge es beim Start der JVM hinzu und setze (optional) auch so etwas wie folgendes verwandt JAVA_OPTS: -Dmyagent.config_file=path/to/my_agent.conf , wobei path/to/myagent.conf die Konfiguration enthält, die vom Agenten verwendet wird.

kann bereits mit cf set-env <APP> JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf' erreicht werden. Wenn der Plan darin besteht, Agenten und Konfiguration in jede Anwendung zu packen, scheint dies genauso gut zu sein wie etwas, bei dem Sie cf set-env <APP> JBP_CONFIG_AGENT "{path: 'path/to/my_agent.jar', java_opts: '-Dmyagent.config_file=app/META-INF/my_agent.conf'}" sagen würden

Gedanken zu den Vor- und Nachteilen dessen, was heute verfügbar ist, im Vergleich zu dem, was Sie lieber tun würden?

kann bereits mit cf set-env <APP> JAVA_OPTS '-javaagent:app/META-INF/myagent.jar -Dmyagent.config_file=app/META-INF/my_agent.conf' erreicht werden

Großartig, wenn ja, dann sind wir gut. In diesem Fall sind wir in Fall 2 meines ursprünglichen Beitrags:

Wenn ich es verpasst habe und dies bereits unterstützt wird, wäre es meiner Meinung nach hilfreich, wenn die Buildpack-Dokumentation oder die Java-Tipps ein Beispiel dafür enthalten würden.

Einige Fragen:

• Ist dies die offiziell unterstützte Art, einen vom Benutzer bereitgestellten Wirkstoff zu injizieren? (Ich denke, das würde so etwas wie "Ist es durch einen Abnahmetest abgedeckt?" bedeuten.)
• Angenommen, die Antwort auf die vorherige Frage lautet ja, können wir dies zu den Dokumenten hinzufügen, damit die Benutzer keine Zweifel haben, wie sie dies tun sollen?

Ich würde dies als offiziell unterstützt betrachten, da ich es regelmäßig empfehle. Es ist eigentlich ein allgemeinerer Fall, der auch Dinge wie „Wie füge ich ein privates KeyStore in meine Bewerbung ein?“ beinhaltet. Das Muster „Zeug in META-INF stecken, damit es nicht versehentlich offengelegt werden kann, und dann mit JAVA_OPTS darauf verweisen“ wird als allgemeiner Fall getestet, und ich werde einige Dokumentation über die Strategie hinzufügen .

Haben Sie eine Empfehlung, wo in der Dokumentation Sie dies erwarten würden?

Ich würde es dem Standard-Framework-Abschnitt der README hinzufügen (es enthält bereits einen Abschnitt über Java-Optionen und über alle integrierten Agenten) und idealerweise irgendwo in https://docs.cloudfoundry.org/buildpacks/java/java-tips. html (z. B. das Beispiel in https://docs.cloudfoundry.org/buildpacks/java/java-tips.html#extension scheint zu implizieren, dass "der Weg" zur Verwendung eines Agenten das Verzweigen/Erweitern ist)