Java-buildpack: Ошибка при использовании Azul Zulu JDK в микросервисах PCF

Местоположение, на которое вы указываете buildpack, то есть repository_root , должно быть действующим репозиторием. В этом месте нет index.yml (по крайней мере, когда я только что смотрел).

См. Https://github.com/cloudfoundry/java-buildpack/blob/main/docs/exnding-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"]}'

Хорошо, это должно немного отличаться. repository_root указывает на папку, в которой находится ваш index.yml . Таким образом, URL-адрес, который JBP использует для загрузки index.yml, - это repository_root/index.yml .

Затем JBP прочитает index.yml, выберет последнюю версию, соответствующую указанному вами фильтру версий, и загрузит ресурс, на который ссылается index.yml для этой версии.

Привет Дмикуса,

Значит ли это, что Zulu JDK и index.yml должны находиться в одном месте?

Хорошо, я понимаю, что вы говорите, JBP_CONFIG_ZULU_JRE должен быть настроен как

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

Это должен быть полный URL-адрес папки / каталога, в котором находится index.yml. Пакет сборки добавит к нему /index.yml когда он сгенерирует URL-адрес для загрузки файла index.yml. Таким образом, ваш repository_root не должен заканчиваться на /index.yml .

Похоже, он выбирает JVM с этого пути https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gz. Где это настроено?

@ ajay-dbs - Вероятно, причина:

[ConfigurationUtils] ПРЕДУПРЕЖДЕНИЕ. Значение конфигурации пользователя для 'jres' недействительно, существующее свойство отсутствует

Он игнорирует часть вашей конфигурации. Ваш JBP_CONFIG_COMPONENTS мне кажется нормальным, но вы захотите более внимательно посмотреть, что там происходит. Он не применяет эту часть конфигурации, поэтому не выбирает желаемый JDK.

Это из-за отсутствия символа «:» между JBP_CONFIG_COMPONENTS и значением?

Должен быть JBP_CONFIG_COMPONENTS: '{jres: ["JavaBuildpack :: Jre :: ZuluJRE"]}'

Это зависит от того, как вы устанавливаете переменные env. Если вы установите их в манифесте, между ними должен быть : . Если вы устанавливаете их с помощью 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, поскольку вы добавляете переменные env в manifest.yml, похоже, проблема в отсутствии двоеточия. Пожалуйста, исправьте это как

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

[Buildpack] ОШИБКА Завершить не удалось, исключение №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] WARN Значение конфигурации пользователя для 'версии' недействительно, существующее свойство отсутствует

Другая, но похожая ошибка. Кажется, теперь он принимает 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://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] Ошибка обнаружения ошибки, исключение №

Я помню, что видел что-то подобное в прошлом, если приложение испортило кеш. Попробуйте продвигать свое приложение под новым именем, например "my-cool-app-2" или чем-нибудь уникальным и новым. Если это исправит, вам нужно либо удалить и повторно отправить приложение, либо попросить администратора очистить кеш хранилища пакетов сборки.

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: no such file or directory error. Это должно произойти, а не со сборочными пакетами, которые мы упаковываем вместе с выпусками.

Где ты достаешь свой сборочный пакет? Вы загружаете его со страницы релизов и загружаете в CF? Вы используете URL-адрес страницы github? Если да, то каков точный URL? Вы получаете пакет сборки где-нибудь еще? Вы упаковываете свой собственный сборочный пакет? Если да, попробуйте использовать пакет со страницы «Релизы» или другой известный рабочий пакет сборки в качестве базового теста, чтобы убедиться, что он работает должным образом, а также укажите, как вы упаковываете пакет сборки? Любые дополнительные сведения, которые вы можете предоставить, могут помочь выявить проблему или воспроизвести ее.

Продолжайте использовать новое имя приложения, пока продолжаете тестирование, потому что мы хотим убедиться, что мы исключаем проблемы с кешированием.

Спасибо

Еще пара вопросов ... Это работало раньше, а недавно сломалось? Если да, то что изменилось за последнее время? Вы обновляли версии buildpack? Вы меняли файлы на своем сервере, на котором размещен 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

устранение проблемы создания https, когда пакет сборки не загружал jre.

Мы загрузили автономный пакет сборки Java из pivortal и сохранили его в репозитории PCF, а затем использовали buildpack из репозитория PCF.
Это первый раз, когда мы пытаемся запустить приложение с Azul Zulu JDK. По умолчанию Oracle JDK используется с виртуальной машиной Bellsoft, а эта виртуальная машина Bellsoft не поддерживает отслеживание экземпляров объектов. Итак, мы пытаемся использовать Azul Zulu JDK.

Хорошо, спасибо за эту информацию. Теперь все обретает смысл.

Сборочный пакет 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

Это связано с тем, что этот файл не существует в автономном кеше, а в автономном режиме он будет только искать в кеше.

Если вы хотите использовать Azul Zulu в автономном пакете сборки, вам нужно самостоятельно упаковать buildpack с Zulu в нем. В противном случае вам нужно использовать онлайн-версию buildpack. Чтобы упаковать buildpack, посмотрите здесь и убедитесь, что вы настроили components.yml перед упаковкой. Вы хотите, чтобы этот файл указывал на Zulu.

Использование онлайн-пакета сборки работает, но, как сказал @RageZBla, index.yml необходимо правильно отформатировать. На данный момент index.yml на https://cdn.azul.com/zulu/bin/index.yml отформатирован неправильно. Отсутствует протокол, что вызывает проблемы. Убедитесь, что ваш index.yml структурирован, как в примере в комментарии @RageZBla .

спасибо за отчет, index.yml обновился: https://cdn.azul.com/zulu/bin/index.yml

@ ajay-dbs Если вы находитесь в автономной среде, вам необходимо самостоятельно упаковать buildpack. Чтобы кто-то другой сделал это за вас, требуется юридическое разрешение в связи с требованиями распространения программного обеспечения. Не говоря уже об аспектах безопасности распространения надежного программного обеспечения. Самый простой способ - упаковать сборочный пакет самостоятельно.

Этот процесс задокументирован здесь . Вам действительно нужно выполнить пакет с компьютера, имеющего доступ к Интернету, потому что ему необходимо загрузить зависимости, однако это всего лишь пара команд и не должно занимать больше нескольких минут при достаточно быстром подключении к Интернету.