Et byggeverktøy kan løse avhengighetene sine, mens en Paketo-buildpack ikke får lastet ned en kjøretid. Buildpacken kjører inne i byggerens container og trenger sitt eget proxy-innhold.

Gradles bootBuildImage-oppgave

I en Groovy build.gradle med Spring Boots eksisterende bootBuildImage-oppgave:

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

Maven-plugin-modulen bruker image.env

For spring-boot:build-image plasserer du disse verdiene under image.env i den eksisterende konfigurasjonen for Spring Boot Maven-plugin-modulen:

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

Både oppgavemiljøet i Gradle og image.env i Maven gir verdier til byggeren. Begge navnene kan betegne den samme vanlige HTTP-mellommannen, også for HTTPS-artefakt-URL-er. For offentlige artefaktnedlastinger som tillates via offentlige proxyer, gir HTTP-proxylisten kandidater for disse byggerverdiene.

Denne innstillingen er uavhengig av Gradles systemProp.http.proxyHost-egenskaper. De tilhører JVM-en og konfigurerer ikke automatisk en annen prosess i byggeren.

Docker-demonen må først hente bygger- og kjøretidsbildene som trengs. En registerfeil på det tidligere stadiet krever demonens rute- og registerkonfigurasjon, ikke en variabel som gis til en buildpack som ennå ikke er startet.

Bruk et proxy-endepunkt som kan nås fra byggerens container. Loopback-adressen identifiserer den containeren, ikke nødvendigvis utviklerens arbeidsstasjon.

Hold også kjøretidsmiljøet til den endelige applikasjonen bevisst. Tilgang under bygging og ruten som brukes når applikasjonen kjører senere, er separate konfigurasjonsbeslutninger.

Relaterte artikler