Инструмент сборки может успешно разрешить свои зависимости, тогда как buildpack Paketo не может загрузить среду выполнения. Buildpack работает внутри контейнера сборщика и нуждается в собственном прокси-вводе.

Задача bootBuildImage в Gradle

В файле Groovy build.gradle с существующей задачей bootBuildImage из Spring Boot:

tasks.named("bootBuildImage") {
    environment["HTTP_PROXY"] = "http://proxy.example:8080"
    environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}

Плагин Maven использует image.env

Для spring-boot:build-image поместите эти значения в раздел image.env существующей конфигурации плагина Spring Boot Maven:

<configuration>
  <image>
    <env>
      <HTTP_PROXY>http://proxy.example:8080</HTTP_PROXY>
      <HTTPS_PROXY>http://proxy.example:8080</HTTPS_PROXY>
    </env>
  </image>
</configuration>

И окружение задачи Gradle, и image.env в Maven передают значения сборщику. Оба имени могут обозначать один и тот же обычный посредник HTTP, в том числе для URL артефактов HTTPS. Для публичных загрузок артефактов, разрешённых через публичные прокси, список прокси HTTP предлагает кандидатов для этих значений сборщика.

Этот параметр не зависит от свойств systemProp.http.proxyHost в Gradle. Они принадлежат JVM и не настраивают автоматически другой процесс внутри сборщика.

Демон Docker сначала должен получить нужные образы сборщика и выполнения. Сбой реестра на этом более раннем этапе требует маршрута и конфигурации реестра демона, а не переменной, переданной buildpack, который ещё не запустился.

Используйте прокси-эндпоинт, доступный из контейнера сборщика. Его loopback-адрес обозначает именно этот контейнер, а не обязательно рабочую станцию разработчика.

Среду выполнения итогового приложения тоже делайте осознанной. Доступ во время сборки и маршрут, используемый при последующем запуске приложения, — это отдельные решения конфигурации.

Похожие статьи