Egy build-eszköz sikeresen feloldhatja a függőségeit, miközben egy Paketo buildpack nem tud letölteni egy futtatókörnyezetet. A buildpack a builder konténerében fut, és saját proxybevitelre van szüksége.

A Gradle bootBuildImage feladata

Egy Groovy build.gradle fájlban a Spring Boot meglévő bootBuildImage feladatával:

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

A Maven beépülő az image.env-et használja

A spring-boot:build-image esetében helyezze ezeket az értékeket az image.env alá a meglévő Spring Boot Maven beépülő konfigurációjában:

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

A Gradle feladatkörnyezete és a Maven image.env beállítása egyaránt értékeket ad a buildernek. Mindkét név ugyanazt a hétköznapi HTTP-közvetítőt jelölheti, HTTPS-összetevők URL-jei esetében is. A nyilvános proxykon keresztül engedélyezett nyilvános összetevő-letöltésekhez a HTTP-proxylista kínál jelölteket ezekhez a builderértékekhez.

Ez a beállítás független a Gradle systemProp.http.proxyHost tulajdonságaitól. Azok a JVM-hez tartoznak, és nem konfigurálnak automatikusan más folyamatot a builderben.

A Docker démonnak először be kell szereznie a szükséges builder- és futtató image-eket. A regisztrációs hiba abban a korábbi szakaszban a démon útvonal- és regisztrációs konfigurációját igényli, nem pedig egy olyan változót, amelyet egy még el nem indult buildpack kap.

Használjon a builder konténeréből elérhető proxyvégpontot. Ennek loopback-címe azonosítja azt a konténert, nem feltétlenül a fejlesztő munkaállomását.

Tartsa szándékosnak a végleges alkalmazás futtatókörnyezetét is. A build idejű hozzáférés és az alkalmazás későbbi futásakor használt útvonal külön konfigurációs döntések.

Kapcsolódó cikkek