Images Spring Boot : configurer le proxy du builder Paketo

Transmettez des variables de proxy à un builder Paketo via Gradle bootBuildImage ou Maven image.env, indépendamment de l'outil de build et du démon Docker.

Un outil de build peut résoudre ses dépendances, tandis qu'un buildpack Paketo ne parvient pas à télécharger un runtime. Le buildpack s'exécute dans le conteneur du builder et a besoin de sa propre entrée proxy.

La tâche bootBuildImage de Gradle

Dans un build.gradle Groovy utilisant la tâche bootBuildImage existante de Spring Boot :

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

Le plugin Maven utilise image.env

Pour spring-boot:build-image, placez ces valeurs sous image.env dans la configuration existante du 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>

L'environnement de la tâche Gradle et image.env de Maven fournissent tous deux des valeurs au builder. Les deux noms peuvent désigner le même intermédiaire HTTP ordinaire, y compris pour les URL d'artefacts HTTPS. Pour les téléchargements publics d'artefacts autorisés via des proxys publics, la liste de proxys HTTP fournit des candidats pour ces valeurs du builder.

Ce réglage est indépendant des propriétés systemProp.http.proxyHost de Gradle. Celles-ci appartiennent à la JVM et ne configurent pas automatiquement un autre processus dans le builder.

Le démon Docker doit d'abord obtenir les images de builder et d'exécution requises. Un échec de registre à cette étape antérieure nécessite la route et la configuration de registre du démon, et non une variable fournie à un buildpack qui n'a pas encore démarré.

Utilisez un point de terminaison proxy accessible depuis le conteneur du builder. Son adresse de bouclage identifie ce conteneur, pas nécessairement le poste de travail du développeur.

Gardez également l'environnement d'exécution de l'application finale réfléchi. L'accès au moment du build et la route utilisée lorsque l'application s'exécute ensuite sont des décisions de configuration distinctes.

Articles similaires