Een build-tool kan zijn afhankelijkheden met succes oplossen, terwijl een Paketo-buildpack geen runtime kan downloaden. De buildpack draait in de container van de builder en heeft zijn eigen proxy-invoer nodig.

De bootBuildImage-taak van Gradle

In een Groovy build.gradle met de bestaande bootBuildImage-taak van Spring Boot:

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

De Maven-plugin gebruikt image.env

Voor spring-boot:build-image plaatst u deze waarden onder image.env in de bestaande configuratie van de 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>

Zowel de taakomgeving van Gradle als image.env van Maven geven waarden aan de builder. Beide namen kunnen dezelfde gewone HTTP-tussenpersoon aanduiden, ook voor HTTPS-artefact-URL's. Voor openbare artefactdownloads die via openbare proxy's zijn toegestaan, levert de HTTP-proxylijst kandidaten voor deze builderwaarden.

Deze instelling staat los van de systemProp.http.proxyHost-eigenschappen van Gradle. Die horen bij de JVM en configureren niet automatisch een ander proces in de builder.

De Docker-daemon moet eerst de vereiste builder- en runtime-images ophalen. Een registerfout in die eerdere fase vereist de route- en registerconfiguratie van de daemon, niet een variabele die aan een buildpack wordt gegeven dat nog niet is gestart.

Gebruik een proxy-eindpunt dat bereikbaar is vanuit de container van de builder. Het loopbackadres daarvan identificeert die container, niet per se het werkstation van de ontwikkelaar.

Houd ook de runtime-omgeving van de uiteindelijke applicatie bewust. Toegang tijdens de build en de route die wordt gebruikt wanneer de applicatie later draait, zijn afzonderlijke configuratiebeslissingen.

Gerelateerde artikelen