构建工具能成功解析自身依赖,Paketo buildpack 却可能无法下载运行时。buildpack 运行在 builder 容器内部,需要自己的代理输入。

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 都会把值交给 builder。两个名称可以指向同一个普通 HTTP 中间人,HTTPS 制品 URL 也是如此。对于允许通过公共代理进行的公共制品下载,HTTP 代理列表可为这些 builder 值提供候选。

该设置独立于 Gradle 的 systemProp.http.proxyHost 属性。那些属性属于 JVM,不会自动配置 builder 内的另一个进程。

Docker 守护进程必须先取得所需的 builder 镜像和运行镜像。更早阶段的仓库故障需要守护进程的路由与仓库配置,而不是传给尚未启动的 buildpack 的变量。

使用从 builder 容器可访问的代理端点。它的回环地址标识的是那个容器,未必是开发者的工作站。

最终应用的运行环境也要有意识地保留。构建期的访问与应用之后运行时的路由是两项独立的配置决定。

相关文章