Инструментът за изграждане може успешно да разреши зависимостите си, докато buildpack на Paketo не може да изтегли среда за изпълнение. Buildpack работи вътре в контейнера на builder и се нуждае от собствен прокси вход.

Задачата bootBuildImage на Gradle

В Groovy build.gradle със съществуващата задача bootBuildImage на Spring Boot:

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

Maven плъгинът използва image.env

За spring-boot:build-image поставете тези стойности под image.env в съществуващата конфигурация на 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>

Средата на задачата на Gradle и image.env на Maven и двете подават стойности на builder. И двете имена могат да обозначават един и същ обикновен HTTP посредник, включително за HTTPS URL адреси на артефакти. За публични изтегляния на артефакти, разрешени през публични прокси сървъри, списъкът с HTTP прокси сървъри предоставя кандидати за тези стойности на builder.

Тази настройка е независима от свойствата systemProp.http.proxyHost на Gradle. Те принадлежат на JVM и не конфигурират автоматично друг процес в builder.

Демонът на Docker първо трябва да получи необходимите образи за builder и за изпълнение. Провал на регистъра в този по-ранен етап изисква маршрута и конфигурацията на регистъра на демона, а не променлива, подадена на buildpack, който още не е стартирал.

Използвайте прокси крайна точка, достъпна от контейнера на builder. Неговият loopback адрес идентифицира този контейнер, а не непременно работната станция на разработчика.

Пазете съзнателно и средата за изпълнение на крайното приложение. Достъпът по време на изграждане и маршрутът при по-късното изпълнение на приложението са отделни конфигурационни решения.

Подобни статии