빌드 도구가 의존성을 성공적으로 해결해도 Paketo 빌드팩은 런타임을 내려받지 못할 수 있습니다. 빌드팩은 빌더 컨테이너 안에서 실행되며 자체 프록시 입력이 필요합니다.

Gradle의 bootBuildImage 태스크

Spring Boot의 기존 bootBuildImage 태스크를 사용하는 Groovy build.gradle에서:

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

Maven 플러그인은 image.env를 사용합니다

spring-boot:build-image의 경우 기존 Spring Boot Maven 플러그인 구성의 image.env 아래에 이 값들을 넣으십시오:

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

Gradle의 태스크 환경과 Maven의 image.env 모두 빌더에 값을 제공합니다. 두 이름 모두 같은 일반 HTTP 중개자를 가리킬 수 있으며 HTTPS 아티팩트 URL에도 마찬가지입니다. 공용 프록시를 통해 허용되는 공용 아티팩트 다운로드에는 HTTP 프록시 목록이 이러한 빌더 값의 후보를 제공합니다.

이 설정은 Gradle의 systemProp.http.proxyHost 속성과 무관합니다. 그 속성은 JVM에 속하며 빌더 안의 다른 프로세스를 자동으로 구성하지 않습니다.

Docker 데몬은 먼저 필요한 빌더 및 실행 이미지를 확보해야 합니다. 그 이전 단계의 레지스트리 실패에는 아직 시작하지 않은 빌드팩에 넘기는 변수가 아니라 데몬의 경로와 레지스트리 구성이 필요합니다.

빌더 컨테이너에서 도달할 수 있는 프록시 엔드포인트를 사용하십시오. 그 루프백 주소가 가리키는 것은 해당 컨테이너이며, 반드시 개발자의 워크스테이션은 아닙니다.

최종 애플리케이션의 런타임 환경도 의도적으로 유지하십시오. 빌드 시점의 접근과 애플리케이션이 나중에 실행될 때 쓰는 경로는 별개의 구성 결정입니다.

관련 글