Spring Boot-avbildningar: konfigurera Paketo-byggarens proxy
Skicka proxyvariabler till en Paketo-byggare via Gradle bootBuildImage eller Maven image.env, separat från byggverktyget och Docker-demonen.
Ett byggverktyg kan lösa sina beroenden, medan ett Paketo-buildpack inte kan hämta en körmiljö. Buildpacket körs inuti byggarens container och behöver sin egen proxyindata.
Gradles bootBuildImage-uppgift
I en Groovy build.gradle med Spring Boots befintliga bootBuildImage-uppgift:
tasks.named("bootBuildImage") {
environment["HTTP_PROXY"] = "http://proxy.example:8080"
environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}
Maven-insticksmodulen använder image.env
För spring-boot:build-image placerar du dessa värden under image.env i den befintliga konfigurationen för Spring Boot Maven-insticksmodulen:
<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 uppgiftsmiljö och Mavens image.env ger värden till byggaren. Båda namnen kan beteckna samma vanliga HTTP-mellanhand, även för HTTPS-artefakt-URL:er. För offentliga artefaktnedladdningar som tillåts via offentliga proxyservrar tillhandahåller HTTP-proxylistan kandidater för dessa byggarvärden.
Den här inställningen är oberoende av Gradles systemProp.http.proxyHost-egenskaper. De tillhör JVM:en och konfigurerar inte automatiskt en annan process i byggaren.
Docker-demonen måste först hämta de byggar- och köravbildningar som krävs. Ett registerfel i det tidigare skedet kräver demonens rutt- och registerkonfiguration, inte en variabel som ges till ett buildpack som ännu inte har startat.
Använd en proxy-slutpunkt som nås från byggarens container. Dess loopback-adress identifierar den containern, inte nödvändigtvis utvecklarens arbetsstation.
Håll också den slutliga applikationens körmiljö medveten. Åtkomst vid byggtiden och rutten som används när applikationen körs senare är separata konfigurationsbeslut.