Java-buildpack: PCFマイクロサービスでAzulZuluJDKを使用中にエラーが発生する

ビルドパックを指定する場所、つまりrepository_rootは、有効なリポジトリである必要があります。 その場所にはindex.ymlはありません（少なくとも今見たときは）。

https://github.com/cloudfoundry/java-buildpack/blob/main/docs/extending-repositories.mdを参照して

うーん、その場所にはかつてindex.ymlがあったようですが、もう見えません。 周りに聞いて、何が見つかるか見てみましょう。

それまでの間、独自のindex.ymlを作成する場合は、それをどこかでホストし（関係ありません）、その場所にあるファイルをポイントします（つまり、https：//cdn.azul.com/zulu/bin/zulu9 .0.7.1-jdk9.0.7-linux_x64.tar.gz）、これを回避できます。

アプリケーションのmanifest.ymlで以下の変数を使用しました-
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 "}、{バージョン：11.0。+}] '
JBP_CONFIG_COMPONENTS '{jres：["JavaBuildpack :: Jre :: ZuluJRE"]}'

OK、これは少し違う必要があります。 repository_rootは、 index.ymlが配置されているフォルダーを指します。 したがって、JBPがindex.ymlをダウンロードするために使用するURLはrepository_root/index.ymlです。

次に、JBPはindex.ymlを読み取り、指定したバージョンフィルターに一致する最新バージョンを選択し、そのバージョンのindex.ymlから参照されるリソースをダウンロードします。

こんにちはDmikusa、

つまり、Zulu JDKとindex.ymlの両方が同じ場所にある必要があるということですか？

わかりました。あなたの言っていることがわかります。JBP_CONFIG_ZULU_JREは次のように設定する必要があります。

JBP_CONFIG_ZULU_JRE： '[jre：{repository_root： "insert-full-URL-to-index-yml-on-another-server"}、{バージョン：11.0。+}]'

index.ymlが存在するフォルダ/ディレクトリへの完全なURLである必要があります。 ビルドパックは、index.ymlファイルをダウンロードするためのURLを生成するときに、 /index.ymlを追加します。 したがって、 repository_rootは/index.yml終わるべきではありません。

このパスhttps://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gzからJVMを選択しているようです

@ ajay-dbs-これが理由である可能性があります：

[ConfigurationUtils]警告 'jres'のユーザー構成値が無効です。既存のプロパティが存在しません

構成の一部を無視しています。 あなたのJBP_CONFIG_COMPONENTSは私には問題ないように見えますが、そこで何が起こっているのかをもっと詳しく調べたいと思うでしょう。 構成のその部分を適用していないため、目的のJDKを選択していません。

JBP_CONFIG_COMPONENTSと値の間に「：」がないためですか？

JBP_CONFIG_COMPONENTSである必要があります： '{jres：["JavaBuildpack :: Jre :: ZuluJRE"]}'

これは、環境変数をどのように設定するかによって異なります。 マニフェストでそれらを設定する場合、その間に:が必要です。 cf set-env設定している場合は、 name valです。

こんにちはチーム、

アプリケーションチームは、manifest.ymlファイルでこの変数を使用しました。
JBP_CONFIG_ZULU_JRE： '[jre：{repository_root： " https://example.com：8051 / pcf"}、{バージョン：11.0。+}]'
JBP_CONFIG_COMPONENTS '{jres：["JavaBuildpack :: Jre :: ZuluJRE"]}'

@ ajay-dbsマニフェスト.ymlに環境変数を追加しているので、コロンが欠落していることが問題である可能性があります。 次のように修正してください

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

[ビルドパック]エラーファイナライズが例外＃で失敗しましたhttps://cdn.azul.com/zulu/bin/index.yml>
Zulu JREエラー： https ：//cdn.azul.com/zulu/bin/index.ymlのキャッシュファイルが見つかりません

ところで、 https： //cdn.azul.com/zulu/bin/index.ymlへのリンクが復元されました。

[ERR] [ConfigurationUtils]警告「バージョン」のユーザー構成値が無効です。既存のプロパティが存在しません

異なるが同様のエラーです。 今はjresを受け入れているようです。これは良いことです。 これで、実際にZuluコンテナが実行されていることがわかります。

この場合、バージョンを11.0。+に設定しようとしている部分が気に入らないようになりました。 あなたが持っているものは完全に正しくありません。

JBP_CONFIG_ZULU_JRE： '[jre：{repository_root： " https://example.com：8051 / pcf"}、{バージョン：11.0。+}]'

する必要があります

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

versionとrepository_rootは同じjreオブジェクト上にあります。 疑わしい場合は、関連するconfig/ファイルをいつでも確認できます。 追加するJBP_CONFIG_*は、構成の上にオーバーレイされるため、構成ファイルの形式と一致する必要があります。

Zuluの構造を参照してください： https ：

021-06-14T13：14：15.960 + 05：30 [STG / 0] [ERR] [Buildpack]エラー検出が例外＃で失敗しました

キャッシュがアプリで台無しになった場合、過去にこのようなものを見たことを思い出します。 「my-cool-app-2」などの新しい名前でアプリをプッシュしてみてください。 それで問題が解決した場合は、アプリを削除して再プッシュするか、管理者にビルドパックのblobstoreキャ​​ッシュをクリアしてもらう必要があります。

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

後者はすべてのビルドパックのキャッシュをクリアすることに注意してください。 これは破壊的なものではありませんが、次にアプリケーションがステージングされるときに、すべてのビルドパックにすべてのリソースを再ダウンロードするように強制します。

キャッシュをクリアしようとしました。また、ルートだけでなく、まったく新しい名前でアプリをデプロイしようとしました。 それでも同じ問題。

これは通常、このタイプの問題を修正するので、ここでは役に立たないことを知っておくとよいでしょう。 それはおそらく何か違うことが起こっていることを意味します。

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

キャッシュエラー以外に私が心配しているのは、 /bin/detectに関する警告と `stat：そのようなファイルまたはディレクトリエラーはありません。 これらは発生するはずであり、リリースとともにパッケージ化するビルドパックでは発生しません。

ビルドパックはどこで入手できますか？ リリースページからダウンロードしてCFにアップロードしていますか？ githubページへのURLを使用していますか？ もしそうなら、正確なURLは何ですか？ ビルドパックを別の場所から入手していますか？ 独自のビルドパックをパッケージ化していますか？ その場合は、リリースページのビルドパックまたは別の既知の動作中のビルドパックをベースラインテストとして使用して、期待どおりに動作するかどうかを確認してください。また、ビルドパックをどのようにパッケージ化しているかを示してください。 提供できる追加の詳細は、問題の特定や問題の再現に役立つ場合があります。

キャッシュの問題を排除していることを確認したいので、テストを続ける間、新しいアプリ名としてプッシュし続けてください。

ありがとう

さらにいくつか質問があります...これは以前は機能していましたが、最近壊れましたか？ もしそうなら、最近何が変わったのですか？ ビルドパックのバージョンをアップグレードしましたか？ Zuluをホストしているサーバー上のファイルを変更しましたか？ サーバーに新しいZuluアップデートが追加されましたか？ それが一度も機能しなかった場合、またはこれが初めての場合は、それもお知らせください。

ありがとう

@ mells82 index.ymlの内容は

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

ビルドパックがjreをダウンロードしないhttpscreateの問題を削除します。

pivortalからjavaオフラインビルドパックをダウンロードしてPCFリポジトリに保存し、PCFリポジトリからビルドパックを使用します。
Azul ZuluJDKでアプリを実行しようとするのはこれが初めてです。 デフォルトでは、oracleJDKはBellsoftVMで使用され、このBellsoftVMはオブジェクトインスタンストラッキングをサポートしていません。 そのため、Azul ZuluJDKを使用しようとしています。

OK、この情報をありがとう。 物事は今より理にかなっています。

Tanzuビルドパックのパッケージ方法は、「オフライン」モードで実行されます。 ここを参照してください。

「オフライン」モードの場合、バンドルにパッケージ化されているもののみを取得します。 JBPは他のものをダウンロードできません。

「オフライン」のドキュメントから：

各依存関係の最新バージョン（config /ディレクトリで構成されている）をパッケージ化し、remote_downloadsを無効にします。

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

これは、インターネットにアクセスできないオフライン環境で実行することを目的としているためです。

オフラインのJBPを使用してラボで試しましたが、まったく同じエラーが発生します。

   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

これは、そのファイルがオフラインキャッシュとオフラインモードに存在せず、キャッシュ内でのみ検索されるためです。

オフラインビルドパックでAzulZuluを使用する場合は、ビルドパックをZuluと一緒に自分でパッケージ化する必要があります。 それ以外の場合は、ビルドパックのオンラインバージョンを使用する必要があります。 ビルドパックをパッケージ化するには、ここを参照し、パッケージ化する前にcomponents.ymlを調整してください。 そのファイルにZuluを示す必要があります。

オンラインビルドパックの使用は機能しますが、 @ RageZBlaが言ったように、 index.ymlは正しくフォーマットする必要があります。 現時点では、 https： //cdn.azul.com/zulu/bin/index.ymlのindex.ymlが正しくフォーマットされていません。 プロトコルが欠落しているため、問題が発生します。 index.ymlが@RageZBlaのコメントの例のように構成されていることを確認してください。

レポートのおかげで、index.ymlが更新されました： https ：//cdn.azul.com/zulu/bin/index.yml

@ ajay-dbsオフライン環境にいる場合は、ビルドパックを自分でパッケージ化する必要があります。 他の誰かがあなたのためにそれをするためには、ソフトウェアを再配布する必要があるため、法的許可が必要です。 言うまでもなく、信頼できるソフトウェアを配布する際のセキュリティ面。 前進する最も簡単な方法は、ビルドパックを自分でパッケージ化することです。

プロセスはここに文書化されています。 依存関係をダウンロードする必要があるため、インターネットにアクセスできるコンピューターからパッケージ化する必要がありますが、コマンドは2、3であり、適度に高速なインターネット接続で数分以上かかることはありません。