Java-buildpack: Obtendo um erro ao usar o Azul Zulu JDK em microsserviços PCF

O local para o qual você aponta o buildpack, ou seja, repository_root , deve ser um repositório válido. Não há index.yml (pelo menos quando eu olhei agora) nesse local.

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

Hmm, parece que costumava haver um index.yml naquele local, mas não o vejo mais. Deixe-me perguntar por aí e ver o que posso encontrar.

Enquanto isso, se você criar seu próprio index.yml , hospede-o em algum lugar (não importa) e aponte para os arquivos nesse local (ou seja, https://cdn.azul.com/zulu/bin/zulu9 .0.7.1-jdk9.0.7-linux_x64.tar.gz), você pode contornar isso.

Usamos as variáveis ​​abaixo em 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 "}, {version: 11.0. +}] '
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack :: Jre :: ZuluJRE"]}'

OK, isso precisa ser um pouco diferente. O repository_root aponta para a pasta onde seu index.yml está localizado. Portanto, a URL que o JBP usa para baixar o index.yml é repository_root/index.yml .

O JBP então lerá index.yml, escolherá a versão mais recente correspondente ao filtro de versão que você especificou e fará o download do recurso referenciado em index.yml para essa versão.

Oi Dmikusa,

Então, isso significa que tanto o Zulu JDK quanto o index.yml devem estar no mesmo local?

Ok, entendo o que você está dizendo, o JBP_CONFIG_ZULU_JRE deve ser configurado como

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

Precisa ser a URL completa para a pasta / diretório onde o index.yml reside. O buildpack anexará /index.yml a ele quando gerar a URL para baixar o arquivo index.yml. Portanto, seu repository_root não deve terminar com /index.yml .

Parece que ele está escolhendo a JVM deste caminho https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gz. Onde isso está configurado?

@ ajay-dbs - Este é provavelmente o motivo:

[ConfigurationUtils] WARN O valor de configuração do usuário para 'jres' não é válido, a propriedade existente não está presente

Ele está ignorando parte de sua configuração. Seu JBP_CONFIG_COMPONENTS parece bom para mim, mas você vai querer olhar mais de perto o que está acontecendo lá. Ele não está aplicando essa parte da configuração, portanto, não está escolhendo o JDK desejado.

É por causa da falta de ":" entre JBP_CONFIG_COMPONENTS e o valor?

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

Depende de como você define as variáveis ​​env. Se você defini-los no manifesto, deve haver um : entre eles. Se você estiver configurando-os com cf set-env então será apenas name val .

Oi equipe,

A equipe do aplicativo usou essa variável no arquivo 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 como você está adicionando as variáveis ​​env em um manifest.yml, parece que a falta de dois pontos talvez seja o problema. Por favor, corrija como

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

[Buildpack] ERROR Finalize falhou com exceção #https://cdn.azul.com/zulu/bin/index.yml>
Erro Zulu JRE: não foi possível encontrar o arquivo em cache para https://cdn.azul.com/zulu/bin/index.yml

BTW, o link para https://cdn.azul.com/zulu/bin/index.yml foi restaurado agora.

[ERR] [ConfigurationUtils] WARN O valor de configuração do usuário para 'versão' não é válido, propriedade existente não está presente

É um erro diferente, mas semelhante. Parece que agora está aceitando jres que é bom. Você pode ver que ele também está executando o contêiner Zulu agora.

Neste caso, agora não gosta da parte em que você está tentando definir a versão para 11.0. +. O que você tem aí não está certo.

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

deveria estar

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

O version e repository_root estão no mesmo objeto jre . Em caso de dúvida, você sempre pode consultar o arquivo config/ associado. A configuração JBP_CONFIG_* você adiciona precisa corresponder ao formato do arquivo de configuração, pois é sobreposto na parte superior da configuração.

Veja a estrutura 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 Detect falhou com exceção #

Lembro-me de ter visto algo assim no passado, se o cache do app bagunçasse. Tente colocar seu aplicativo com um novo nome como "my-cool-app-2" ou algo que seja único e novo. Se isso resolver o problema, você precisará excluir e reenviar seu aplicativo ou fazer com que o administrador limpe o cache do blobstore de buildpacks.

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

Observe que o último limpará o cache de todos os buildpacks. Embora isso não seja destrutivo, ele forçará todos os buildpacks a baixar novamente todos os recursos na próxima vez que um aplicativo for testado.

Tentamos limpar o cache e também tentamos implantar um aplicativo com um nome e uma rota completamente novos. Ainda é o mesmo problema.

Isso normalmente corrigirá esse tipo de problema, então é bom saber que não está ajudando aqui. Provavelmente significa que algo diferente está acontecendo.

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

O que me preocupa, além do erro de cache, é o AVISO sobre /bin/detect e o `stat: nenhum arquivo ou diretório de erro. Isso deveria acontecer, e não aconteceria com os buildpacks que empacotamos com as versões.

Onde você está obtendo seu buildpack? Você está baixando da página Releases e enviando para CF? Você está usando um URL para a página do github? Em caso afirmativo, qual é o URL exato? Você está obtendo o buildpack de algum outro lugar? Você está empacotando seu próprio buildpack? Em caso afirmativo, tente usar aquele da página Releases ou outro buildpack conhecido em funcionamento como um teste de linha de base para ver se funciona conforme o esperado e também indique como você está empacotando o buildpack? Quaisquer detalhes adicionais que você possa fornecer podem ajudar a identificar o problema ou ajudar a reproduzi-lo.

Continue a enviar como um novo nome de aplicativo enquanto você continua a testar porque queremos garantir que estamos eliminando problemas de cache.

Obrigado

Mais algumas perguntas ... Isso estava funcionando anteriormente e quebrou recentemente? Em caso afirmativo, o que mudou recentemente? Você atualizou as versões do buildpack? Você alterou arquivos no servidor que hospeda o Zulu? Houve novas atualizações do Zulu colocadas em seu servidor? Se nunca funcionou ou se esta é a primeira vez que você está experimentando, informe-nos também.

Obrigado

@ mells82 Acho que o conteúdo de index.yml deveria 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

removendo o problema de criação de https em que o buildpack não baixava o jre.

Baixamos java offline buildpack de pivortal e mantemos no repositório PCF e então usamos buildpack do repositório PCF.
Esta é a primeira vez que tentamos executar um aplicativo com o Azul Zulu JDK. Por padrão, o oracle JDK é usado com o Bellsoft VM e este Bellsoft VM não suporta rastreamento de instância de objeto. Então, estamos tentando usar o Azul Zulu JDK.

OK, obrigado por esta informação. As coisas estão fazendo mais sentido agora.

A forma como o buildpack do Tanzu é empacotado é feito no modo "offline". Veja aqui, nós rodamos este script para empacotá-lo .

Quando no modo "offline", você obtém apenas o que está empacotado no pacote. O JBP não pode baixar outras coisas.

Na documentação para "offline":

Ele empacota a versão mais recente de cada dependência (conforme configurado no diretório config /) e desabilita remote_downloads.

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

Ele faz isso porque deve ser executado em um ambiente offline, sem acesso à Internet.

Tentei em um laboratório com um JBP offline e recebo exatamente o mesmo erro que você:

   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

Isso ocorre porque esse arquivo não existe no cache offline e no modo offline, ele só procurará no cache.

Se quiser usar o Azul Zulu em um buildpack offline, você precisa empacotar o buildpack com o Zulu nele. Caso contrário, você precisa usar uma versão online do buildpack. Para empacotar o buildpack, veja aqui e certifique-se de ajustar o components.yml antes de empacotar. Você quer que esse arquivo indique Zulu.

Usar o buildpack online funciona, mas como @RageZBla disse, index.yml precisa ser formatado corretamente. No momento, o index.yml em https://cdn.azul.com/zulu/bin/index.yml não está formatado corretamente. Está faltando o protocolo, o que causa problemas. Certifique-se de que seu index.yml está estruturado como o exemplo no comentário de @RageZBla .

obrigado pelo relatório, index.yml foi atualizado: https://cdn.azul.com/zulu/bin/index.yml

@ ajay-dbs Se você estiver em um ambiente offline, precisará empacotar o buildpack você mesmo. Para outra pessoa fazer isso por você, é necessária autorização legal devido aos requisitos de redistribuição de software. Sem mencionar os aspectos de segurança da distribuição de software confiável. A maneira mais fácil de avançar é empacotar o buildpack você mesmo.

O processo está documentado aqui . Você precisa empacotar de um computador que tenha acesso à Internet porque ele precisa baixar as dependências; no entanto, são apenas alguns comandos e não devem demorar mais do que alguns minutos com uma conexão razoavelmente rápida com a Internet.