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.

Relaterade artiklar