Сборка образов Spring Boot: настройка прокси сборщика Paketo
Передавайте прокси-переменные сборщику Paketo через Gradle bootBuildImage или Maven image.env, отдельно от инструмента сборки и демона Docker.
Инструмент сборки может успешно разрешить свои зависимости, тогда как 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-адрес обозначает именно этот контейнер, а не обязательно рабочую станцию разработчика.
Среду выполнения итогового приложения тоже делайте осознанной. Доступ во время сборки и маршрут, используемый при последующем запуске приложения, — это отдельные решения конфигурации.