Java-buildpack: Recibiendo un error al usar Azul Zulu JDK en microservicios PCF

La ubicación a la que apuntas el paquete de compilación, es decir, repository_root , debe ser un repositorio válido. No hay index.yml (al menos cuando miré hace un momento) en esa ubicación.

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

Mmm, parece que solía haber un index.yml en esa ubicación, pero ya no lo veo. Déjame preguntar y ver qué puedo encontrar.

Mientras tanto, si crea su propio index.yml , alójelo en algún lugar (no importa) y apunte a los archivos en esa ubicación (es decir, https://cdn.azul.com/zulu/bin/zulu9 .0.7.1-jdk9.0.7-linux_x64.tar.gz), puede solucionar este problema.

Hemos utilizado las siguientes variables en manifest.yml de 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.0.11-linux_x64 / AppD_zulu11.48.21 ca-jdk-11.0.11-linux_x64.gz "}, {versión: 11.0. +}] '
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack :: Jre :: ZuluJRE"]}'

Bien, esto debe ser un poco diferente. El repository_root apunta a la carpeta donde se encuentra su index.yml . Entonces, la URL que utiliza JBP para descargar index.yml es repository_root/index.yml .

El JBP leerá index.yml, seleccionará la última versión que coincida con el filtro de versión que especifique y descargará el recurso al que se hace referencia en index.yml para esa versión.

Hola Dmikusa,

Entonces, ¿eso significa que tanto el Zulu JDK como el index.yml deben estar en la misma ubicación?

Ok, veo lo que estás diciendo, el JBP_CONFIG_ZULU_JRE debería configurarse como

JBP_CONFIG_ZULU_JRE: '[jre: {raíz_de_repositorio: "insertar-URL-completa-en-índice-yml-en-otro-servidor"}, {versión: 11.0. +}]'

Debe ser la URL completa de la carpeta / directorio donde reside index.yml. El paquete de compilación le agregará /index.yml cuando genere la URL para descargar el archivo index.yml. Por lo tanto, su repository_root no debe terminar en /index.yml .

Parece que está eligiendo la JVM de esta ruta https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gz. ¿Dónde está configurado esto?

@ ajay-dbs: esta es probablemente la razón:

[ConfigurationUtils] WARN El valor de configuración del usuario para 'jres' no es válido, la propiedad existente no está presente

Está ignorando parte de su configuración. Tu JBP_CONFIG_COMPONENTS parece bien, pero querrás ver más de cerca lo que está sucediendo allí. No está aplicando esa parte de la configuración, por lo que no está eligiendo su JDK deseado.

¿Es porque falta un ":" entre JBP_CONFIG_COMPONENTS y ​​el valor?

¿Debería ser JBP_CONFIG_COMPONENTS: '{jres: ["JavaBuildpack :: Jre :: ZuluJRE"]}'

Depende de cómo establezca las variables env. Si los configura en el manifiesto, debería tener un : entre ellos. Si los configura con cf set-env entonces es solo name val .

Hola, equipo,

El equipo de la aplicación ha utilizado esta variable en el archivo manifest.yml.
JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: " https://example.com : 8051 / pcf"}, {versión: 11.0. +}]'
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack :: Jre :: ZuluJRE"]}'

@ ajay-dbs ya que está agregando las variables env en un manifest.yml, parece que los dos puntos que faltan pueden ser el problema. Por favor, arréglalo como

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

[Buildpack] ERROR Finalización fallida con excepción #https://cdn.azul.com/zulu/bin/index.yml>
Error de Zulu JRE: no se puede encontrar el archivo en caché para https://cdn.azul.com/zulu/bin/index.yml

Por cierto, el enlace a https://cdn.azul.com/zulu/bin/index.yml se ha restaurado ahora.

[ERR] [ConfigurationUtils] WARN El valor de configuración del usuario para 'versión' no es válido, la propiedad existente no está presente

Es un error diferente pero similar. Ahora parece estar aceptando jres cual es bueno. Puede ver que ahora también está ejecutando el contenedor Zulu.

En este caso, ahora no le gusta la parte en la que está intentando establecer la versión en 11.0. +. Lo que tienes ahí no está del todo bien.

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

debiera ser

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

Los version y repository_root están en el mismo objeto jre . En caso de duda, siempre puede consultar el archivo config/ asociado. La configuración JBP_CONFIG_* que agregue, debe coincidir con el formato del archivo de configuración, ya que se superpone encima de la configuración.

Vea la estructura para 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] ERROR Detección fallida con excepción #

Recuerdo haber visto algo como esto en el pasado si el caché se estropeaba con la aplicación. Intente enviar su aplicación con un nuevo nombre como "my-cool-app-2" o algo que sea único y nuevo. Si eso lo soluciona, deberá eliminar y volver a enviar su aplicación o pedirle a su administrador que borre la memoria caché del almacén de blobs de paquetes de compilación.

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

Tenga en cuenta que este último borrará el caché de todos los paquetes de compilación. Si bien esto no es destructivo, obligará a todos los paquetes de compilación a volver a descargar todos los recursos la próxima vez que se realice una aplicación.

Intentamos borrar el caché y también intentamos implementar una aplicación con un nombre y una ruta completamente nuevos. Sigue siendo el mismo problema.

Esto normalmente solucionará este tipo de problema, por lo que es bueno saber que no está ayudando aquí. Probablemente signifique que está sucediendo algo diferente.

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

Lo que me preocupa, además del error de almacenamiento en caché, es la ADVERTENCIA sobre /bin/detect y el `stat: no existe tal error de archivo o directorio. Eso debería suceder, y no sucedería con los paquetes de compilación que empaquetamos con las versiones.

¿De dónde sacas tu paquete de construcción? ¿Lo está descargando desde la página de lanzamientos y subiéndolo a CF? ¿Estás usando una URL a la página de github? Si es así, ¿cuál es la URL exacta? ¿Está obteniendo el paquete de compilación de otro lugar? ¿Estás empaquetando tu propio paquete de construcción? Si es así, intente utilizar el de la página de lanzamientos u otro paquete de compilación que funcione como prueba de referencia para ver si funciona como se esperaba, y también indique cómo está empaquetando el paquete de compilación. Cualquier detalle adicional que pueda proporcionar puede ayudar a detectar el problema o ayudar a reproducirlo.

Continúe promocionando como un nuevo nombre de aplicación mientras continúa probando porque queremos asegurarnos de que descartamos problemas de almacenamiento en caché.

Gracias

Un par de preguntas más ... ¿Funcionó anteriormente y se rompió recientemente? Si es así, ¿qué ha cambiado recientemente? ¿Actualizaste las versiones de buildpack? ¿Cambió archivos en su servidor que aloja Zulu? ¿Se pusieron nuevas actualizaciones de Zulu en su servidor? Si nunca ha funcionado o es la primera vez que lo prueba, avísenos también.

Gracias

@ mells82 Creo que el contenido de index.yml debería ser

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

eliminando el problema de creación de https donde el paquete de compilación no descargaría el archivo jre.

Hemos descargado el paquete de compilación sin conexión de java de pivortal y lo hemos guardado en el repositorio de PCF y luego usamos el paquete de compilación del repositorio de PCF.
Esta es la primera vez que intentamos ejecutar una aplicación con Azul Zulu JDK. De forma predeterminada, Oracle JDK se usa con Bellsoft VM y esta Bellsoft VM no es compatible con el seguimiento de instancias de objetos. Entonces estamos tratando de usar Azul Zulu JDK.

Bien, gracias por esta información. Las cosas tienen más sentido ahora.

La forma en que se empaqueta el paquete de construcción de Tanzu, se hace en modo "fuera de línea". Vea aquí, ejecutamos este script para empaquetarlo .

Cuando está en el modo "sin conexión", solo obtiene lo que está empaquetado en el paquete. El JBP no puede descargar otras cosas.

De los documentos para "sin conexión":

Empaqueta la última versión de cada dependencia (como se configura en el directorio config /) y deshabilita las descargas remotas.

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

Lo hace porque está destinado a ejecutarse en un entorno fuera de línea sin acceso a Internet.

Probé en un laboratorio con un JBP sin conexión y obtengo exactamente el mismo error que tú:

   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

Esto se debe a que ese archivo no existe en el caché sin conexión y, en el modo sin conexión, solo buscará en el caché.

Si desea utilizar Azul Zulu en un paquete de compilación sin conexión, debe empaquetar el paquete de compilación usted mismo con Zulu en él. De lo contrario, debe utilizar una versión en línea del paquete de compilación. Para empaquetar el paquete de compilación, consulte aquí y asegúrese de ajustar el archivo components.yml antes de empaquetarlo. Quieres que ese archivo indique Zulu.

Usar el paquete de compilación en línea funciona, pero como dijo index.yml debe formatearse correctamente. Por el momento, index.yml en https://cdn.azul.com/zulu/bin/index.yml no está formateado correctamente. Falta el protocolo, lo que causa problemas. Asegúrese de que su index.yml esté estructurado como el ejemplo en el comentario de @RageZBla .

gracias por el informe, index.yml ha sido actualizado: https://cdn.azul.com/zulu/bin/index.yml

@ ajay-dbs Si se encuentra en un entorno fuera de línea, debe empaquetar el paquete de compilación usted mismo. Para que otra persona lo haga por usted, se requiere autorización legal debido a los requisitos de redistribución del software. Sin mencionar los aspectos de seguridad de la distribución de software confiable. La forma más fácil de avanzar es empaquetar el paquete de compilación usted mismo.

El proceso está documentado aquí . Necesita empaquetar desde una computadora que tenga acceso a Internet porque necesita descargar las dependencias, sin embargo, son solo un par de comandos y no debería tomar más de unos minutos con una conexión a Internet razonablemente rápida.