Spring Boot-imagebuilds: konfigurer Paketo-byggerens proxy
Send proxyvariabler til en Paketo-bygger via Gradle bootBuildImage eller Maven image.env, adskilt fra byggeværktøjet og Docker-dæmonen.
Et byggeværktøj kan løse sine afhængigheder med succes, mens en Paketo-buildpack ikke kan hente en runtime. Buildpacken kører inde i byggerens container og har brug for sit eget proxy-input.
Gradles bootBuildImage-opgave
I en Groovy build.gradle med Spring Boots eksisterende bootBuildImage-opgave:
tasks.named("bootBuildImage") {
environment["HTTP_PROXY"] = "http://proxy.example:8080"
environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}
Maven-pluginet bruger image.env
For spring-boot:build-image skal du placere disse værdier under image.env i den eksisterende Spring Boot Maven-plugin-konfiguration:
<configuration>
<image>
<env>
<HTTP_PROXY>http://proxy.example:8080</HTTP_PROXY>
<HTTPS_PROXY>http://proxy.example:8080</HTTPS_PROXY>
</env>
</image>
</configuration>
Både Gradles opgaveenvironnement og Mavens image.env leverer værdier til byggeren. Begge navne kan betegne den samme almindelige HTTP-mellemmand, også for HTTPS-artefakt-URL'er. Til offentlige artefakt-downloads, der er tilladt via offentlige proxyer, leverer HTTP-proxylisten kandidater til disse byggerværdier.
Denne indstilling er uafhængig af Gradles systemProp.http.proxyHost-egenskaber. De tilhører JVM'en og konfigurerer ikke automatisk en anden proces i byggeren.
Docker-dæmonen skal først hente de nødvendige bygger- og runtime-images. En registry-fejl på det tidligere trin kræver dæmonens rute- og registry-konfiguration i stedet for en variabel, der gives til en buildpack, som endnu ikke er startet.
Brug et proxy-endpoint, der kan nås fra byggerens container. Dens loopback-adresse identificerer den container, ikke nødvendigvis udviklerens arbejdsstation.
Hold også den endelige applikations runtime-miljø bevidst. Adgang under byggetiden og den rute, der bruges, når applikationen senere kører, er separate konfigurationsbeslutninger.