In bouwark kin syn ôfhinklikheden mei súkses oplosse, wylst in Paketo-buildpack gjin runtime downloade kin. It buildpack draait yn 'e kontener fan 'e bouwer en hat syn eigen proxy-ynput nedich.

De bootBuildImage-taak fan Gradle

Yn in Groovy build.gradle mei de besteande bootBuildImage-taak fan Spring Boot:

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

De Maven-plugin brûkt image.env

Foar spring-boot:build-image sette dy wearden ûnder image.env yn 'e besteande konfiguraasje fan 'e 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>

Sawol de taakomjouwing fan Gradle as image.env fan Maven jouwe wearden oan 'e bouwer. Beide nammen kinne deselde gewoane HTTP-tuskenpersoan oanjaan, ek foar HTTPS-artefakt-URL's. Foar iepenbiere artefakt-downloads dy't tastien binne fia iepenbiere proxy's, leveret de HTTP-proxylist kandidaten foar dizze bouwerwearden.

Dizze ynstelling is ûnôfhinklik fan Gradle's systemProp.http.proxyHost-eigenskippen. Dy hearre by de JVM en konfigurearje net automatysk in oar proses yn 'e bouwer.

De Docker-daemon moat earst de fereaske bouwer- en runtime-ôfbyldings krije. In registry-flater yn dy eardere faze freget de rûte en registry-konfiguraasje fan 'e daemon, net in fariabele dy't oan in buildpack jûn wurdt dat noch net begûn is.

Brûk in proxy-einpunt dat berikber is fan 'e kontener fan 'e bouwer. It loopback-adres dêrfan identifisearret dy kontener, net needsaaklik it wurkstasjon fan 'e ûntwikkeler.

Hâld ek de runtime-omjouwing fan 'e definitive applikaasje bewust. Tagong yn 'e boutiid en de rûte dy't brûkt wurdt as de applikaasje letter draait, binne aparte konfiguraasjebesluten.

Relatearre artikelen