E Build-Tool kann seng Ofhängegkeeten erfollegräich opléisen, während e Paketo-Buildpack keng Runtime erofklappe kann. De Buildpack leeft am Builder-Container a brauch seng eege Proxy-Agab.

Dem Gradle seng bootBuildImage-Aufgab

An enger Groovy build.gradle mat der existéierender bootBuildImage-Aufgab vu Spring Boot:

tasks.named("bootBuildImage") {
    environment["HTTP_PROXY"] = "http://proxy.example:8080"
    environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}

Den Maven-Plugin benotzt image.env

Fir spring-boot:build-image setzt dës Wäerter ënner image.env an der existéierender Konfiguratioun vum Spring Boot Maven-Plugin:

<configuration>
  <image>
    <env>
      <HTTP_PROXY>http://proxy.example:8080</HTTP_PROXY>
      <HTTPS_PROXY>http://proxy.example:8080</HTTPS_PROXY>
    </env>
  </image>
</configuration>

Souwuel d'Aufgabëmwelt vu Gradle wéi och image.env vu Maven ginn dem Builder Wäerter. Béid Nimm kënne deen selwechten normale HTTP-Zwëschemann bezeechnen, och fir HTTPS-Artefakt-URLen. Fir ëffentlech Artefakt-Downloads, déi iwwer ëffentlech Proxye erlaabt sinn, liwwert d'HTTP-Proxy-Lëscht Kandidaten fir dës Builder-Wäerter.

Dës Astellung ass onofhängeg vun de systemProp.http.proxyHost-Eegeschaften vu Gradle. Déi gehéieren zur JVM a konfiguréieren net automatesch en anere Prozess am Builder.

Den Docker-Daemon muss fir d'éischt déi néideg Builder- an Ausféierungs-Imagen ufroen. E Registrierungsfehler an där fréierer Etapp verlaangt d'Route an d'Registrierungskonfiguratioun vum Daemon, an net eng Variabel, déi engem Buildpack ginn ass, deen nach net gestart ass.

Benotzt en Proxy-Endpunkt, deen aus dem Builder-Container erreechbar ass. Seng Loopback-Adress identifizéiert dee Container, net onbedéngt dem Entwéckler seng Aarbechtsplaz.

Halt och d'Runtime-Ëmwelt vun der endgülteger Applikatioun bewosst. Den Zougrëff zur Build-Zäit an d'Route, déi benotzt gëtt wann d'Applikatioun méi spéit leeft, sinn getrennte Konfiguratiounsentscheedungen.

Ähnlech Artikelen