Kūrimo įrankis gali sėkmingai išspręsti savo priklausomybes, tačiau Paketo buildpack negali atsisiųsti vykdymo aplinkos. Buildpack veikia builder konteinerio viduje ir jam reikia savo proxy įvesties.

Gradle bootBuildImage užduotis

Groovy build.gradle faile su esama Spring Boot bootBuildImage užduotimi:

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

Maven papildinys naudoja image.env

Jei naudojate spring-boot:build-image, įdėkite šias reikšmes po image.env esamoje Spring Boot Maven papildinio konfigūracijoje:

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

Tiek Gradle užduoties aplinka, tiek Maven image.env perduoda builder reikšmes. Abu pavadinimai gali žymėti tą patį įprastą HTTP tarpininką, įskaitant HTTPS artefaktų URL. Viešiems artefaktų atsisiuntimams, leidžiamiems per viešus proxy, HTTP proxy sąrašas siūlo kandidatus šioms builder reikšmėms.

Šis nustatymas nepriklauso nuo Gradle systemProp.http.proxyHost savybių. Jos priklauso JVM ir automatiškai nekonfigūruoja kito proceso builder viduje.

Docker demonas pirmiausia turi gauti reikiamus builder ir vykdymo atvaizdus. Registro klaida tame ankstesniame etape reikalauja demono maršruto ir registro konfigūracijos, o ne kintamojo, perduoto buildpack, kuris dar neprasidėjo.

Naudokite proxy galinį tašką, pasiekiamą iš builder konteinerio. Jo loopback adresas nurodo tą konteinerį, o ne būtinai kūrėjo darbo vietą.

Taip pat sąmoningai palaikykite galutinės programos vykdymo aplinką. Prieiga kūrimo metu ir maršrutas, naudojamas vėliau paleidus programą, yra atskiri konfigūracijos sprendimai.

Susiję straipsniai