ビルドツールが依存関係を解決できても、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 デーモンはまず必要なビルダーイメージと実行イメージを取得しなければならない。その前段階でのレジストリ障害には、デーモンの経路とレジストリ設定が必要であり、まだ起動していないビルドパックに渡す変数では対処できない。

ビルダーコンテナから到達できるプロキシエンドポイントを使う。そのループバックアドレスが指すのはそのコンテナであり、開発者のワークステーションとは限らない。

最終アプリケーションの実行環境も意図的に保つ。ビルド時のアクセスと、アプリケーションが後で実行されるときに使う経路は別々の設定判断である。

関連記事