Інструмент зборкі можа паспяхова развязаць свае залежнасці, але buildpack Paketo не здольны спампаваць асяроддзе выканання. Buildpack працуе ўнутры кантэйнера зборшчыка і патрабуе ўласных даных проксі.

Заданне bootBuildImage у Gradle

У Groovy-файле build.gradle з існуючым заданнем bootBuildImage ад Spring Boot:

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

Плагін Maven выкарыстоўвае image.env

Для spring-boot:build-image змясціце гэтыя значэнні ў image.env у існуючай канфігурацыі плагіна 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>

Асяроддзе задання Gradle і image.env у Maven абодва перадаюць значэнні зборшчыку. Абедзве назвы могуць пазначаць адзін і той жа звычайны HTTP-пасрэднік, у тым ліку для URL артэфактаў HTTPS. Для публічных спамповак артэфактаў, дазволеных праз публічныя проксі, спіс HTTP-проксі дае кандыдатаў для гэтых значэнняў зборшчыка.

Гэта налада не залежыць ад уласцівасцей systemProp.http.proxyHost у Gradle. Яны належаць JVM і не наладжваюць аўтаматычна іншы працэс у зборшчыку.

Дэман Docker спачатку павінен атрымаць патрэбныя вобразы зборшчыка і запуску. Збой рэестра на гэтай ранейшай стадыі патрабуе маршруту і канфігурацыі рэестра дэмана, а не зменнай, перададзенай buildpack, які яшчэ не запусціўся.

Выкарыстоўвайце канечную кропку проксі, дасяжную з кантэйнера зборшчыка. Яе адрас зваротнай сувязі вызначае гэты кантэйнер, а не абавязкова працоўную станцыю распрацоўшчыка.

Трымайце асяроддзе выканання канчатковай праграмы таксама свядомым. Доступ падчас зборкі і маршрут, які выкарыстоўваецца пры наступным запуску праграмы, — гэта асобныя рашэнні канфігурацыі.

Падобныя артыкулы