Збирання образів 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-адреса ідентифікує цей контейнер, а не обов'язково робочу станцію розробника.
Свідомо підтримуйте й середовище виконання фінальної програми. Доступ під час збирання та маршрут, що використовується під час подальшого запуску програми, — це окремі рішення конфігурації.