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 डेमॉन को पहले ज़रूरी बिल्डर और रन इमेज प्राप्त करनी होती हैं। उस पहले चरण में रजिस्ट्री विफलता के लिए डेमॉन का मार्ग और रजिस्ट्री कॉन्फ़िगरेशन चाहिए, न कि ऐसा चर जो ऐसे बिल्डपैक को दिया जाए जो अभी शुरू ही नहीं हुआ।

बिल्डर कंटेनर से पहुँचने योग्य प्रॉक्सी एंडपॉइंट इस्तेमाल करें। उसका लूपबैक पता उसी कंटेनर की पहचान करता है, ज़रूरी नहीं कि डेवलपर का वर्कस्टेशन।

अंतिम एप्लिकेशन के रनटाइम एनवायरनमेंट को भी सोच-समझकर रखें। बिल्ड के समय की पहुँच और एप्लिकेशन के बाद में चलने पर इस्तेमाल होने वाला मार्ग दो अलग कॉन्फ़िगरेशन निर्णय हैं।

संबंधित लेख