Spring Boot იმიჯების აწყობა: Paketo builder-ის პროქსის კონფიგურაცია

build-ის ხელსაწყოს შეუძლია თავისი დამოკიდებულებების წარმატებით გადაწყვეტა, მაშინ როცა Paketo buildpack-ს არ შეუძლია runtime-ის ჩამოტვირთვა. buildpack მუშაობს builder-ის კონტეინერის შიგნით და საჭიროებს საკუთარ პროქსის შეყვანას.

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-ის დანამატი იყენებს 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-ის ამოცანის გარემო, ისე Maven-ის image.env აძლევს მნიშვნელობებს builder-ს. ორივე სახელწოდება შეიძლება აღნიშნავდეს ერთსა და იმავე ჩვეულებრივ HTTP შუამავალს, HTTPS არტეფაქტების URL-ებისთვისაც. საჯარო პროქსების მეშვეობით დაშვებული საჯარო არტეფაქტების ჩამოტვირთვისთვის HTTP პროქსების სია გთავაზობთ კანდიდატებს ამ builder-ის მნიშვნელობებისთვის.

ეს პარამეტრი დამოუკიდებელია Gradle-ის systemProp.http.proxyHost თვისებებისგან. ისინი JVM-ს ეკუთვნის და ავტომატურად არ აკონფიგურირებენ სხვა პროცესს builder-ში.

Docker-ის დემონმა ჯერ უნდა მიიღოს საჭირო builder-ისა და გაშვების იმიჯები. რეესტრის ჩავარდნა იმ უფრო ადრეულ ეტაპზე მოითხოვს დემონის მარშრუტსა და რეესტრის კონფიგურაციას, და არა ცვლადს, რომელიც ჯერ არგაშვებულ buildpack-ს გადაეცემა.

გამოიყენეთ პროქსის ბოლო წერტილი, რომელიც ხელმისაწვდომია builder-ის კონტეინერიდან. მისი loopback მისამართი განსაზღვრავს სწორედ იმ კონტეინერს, და არა აუცილებლად დეველოპერის სამუშაო სადგურს.

საბოლოო აპლიკაციის გაშვების გარემოც გააზრებულად შეინახეთ. build-ის დროის წვდომა და მარშრუტი, რომელიც აპლიკაციის შემდგომი მუშაობისას გამოიყენება, ცალკეული კონფიგურაციის გადაწყვეტილებებია.