Imágenes de Spring Boot: configurar el proxy del builder de Paketo

Pasa variables de proxy a un builder de Paketo mediante Gradle bootBuildImage o Maven image.env, por separado de la herramienta de compilación y del demonio de Docker.

Una herramienta de compilación puede resolver sus dependencias correctamente mientras un buildpack de Paketo no puede descargar un entorno de ejecución. El buildpack se ejecuta dentro del contenedor del builder y necesita su propia entrada de proxy.

La tarea bootBuildImage de Gradle

En un build.gradle de Groovy con la tarea bootBuildImage existente de Spring Boot:

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

El plugin de Maven usa image.env

Para spring-boot:build-image, coloca estos valores bajo image.env en la configuración existente del 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 el entorno de la tarea de Gradle como image.env de Maven proporcionan valores al builder. Ambos nombres pueden identificar el mismo intermediario HTTP ordinario, también para URL de artefactos HTTPS. Para descargas públicas de artefactos permitidas a través de proxies públicos, la lista de proxies HTTP ofrece candidatos para estos valores del builder.

Este ajuste es independiente de las propiedades systemProp.http.proxyHost de Gradle. Esas pertenecen a la JVM y no configuran automáticamente otro proceso dentro del builder.

El demonio de Docker primero debe obtener las imágenes de builder y de ejecución necesarias. Un fallo de registro en esa etapa anterior requiere la ruta y la configuración de registro del demonio, no una variable entregada a un buildpack que aún no ha comenzado.

Usa un punto de conexión de proxy accesible desde el contenedor del builder. Su dirección de loopback identifica ese contenedor, no necesariamente el puesto de trabajo del desarrollador.

Mantén también deliberado el entorno de ejecución de la aplicación final. El acceso durante la compilación y la ruta que se usa cuando la aplicación se ejecuta después son decisiones de configuración separadas.

Artículos relacionados