Կառուցման գործիքը կարող է հաջողությամբ լուծել իր կախվածությունները, մինչդեռ Paketo buildpack-ը չի կարող ներբեռնել գործարկման միջավայր։ Buildpack-ը աշխատում է builder-ի կոնտեյների ներսում և կարիք ունի իր սեփական proxy մուտքագրմանը։

Gradle-ի bootBuildImage խնդիրը

Groovy build.gradle-ում Spring Boot-ի առկա bootBuildImage խնդրով՝

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

Maven-ի plug-in-ը օգտագործում է image.env

spring-boot:build-image-ի համար տեղադրեք այս արժեքները image.env-ի տակ՝ Spring Boot Maven plug-in-ի առկա կարգավորման մեջ՝

<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-ները։ Հանրային proxy-ների միջոցով թույլատրված հանրային արտեֆակտների ներբեռնումների համար HTTP proxy-ների ցանկը առաջարկում է թեկնածուներ այս builder արժեքների համար։

Այս կարգավորումը անկախ է Gradle-ի systemProp.http.proxyHost հատկություններից։ Դրանք պատկանում են JVM-ին և ինքնաշխատ չեն կարգավորում builder-ի մեկ այլ գործընթաց։

Docker դեմոնը նախ պետք է ստանա անհրաժեշտ builder-ի և գործարկման պատկերները։ Այդ ավելի վաղ փուլում ռեեստրի ձախողումը պահանջում է դեմոնի երթուղին և ռեեստրի կարգավորումը, այլ ոչ թե փոփոխական, որը տրվում է դեռ չմեկնարկած buildpack-ին։

Օգտագործեք proxy-ի վերջնակետ, որը հասանելի է builder-ի կոնտեյներից։ Դրա loopback հասցեն նույնականացնում է այդ կոնտեյները, ոչ պարտադիր մշակողի աշխատանքային կայանը։

Վերջնական հավելվածի գործարկման միջավայրը նույնպես պահեք դիտավորյալ։ Կառուցման ժամանակ հասանելիությունը և այն երթուղին, որն օգտագործվում է հավելվածի հետագա աշխատանքի ընթացքում, առանձին կարգավորման որոշումներ են։

Առնչվող հոդվածներ