Budowanie obrazów Spring Boot: konfiguracja proxy buildera Paketo

Przekazuj zmienne proxy do buildera Paketo przez Gradle bootBuildImage lub Maven image.env, oddzielnie od narzędzia budującego i demona Docker.

Narzędzie budujące może z powodzeniem rozwiązać swoje zależności, podczas gdy buildpack Paketo nie potrafi pobrać środowiska uruchomieniowego. Buildpack działa wewnątrz kontenera buildera i potrzebuje własnego wejścia proxy.

Zadanie bootBuildImage w Gradle

W pliku Groovy build.gradle z istniejącym zadaniem bootBuildImage Spring Boot:

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

Wtyczka Maven używa image.env

Dla spring-boot:build-image umieść te wartości pod image.env w istniejącej konfiguracji wtyczki 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>

Zarówno środowisko zadania Gradle, jak i image.env w Maven przekazują wartości do buildera. Obie nazwy mogą wskazywać ten sam zwykły pośrednik HTTP, także dla adresów URL artefaktów HTTPS. W przypadku publicznych pobrań artefaktów dozwolonych przez publiczne proxy lista proxy HTTP dostarcza kandydatów dla tych wartości buildera.

To ustawienie jest niezależne od właściwości systemProp.http.proxyHost w Gradle. Należą one do JVM i nie konfigurują automatycznie innego procesu w builderze.

Demon Docker musi najpierw uzyskać wymagane obrazy buildera i środowiska uruchomieniowego. Awaria rejestru na tym wcześniejszym etapie wymaga skonfigurowania trasy i rejestru demona, a nie zmiennej przekazanej buildpackowi, który jeszcze nie wystartował.

Używaj punktu końcowego proxy osiągalnego z kontenera buildera. Jego adres loopback identyfikuje ten kontener, a niekoniecznie stację roboczą dewelopera.

Utrzymuj też świadomie środowisko uruchomieniowe końcowej aplikacji. Dostęp w czasie budowania i trasa używana podczas późniejszego działania aplikacji to odrębne decyzje konfiguracyjne.

Powiązane artykuły