Spring Boot-imagebygg: konfigurer proxyen for Paketo-byggeren
Send proxyvariabler til en Paketo-bygger via Gradle bootBuildImage eller Maven image.env, atskilt fra byggeverktøyet og Docker-demonen.
Et byggeverktøy kan løse avhengighetene sine, mens en Paketo-buildpack ikke får lastet ned en kjøretid. Buildpacken kjører inne i byggerens container og trenger sitt eget proxy-innhold.
Gradles bootBuildImage-oppgave
I en Groovy build.gradle med Spring Boots eksisterende bootBuildImage-oppgave:
tasks.named("bootBuildImage") {
environment["HTTP_PROXY"] = "http://proxy.example:8080"
environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}
Maven-plugin-modulen bruker image.env
For spring-boot:build-image plasserer du disse verdiene under image.env i den eksisterende konfigurasjonen for Spring Boot Maven-plugin-modulen:
<configuration>
<image>
<env>
<HTTP_PROXY>http://proxy.example:8080</HTTP_PROXY>
<HTTPS_PROXY>http://proxy.example:8080</HTTPS_PROXY>
</env>
</image>
</configuration>
Både oppgavemiljøet i Gradle og image.env i Maven gir verdier til byggeren. Begge navnene kan betegne den samme vanlige HTTP-mellommannen, også for HTTPS-artefakt-URL-er. For offentlige artefaktnedlastinger som tillates via offentlige proxyer, gir HTTP-proxylisten kandidater for disse byggerverdiene.
Denne innstillingen er uavhengig av Gradles systemProp.http.proxyHost-egenskaper. De tilhører JVM-en og konfigurerer ikke automatisk en annen prosess i byggeren.
Docker-demonen må først hente bygger- og kjøretidsbildene som trengs. En registerfeil på det tidligere stadiet krever demonens rute- og registerkonfigurasjon, ikke en variabel som gis til en buildpack som ennå ikke er startet.
Bruk et proxy-endepunkt som kan nås fra byggerens container. Loopback-adressen identifiserer den containeren, ikke nødvendigvis utviklerens arbeidsstasjon.
Hold også kjøretidsmiljøet til den endelige applikasjonen bevisst. Tilgang under bygging og ruten som brukes når applikasjonen kjører senere, er separate konfigurasjonsbeslutninger.