Et byggeværktøj kan løse sine afhængigheder med succes, mens en Paketo-buildpack ikke kan hente en runtime. Buildpacken kører inde i byggerens container og har brug for sit eget proxy-input.

Gradles bootBuildImage-opgave

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

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

Maven-pluginet bruger image.env

For spring-boot:build-image skal du placere disse værdier under image.env i den eksisterende Spring Boot Maven-plugin-konfiguration:

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

Både Gradles opgaveenvironnement og Mavens image.env leverer værdier til byggeren. Begge navne kan betegne den samme almindelige HTTP-mellemmand, også for HTTPS-artefakt-URL'er. Til offentlige artefakt-downloads, der er tilladt via offentlige proxyer, leverer HTTP-proxylisten kandidater til disse byggerværdier.

Denne indstilling er uafhængig af Gradles systemProp.http.proxyHost-egenskaber. De tilhører JVM'en og konfigurerer ikke automatisk en anden proces i byggeren.

Docker-dæmonen skal først hente de nødvendige bygger- og runtime-images. En registry-fejl på det tidligere trin kræver dæmonens rute- og registry-konfiguration i stedet for en variabel, der gives til en buildpack, som endnu ikke er startet.

Brug et proxy-endpoint, der kan nås fra byggerens container. Dens loopback-adresse identificerer den container, ikke nødvendigvis udviklerens arbejdsstation.

Hold også den endelige applikations runtime-miljø bevidst. Adgang under byggetiden og den rute, der bruges, når applikationen senere kører, er separate konfigurationsbeslutninger.

Relaterede artikler