Java-buildpack: Obtenir une erreur lors de l'utilisation du JDK Azul Zulu dans les microservices PCF

L'emplacement vers lequel vous pointez le buildpack, c'est- repository_root dire index.yml (du moins quand j'ai regardé tout à l'heure) à cet endroit.

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

Hmm, on dirait qu'il y avait un index.yml à cet endroit, mais je ne le vois plus. Laissez-moi demander autour de vous et voir ce que je peux trouver.

En attendant, si vous créez votre propre index.yml , hébergez-le quelque part (peu importe) et pointez sur les fichiers à cet emplacement (c'est-à-dire https://cdn.azul.com/zulu/bin/zulu9 .0.7.1-jdk9.0.7-linux_x64.tar.gz), vous pouvez contourner ce problème.

Nous avons utilisé les variables ci-dessous dans manifest.yml d'application-
JBP_CONFIG_ZULU_JRE : '[jre : {repository_root : " https://example.com :8443/nexus/repository/SRET/com/example/sret/AppD_zulu11.48.21-ca-jdk/11.01.1-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, cela doit être légèrement différent. Le repository_root pointe vers le dossier où se trouve votre index.yml . Ainsi, l'URL que le JBP utilise pour télécharger le fichier index.yml est repository_root/index.yml .

Le JBP lira ensuite index.yml, choisira la dernière version correspondant au filtre de version que vous spécifiez et téléchargera la ressource référencée à partir d'index.yml pour cette version.

Salut Dmikusa,

Cela signifie-t-il que le JDK Zulu ainsi que le fichier index.yml doivent se trouver au même endroit ?

Ok, je vois ce que vous dites, le JBP_CONFIG_ZULU_JRE devrait être configuré comme

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

Il doit s'agir de l'URL complète du dossier/répertoire où réside le fichier index.yml. Le pack de construction y ajoutera /index.yml lorsqu'il générera l'URL pour télécharger le fichier index.yml. Ainsi, votre repository_root ne doit /index.yml .

Il semble qu'il sélectionne la JVM à partir de ce chemin https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gz. Où est-ce configuré ?

@ajay-dbs - C'est probablement la raison :

[ConfigurationUtils] WARN La valeur de configuration de l'utilisateur pour 'jres' n'est pas valide, la propriété existante n'est pas présente

C'est ignorer une partie de votre configuration. Votre JBP_CONFIG_COMPONENTS me semble OK, mais vous allez vouloir regarder de plus près ce qui se passe là-bas. Il n'applique pas cette partie de la configuration, il ne sélectionne donc pas le JDK souhaité.

Est-ce à cause d'un ":" manquant entre JBP_CONFIG_COMPONENTS et la valeur ?

S'il s'agit de JBP_CONFIG_COMPONENTS : '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

Cela dépend de la façon dont vous définissez les variables d'environnement. Si vous les définissez dans le manifeste, il devrait y avoir un : entre eux. Si vous les définissez avec cf set-env alors c'est juste name val .

Bonjour l'équipe,

L'équipe d'application a utilisé cette variable dans le fichier manifest.yml.
JBP_CONFIG_ZULU_JRE : '[jre : {repository_root : " https://example.com :8051/pcf"}, {version : 11.0.+}]'
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

@ajay-dbs puisque vous ajoutez les variables env dans un manifest.yml , il semble que les deux points manquants soient peut-être le problème. Veuillez le corriger comme

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

[Buildpack] ERREUR La finalisation a échoué avec l'exception #https://cdn.azul.com/zulu/bin/index.yml>
Erreur Zulu JRE : impossible de trouver le fichier mis en cache pour https://cdn.azul.com/zulu/bin/index.yml

BTW, le lien vers https://cdn.azul.com/zulu/bin/index.yml a été restauré maintenant.

[ERR] [ConfigurationUtils] WARN La valeur de configuration de l'utilisateur pour 'version' n'est pas valide, la propriété existante n'est pas présente

Est une erreur différente mais similaire. Il semble maintenant accepter jres ce qui est bien. Vous pouvez voir qu'il exécute également le conteneur Zulu maintenant.

Dans ce cas, il n'aime plus la partie où vous essayez de définir la version sur 11.0.+. Ce que vous avez là n'est pas tout à fait exact.

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

devrait être

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

Les version et repository_root sont sur le même objet jre . En cas de doute, vous pouvez toujours consulter le fichier config/ associé. La configuration JBP_CONFIG_* vous ajoutez doit correspondre au format du fichier de configuration, car il se superpose à la configuration.

Voir la structure pour le zoulou : 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] ERROR La détection a échoué avec l'exception #

Je me souviens avoir vu quelque chose comme ça dans le passé si le cache était gâché avec l'application. Essayez de pousser votre application sous un nouveau nom comme "my-cool-app-2" ou quelque chose d'unique et nouveau. Si cela résout le problème, vous devrez soit supprimer et relancer votre application, soit demander à votre administrateur d'effacer le cache du blobstore des buildpacks.

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

Notez que ce dernier effacera le cache pour tous les buildpacks. Bien que cela ne soit pas destructeur, cela forcera tous les buildpacks à retélécharger toutes les ressources la prochaine fois qu'une application est mise en scène.

Nous avons essayé de vider le cache et également essayé de déployer une application avec un nom et un itinéraire complètement nouveaux. Toujours le même problème.

Cela résoudra normalement ce type de problème, il est donc bon de savoir que cela n'aide pas ici. Cela signifie probablement qu'il se passe quelque chose de différent.

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

Ce qui m'inquiète, en plus de l'erreur de mise en cache, c'est l'AVERTISSEMENT à propos de /bin/detect et le `stat: no such file or directory error. Cela devrait arriver, et ne se produirait pas avec les buildpacks que nous empaquetons avec les versions.

Où obtenez-vous votre buildpack? Le téléchargez-vous à partir de la page Releases et le téléchargez-vous sur CF ? Utilisez-vous une URL vers la page github ? Si oui, quelle est l'URL exacte ? Obtenez-vous le buildpack d'ailleurs? Emballez-vous votre propre buildpack ? Si c'est le cas, essayez d'utiliser celui de la page Releases ou un autre buildpack fonctionnel connu comme test de base pour voir si cela fonctionne comme prévu, et veuillez également indiquer comment vous emballez le buildpack ? Tous les détails supplémentaires que vous pouvez fournir peuvent aider à repérer le problème ou à le reproduire.

Veuillez continuer à pousser en tant que nouveau nom d'application pendant que vous continuez à tester, car nous voulons nous assurer que nous éliminons les problèmes de mise en cache.

Merci

Encore quelques questions... Cela fonctionnait-il auparavant et s'est-il cassé récemment ? Si oui, qu'est-ce qui a changé récemment ? Avez-vous mis à niveau les versions du pack de construction ? Avez-vous modifié des fichiers sur votre serveur hébergeant Zulu ? De nouvelles mises à jour de Zulu ont-elles été mises sur votre serveur ? Si cela n'a jamais fonctionné ou si c'est la première fois que vous l'essayez, faites-le nous savoir également.

Merci

@mells82 Je pense que le contenu de index.yml devrait être

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

suppression du problème de création https où le buildpack ne téléchargeait pas le fichier jre.

Nous avons téléchargé le pack de construction Java hors ligne à partir de pivortal et conservé dans le référentiel PCF, puis utilisé le pack de construction à partir du référentiel PCF.
C'est la première fois que nous essayons d'exécuter l'application avec Azul Zulu JDK. Par défaut, Oracle JDK est utilisé avec Bellsoft VM et cette VM Bellsoft ne prend pas en charge le suivi des instances d'objets. Nous essayons donc d'utiliser Azul Zulu JDK.

D'accord, merci pour ces infos. Les choses prennent plus de sens maintenant.

La façon dont le pack de construction Tanzu est emballé, cela se fait en mode "hors ligne". Voir ici, nous exécutons ce script pour le packager .

En mode « hors ligne », vous n'obtenez que ce qui est emballé dans le paquet. Le JBP ne peut pas télécharger d'autres choses.

D'après la doc pour "hors ligne":

Il conditionne la dernière version de chaque dépendance (telle que configurée dans le répertoire config/) et désactive remote_downloads.

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

Il le fait parce qu'il est censé fonctionner dans un environnement hors ligne sans accès à Internet.

J'ai essayé dans un laboratoire avec un JBP hors ligne et j'obtiens exactement la même erreur que vous :

   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

C'est parce que ce fichier n'existe pas dans le cache hors ligne et en mode hors ligne, il ne cherchera que dans le cache.

Si vous souhaitez utiliser Azul Zulu dans un pack de construction hors ligne, vous devez emballer le pack de construction vous-même avec Zulu dedans. Sinon, vous devez utiliser une version en ligne du buildpack. Pour empaqueter le buildpack, voir ici et assurez-vous d'ajuster le component.yml avant l'empaquetage. Vous voulez que ce fichier indique Zulu.

L'utilisation du pack de construction en ligne fonctionne, mais comme l' a dit index.yml doit être formaté correctement. Pour le moment, le fichier index.yml sur https://cdn.azul.com/zulu/bin/index.yml n'est pas formaté correctement. Il manque le protocole, ce qui cause des problèmes. Assurez-vous que votre index.yml est structuré comme l'exemple dans le commentaire de @RageZBla .

merci pour le rapport, index.yml a été mis à jour : https://cdn.azul.com/zulu/bin/index.yml

@ajay-dbs Si vous êtes dans un environnement hors ligne, vous devez empaqueter le buildpack vous-même. Pour que quelqu'un d'autre le fasse pour vous, cela nécessite une autorisation légale en raison des exigences de redistribution des logiciels. Sans parler des aspects de sécurité de la distribution de logiciels de confiance. Le moyen le plus simple est d'empaqueter le buildpack vous-même.

Le processus est documenté ici . Vous devez effectuer le package à partir d'un ordinateur qui a accès à Internet car il doit télécharger les dépendances, cependant, il ne s'agit que de quelques commandes et ne devrait pas prendre plus de quelques minutes avec une connexion Internet raisonnablement rapide.