Uma ferramenta de compilação consegue resolver as suas dependências, mas um buildpack Paketo não consegue transferir um runtime. O buildpack é executado dentro do contentor do builder e precisa da sua própria entrada de proxy.

A tarefa bootBuildImage do Gradle

Num build.gradle Groovy com a tarefa bootBuildImage existente do Spring Boot:

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

O plugin Maven usa image.env

Para spring-boot:build-image, coloque estes valores em image.env na configuração existente do plugin 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>

Tanto o ambiente da tarefa Gradle como o image.env do Maven fornecem valores ao builder. Ambos os nomes podem identificar o mesmo intermediário HTTP comum, incluindo para URL de artefactos HTTPS. Para transferências públicas de artefactos permitidas através de proxies públicos, a lista de proxies HTTP fornece candidatos para estes valores do builder.

Esta definição é independente das propriedades systemProp.http.proxyHost do Gradle. Essas pertencem à JVM e não configuram automaticamente outro processo dentro do builder.

O daemon Docker tem primeiro de obter as imagens de builder e de execução necessárias. Uma falha de registo nessa fase anterior exige a rota e a configuração de registo do daemon, não uma variável entregue a um buildpack que ainda não arrancou.

Use um ponto final de proxy acessível a partir do contentor do builder. O seu endereço de loopback identifica esse contentor, não necessariamente a estação de trabalho do programador.

Mantenha também deliberado o ambiente de execução da aplicação final. O acesso durante a compilação e a rota usada quando a aplicação corre mais tarde são decisões de configuração separadas.

Artigos relacionados