Un instrument de build își poate rezolva dependențele cu succes, în timp ce un buildpack Paketo nu poate descărca un runtime. Buildpack-ul rulează în containerul builder-ului și are nevoie de propria intrare de proxy.

Sarcina bootBuildImage din Gradle

Într-un build.gradle Groovy cu sarcina bootBuildImage existentă din Spring Boot:

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

Plugin-ul Maven folosește image.env

Pentru spring-boot:build-image, plasează aceste valori sub image.env în configurația existentă a plugin-ului Spring Boot Maven:

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

Atât mediul sarcinii Gradle, cât și image.env din Maven furnizează valori builder-ului. Ambele nume pot desemna același intermediar HTTP obișnuit, inclusiv pentru URL-uri de artefacte HTTPS. Pentru descărcări publice de artefacte permise prin proxy-uri publice, lista de proxy-uri HTTP oferă candidați pentru aceste valori ale builder-ului.

Această setare este independentă de proprietățile systemProp.http.proxyHost din Gradle. Acelea aparțin JVM-ului și nu configurează automat alt proces din builder.

Daemonul Docker trebuie să obțină mai întâi imaginile de builder și de execuție necesare. O eroare de registru în acea etapă anterioară necesită ruta și configurația de registru ale daemonului, nu o variabilă transmisă unui buildpack care nu a pornit încă.

Folosește un endpoint de proxy accesibil din containerul builder-ului. Adresa sa de loopback identifică acel container, nu neapărat stația de lucru a dezvoltatorului.

Păstrează deliberat și mediul de execuție al aplicației finale. Accesul în timpul build-ului și ruta folosită când aplicația rulează ulterior sunt decizii de configurare separate.

Articole similare