Java-buildpack: Fehler bei der Verwendung von Azul Zulu JDK in PCF-Microservices

Der Speicherort, auf den Sie das Buildpack verweisen, dh repository_root , muss ein gültiges Repository sein. Es gibt kein index.yml (zumindest als ich gerade nachgesehen habe) an diesem Ort.

Siehe https://github.com/cloudfoundry/java-buildpack/blob/main/docs/extending-repositories.md.

Hmm, es sieht so aus, als hätte es an diesem Ort früher ein index.yml , aber ich sehe es nicht mehr. Lassen Sie mich herumfragen und sehen, was ich finden kann.

Wenn Sie in der Zwischenzeit Ihr eigenes index.yml erstellen, hosten Sie es irgendwo (egal) und zeigen Sie auf die Dateien an diesem Ort (dh https://cdn.azul.com/zulu/bin/zulu9 .0.7.1-jdk9.0.7-linux_x64.tar.gz), können Sie dies umgehen.

Wir haben die folgenden Variablen in manifest.yml der Anwendung verwendet-
JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: " https://example.com :8443/nexus/repository/SRET/com/example/sret/AppD_zulu11.48.21-ca-jdk/11.0.11-linux_x64/AppD_zulu11.48.21- ca-jdk-11.0.11-linux_x64.gz"}, {version: 11.0.+}]'
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

OK, das muss etwas anders sein. Das repository_root zeigt auf den Ordner, in dem sich Ihr index.yml befindet. Die URL, die das JBP zum Herunterladen der index.yml verwendet, lautet also repository_root/index.yml .

Die JBP liest dann index.yml, wählt die neueste Version aus, die dem von Ihnen angegebenen Versionsfilter entspricht, und lädt die Ressource herunter, auf die von index.yml für diese Version verwiesen wird.

Hallo Dmikusa,

Bedeutet das also, dass sich sowohl das Zulu-JDK als auch die index.yml am selben Speicherort befinden sollten?

Ok, ich verstehe, was Sie sagen, die JBP_CONFIG_ZULU_JRE sollte eingerichtet werden als

JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "insert-full-URL-to-index-yml-on-an-other-server"}, {version: 11.0.+}]'

Es muss die vollständige URL zu dem Ordner/Verzeichnis sein, in dem sich die index.yml befindet. Das Buildpack fügt /index.yml , wenn es die URL zum Herunterladen der Datei index.yml generiert. Ihr repository_root sollte also nicht mit /index.yml enden.

Es scheint, dass es die JVM aus diesem Pfad wählt https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gz. Wo ist das konfiguriert?

@ajay-dbs - Dies ist wahrscheinlich der Grund:

[ConfigurationUtils] WARN Benutzerkonfigurationswert für 'jres' ist ungültig, vorhandene Eigenschaft nicht vorhanden

Es ignoriert einen Teil Ihrer Konfiguration. Ihr JBP_CONFIG_COMPONENTS sieht für mich in Ordnung aus, aber Sie sollten sich genauer ansehen, was dort vor sich geht. Es wendet diesen Teil der Konfiguration nicht an, also wählt es nicht Ihr gewünschtes JDK aus.

Liegt es an einem fehlenden ":" zwischen JBP_CONFIG_COMPONENTS und dem Wert?

Sollte es JBP_CONFIG_COMPONENTS sein: '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

Es hängt davon ab, wie Sie die env-Variablen festlegen. Wenn Sie sie im Manifest festlegen, sollte ein : dazwischen stehen. Wenn Sie sie mit cf set-env festlegen, ist es nur name val .

Hallo Team,

Das Anwendungsteam hat diese Variable in der Datei manifest.yml verwendet.
JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: " https://example.com :8051/pcf"}, {version: 11.0.+}]'
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

@ajay-dbs Da Sie die env-Variablen in einer manifest.yml hinzufügen, scheint der fehlende Doppelpunkt möglicherweise das Problem zu sein. Bitte beheben Sie es als

JBP_CONFIG_COMPONENTS: '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

[Buildpack] FEHLER Finalisieren fehlgeschlagen mit Ausnahme #https://cdn.azul.com/zulu/bin/index.yml>
Zulu JRE-Fehler: Die zwischengespeicherte Datei für https://cdn.azul.com/zulu/bin/index.yml kann nicht gefunden werden

Übrigens, der Link zu https://cdn.azul.com/zulu/bin/index.yml wurde jetzt wiederhergestellt.

[ERR] [ConfigurationUtils] WARN Benutzerkonfigurationswert für 'Version' ist ungültig, vorhandene Eigenschaft nicht vorhanden

Ist ein anderer aber ähnlicher Fehler. Es scheint jetzt jres zu akzeptieren, was gut ist. Sie können sehen, dass jetzt auch der Zulu-Container ausgeführt wird.

In diesem Fall mag es jetzt nicht den Teil, in dem Sie versuchen, die Version auf 11.0.+ zu setzen. Was du da hast, stimmt nicht ganz.

JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: " https://example.com :8051/pcf"}, {version: 11.0.+}]'

sollte sein

JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "https://example.com:8051/pcf", version: 11.0.+}]'

Die version und repository_root befinden sich im selben jre Objekt. Im Zweifelsfall können Sie sich jederzeit die zugehörige config/ Datei ansehen. Die JBP_CONFIG_* Konfiguration, die Sie hinzufügen, muss dem Format der Konfigurationsdatei entsprechen, da sie über die Konfiguration gelegt wird.

Siehe die Struktur für Zulu: https://github.com/cloudfoundry/java-buildpack/blob/main/config/zulu_jre.yml#L22 -L24

021-06-14T13:14:15.960+05:30 [STG/0] [ERR] [Buildpack] FEHLER Erkennung fehlgeschlagen mit Ausnahme #

Ich erinnere mich, dass ich in der Vergangenheit so etwas gesehen habe, wenn der Cache mit der App durcheinander gebracht wurde. Versuchen Sie, Ihre App unter einem neuen Namen wie "my-cool-app-2" oder etwas Einzigartigem und Neuem zu veröffentlichen. Wenn das Problem dadurch behoben wird, müssen Sie entweder Ihre App löschen und erneut per Push übertragen oder Ihren Administrator bitten, den Blobstore-Cache des Buildpacks zu leeren.

https://apidocs.cloudfoundry.org/16.13.0/blobstores/delete_all_blobs_in_the_buildpack_cache_blobstore.html

Beachten Sie, dass letzteres den Cache für alle Buildpacks löscht. Dies ist zwar nicht destruktiv, zwingt jedoch alle Buildpacks, alle Ressourcen erneut herunterzuladen, wenn eine Anwendung das nächste Mal bereitgestellt wird.

Wir haben versucht, den Cache zu leeren und auch versucht, eine App mit einem völlig neuen Namen sowie einer neuen Route bereitzustellen. Immer noch das gleiche Problem.

Dies wird normalerweise diese Art von Problem beheben, daher ist es gut zu wissen, dass es hier nicht hilft. Es bedeutet wahrscheinlich, dass etwas anderes passiert.

WARNING: buildpack script '/bin/detect' is not executable
[Buildpack] ERROR Detect failed with exception #<RuntimeError: Zulu JRE error: Unable to find cached file for https://zulu-index-file.dev.apps.example.com/index.yml>
Zulu JRE error: Unable to find cached file for https://zulu-index-file.dev.apps.example.com/index.yml
stat /tmp/buildpacks/674495fe521621eeb364a353eb511ee3/bin/detect: no such file or directory

Was mich neben dem Caching-Fehler beunruhigt, ist die WARNUNG zu /bin/detect und die `stat: no such file or directory error. Das sollte passieren und würde mit den Buildpacks, die wir mit Releases verpacken, nicht passieren.

Woher bekommst du dein Buildpack? Laden Sie es von der Releases-Seite herunter und laden Sie es auf CF hoch? Verwenden Sie eine URL zur Github-Seite? Wenn ja, wie lautet die genaue URL? Bekommst du das Buildpack woanders her? Verpacken Sie Ihr eigenes Buildpack? Wenn ja, versuchen Sie bitte, das von der Releases-Seite oder ein anderes bekanntes funktionierendes Buildpack als Basistest zu verwenden, um zu sehen, ob das wie erwartet funktioniert, und geben Sie bitte auch an, wie Sie das Buildpack packen. Alle zusätzlichen Details, die Sie angeben können, können helfen, das Problem zu erkennen oder das Problem zu reproduzieren.

Bitte weiterhin als neuen App-Namen pushen, während Sie weiter testen, da wir sicherstellen möchten, dass wir Caching-Probleme ausschließen.

Vielen Dank

Noch ein paar Fragen... Hat das vorher funktioniert und ist vor kurzem kaputt gegangen? Wenn ja, was hat sich in letzter Zeit geändert? Haben Sie Buildpack-Versionen aktualisiert? Haben Sie Dateien auf Ihrem Server geändert, auf dem Zulu gehostet wird? Gab es neue Zulu-Updates auf Ihrem Server? Wenn es noch nie funktioniert hat oder Sie es zum ersten Mal versuchen, teilen Sie uns dies ebenfalls mit.

Vielen Dank

@mells82 Ich denke, der Inhalt von index.yml sollte sein

---
1.8.0_212: https://cdn.azul.com/zulu/bin/zulu8.38.0.13-ca-jre8.0.212-linux_x64.tar.gz
1.8.0_222: https://cdn.azul.com/zulu/bin/zulu8.40.0.25-ca-jre8.0.222-linux_x64.tar.gz
1.8.0_232: https://cdn.azul.com/zulu/bin/zulu8.42.0.23-ca-jre8.0.232-linux_x64.tar.gz
1.8.0_242: https://cdn.azul.com/zulu/bin/zulu8.44.0.11-ca-jre8.0.242-linux_x64.tar.gz
1.8.0_252: https://cdn.azul.com/zulu/bin/zulu8.46.0.19-ca-jre8.0.252-linux_x64.tar.gz
1.8.0_265: https://cdn.azul.com/zulu/bin/zulu8.48.0.53-ca-jre8.0.265-linux_x64.tar.gz
1.8.0_275: https://cdn.azul.com/zulu/bin/zulu8.50.0.51-ca-jre8.0.275-linux_x64.tar.gz
1.8.0_282: https://cdn.azul.com/zulu/bin/zulu8.52.0.23-ca-jre8.0.282-linux_x64.tar.gz
1.8.0_292: https://cdn.azul.com/zulu/bin/zulu8.54.0.21-ca-jre8.0.292-linux_x64.tar.gz
11.0.3: https://cdn.azul.com/zulu/bin/zulu11.31.11-ca-jre11.0.3-linux_x64.tar.gz
11.0.4: https://cdn.azul.com/zulu/bin/zulu11.33.15-ca-jre11.0.4-linux_x64.tar.gz
11.0.5: https://cdn.azul.com/zulu/bin/zulu11.35.15-ca-jre11.0.5-linux_x64.tar.gz
11.0.6: https://cdn.azul.com/zulu/bin/zulu11.37.17-ca-jre11.0.6-linux_x64.tar.gz
11.0.7: https://cdn.azul.com/zulu/bin/zulu11.39.15-ca-jre11.0.7-linux_x64.tar.gz
11.0.8: https://cdn.azul.com/zulu/bin/zulu11.41.23-ca-jre11.0.8-linux_x64.tar.gz
11.0.9: https://cdn.azul.com/zulu/bin/zulu11.43.55-ca-jre11.0.9.1-linux_x64.tar.gz
11.0.10: https://cdn.azul.com/zulu/bin/zulu11.45.27-ca-jre11.0.10-linux_x64.tar.gz
11.0.11: https://cdn.azul.com/zulu/bin/zulu11.48.21-ca-jre11.0.11-linux_x64.tar.gz

Entfernen des https-Erstellungsproblems, bei dem das Buildpack die jre nicht herunterladen würde.

Wir haben das Java-Offline-Buildpack von pivortal heruntergeladen und im PCF-Repository aufbewahrt und verwenden dann das Buildpack aus dem PCF-Repository.
Dies ist das erste Mal, dass wir versuchen, eine App mit Azul Zulu JDK auszuführen. Standardmäßig wird Oracle JDK mit Bellsoft VM verwendet und diese Bellsoft VM unterstützt kein Objektinstanz-Tracking. Wir versuchen also, Azul Zulu JDK zu verwenden.

Okay, danke für diese Info. Die Dinge machen jetzt mehr Sinn.

Die Art und Weise, wie das Tanzu-Buildpack verpackt ist, erfolgt im "Offline"-Modus. Sehen Sie hier, wir führen dieses Skript aus, um es zu verpacken .

Im "Offline"-Modus erhalten Sie nur das, was im Paket enthalten ist. Das JBP kann andere Dinge nicht herunterladen.

Aus den Dokumenten für "offline":

Es packt die neueste Version jeder Abhängigkeit (wie im config/-Verzeichnis konfiguriert) und deaktiviert remote_downloads.

https://github.com/cloudfoundry/java-buildpack/#offline-Paket

Dies geschieht, weil es in einer Offline-Umgebung ohne Internetzugang ausgeführt werden soll.

Ich habe es in einem Labor mit einem Offline-JBP versucht und erhalte genau den gleichen Fehler wie Sie:

   2021-06-17T15:21:56.72-0400 [STG/0] ERR [Buildpack]                      ERROR Finalize failed with exception #<RuntimeError: Zulu JRE error: Unable to find cached file for https://cdn.azul.com/zulu/bin/index.yml>
   2021-06-17T15:21:56.72-0400 [STG/0] ERR Zulu JRE error: Unable to find cached file for https://cdn.azul.com/zulu/bin/index.yml
   2021-06-17T15:21:56.72-0400 [STG/0] ERR Failed to compile droplet: Failed to run finalize script: exit status 1

Dies liegt daran, dass diese Datei nicht im Offline-Cache vorhanden ist und im Offline-Modus nur im Cache gesucht wird.

Wenn Sie Azul Zulu in einem Offline-Buildpack verwenden möchten, müssen Sie das Buildpack selbst mit Zulu darin verpacken. Andernfalls müssen Sie eine Online-Version des Buildpacks verwenden. Informationen zum Verpacken des Buildpacks finden Sie hier und stellen Sie sicher, dass Sie die components.yml vor dem Verpacken anpassen. Sie möchten, dass diese Datei Zulu anzeigt.

Die Verwendung des Online-Buildpacks funktioniert, aber wie @RageZBla sagte, muss das index.yml korrekt formatiert werden. Im Moment ist die index.yml unter https://cdn.azul.com/zulu/bin/index.yml nicht richtig formatiert. Es fehlt das Protokoll, was zu Problemen führt. Stellen Sie sicher, dass Ihr index.yml wie das Beispiel im Kommentar von @RageZBla strukturiert ist.

danke für den Bericht, index.yml wurde aktualisiert: https://cdn.azul.com/zulu/bin/index.yml

@ajay-dbs Wenn Sie sich in einer Offline-Umgebung befinden, müssen Sie das Buildpack selbst packen. Damit dies von einer anderen Person für Sie erledigt wird, ist aufgrund der Anforderungen für die Weiterverteilung von Software eine rechtliche Genehmigung erforderlich. Ganz zu schweigen von den Sicherheitsaspekten bei der Verteilung vertrauenswürdiger Software. Der einfachste Weg ist, das Buildpack selbst zu verpacken.

Der Vorgang ist hier dokumentiert . Sie müssen das Paket von einem Computer mit Internetzugang aus installieren, da die Abhängigkeiten heruntergeladen werden müssen. Dies sind jedoch nur ein paar Befehle und sollten bei einer relativ schnellen Internetverbindung nicht länger als ein paar Minuten dauern.