ឧបករណ៍សាងសង់អាចដោះស្រាយភាពអាស្រ័យរបស់វាបានដោយជោគជ័យ ខណៈពេលដែល buildpack របស់ Paketo មិនអាចទាញយក runtime បានទេ។ 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 ធម្មតាដូចគ្នា រួមទាំងសម្រាប់ URL អាតេហ្វាក់ HTTPS។ សម្រាប់ការទាញយកអាតេហ្វាក់សាធារណៈដែលត្រូវបានអនុញ្ញាតតាមរយៈប្រូកស៊ីសាធារណៈ បញ្ជីប្រូកស៊ី HTTP ផ្តល់បេក្ខជនសម្រាប់តម្លៃ builder ទាំងនេះ។

ការកំណត់នេះឯករាជ្យពីលក្ខណៈសម្បត្តិ systemProp.http.proxyHost របស់ Gradle។ ពួកវាជាកម្មសិទ្ធិរបស់ JVM ហើយមិនកំណត់ដោយស្វ័យប្រវត្តិនូវដំណើរការផ្សេងទៀតនៅក្នុង builder ទេ។

Docker daemon ត្រូវទទួលបានរូបភាព builder និងដំណើរការដែលត្រូវការជាមុន។ ការបរាជ័យរបស់បញ្ជីឈ្មោះនៅដំណាក់កាលមុននោះត្រូវការ ផ្លូវ និងការកំណត់បញ្ជីឈ្មោះរបស់ daemon មិនមែនអថេរដែលផ្តល់ទៅ buildpack ដែលមិនទាន់ចាប់ផ្តើមនោះទេ។

ប្រើចំណុចបញ្ចប់ប្រូកស៊ីដែលអាចទាក់ទងបានពីធុងរបស់ builder។ អាសយដ្ឋាន loopback របស់វាកំណត់អត្តសញ្ញាណធុងនោះ មិនចាំបាច់ជាស្ថានីយការងាររបស់អ្នកអភិវឌ្ឍន៍ទេ។

រក្សាបរិស្ថានដំណើរការរបស់កម្មវិធីចុងក្រោយឱ្យមានចេតនាផងដែរ។ ការចូលប្រើពេលសាងសង់ និងផ្លូវដែលប្រើនៅពេលកម្មវិធីដំណើរការពេលក្រោយ គឺជាការសម្រេចចិត្តកំណត់រចនាសម្ព័ន្ធដាច់ដោយឡែក។

អត្ថបទពាក់ព័ន្ធ