Spring Boot इमेज बिल्ड: Paketo बिल्डरको प्रोक्सी कन्फिगर गर्नुहोस्

Gradle bootBuildImage वा Maven image.env मार्फत Paketo बिल्डरमा प्रोक्सी चलहरू पठाउनुहोस्, बिल्ड उपकरण र Docker डेमनबाट अलग।

बिल्ड उपकरणले आफ्ना निर्भरताहरू सफलतापूर्वक समाधान गर्न सक्छ, तर Paketo बिल्डप्याकले रनटाइम डाउनलोड गर्न सक्दैन। बिल्डप्याक बिल्डर कन्टेनरभित्र चल्छ र यसलाई आफ्नै प्रोक्सी इनपुट चाहिन्छ।

Gradle को bootBuildImage कार्य

Spring Boot को विद्यमान bootBuildImage कार्य भएको Groovy build.gradle मा:

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

Maven प्लगइनले image.env प्रयोग गर्छ

spring-boot:build-image का लागि, यी मानहरू विद्यमान Spring Boot Maven प्लगइन कन्फिगरेसनको image.env मुनि राख्नुहोस्:

<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 दुवैले बिल्डरलाई मान दिन्छन्। दुवै नामले एउटै सामान्य HTTP मध्यस्थलाई जनाउन सक्छन्, HTTPS आर्टिफ्याक्ट URL का लागि पनि। सार्वजनिक प्रोक्सीमार्फत अनुमति दिइएका सार्वजनिक आर्टिफ्याक्ट डाउनलोडका लागि HTTP प्रोक्सी सूची ले यी बिल्डर मानहरूका लागि उम्मेदवार दिन्छ।

यो सेटिङ Gradle का systemProp.http.proxyHost गुणहरूबाट स्वतन्त्र छ। ती JVM का हुन् र बिल्डरभित्रको अर्को प्रक्रियालाई स्वतः कन्फिगर गर्दैनन्।

Docker डेमनले पहिले आवश्यक बिल्डर र रन इमेजहरू प्राप्त गर्नुपर्छ। त्यो अघिल्लो चरणमा रजिस्ट्री असफल भएमा डेमनको मार्ग र रजिस्ट्री कन्फिगरेसन चाहिन्छ, अझै नसुरु भएको बिल्डप्याकलाई दिइएको चल होइन।

बिल्डर कन्टेनरबाट पुग्न सकिने प्रोक्सी इन्डपोइन्ट प्रयोग गर्नुहोस्। यसको लूपब्याक ठेगानाले त्यही कन्टेनर चिनिन्छ, जरुरी छैन विकासकर्ताको वर्कस्टेसन।

अन्तिम एप्लिकेसनको रनटाइम वातावरण पनि जानाजान राख्नुहोस्। बिल्डका बेलाको पहुँच र एप्लिकेसन पछि चल्दा प्रयोग हुने मार्ग दुई फरक कन्फिगरेसन निर्णय हुन्।

सम्बन्धित लेखहरू