Terraform प्रॉक्सी विफलताएँ: डाउनलोड, प्रदाता और रिमोट रन
Terraform रजिस्ट्री डाउनलोड, Git मॉड्यूल फ़ेच, प्रदाता API कॉल और रिमोट निष्पादन में अंतर करें जब प्रॉक्सी रन के केवल एक हिस्से के लिए काम करता है।
प्रदाता का डाउनलोड सफल होना बाद के क्लाउड API कॉल के बारे में बहुत कम कहता है। पहले विफल होने वाले होस्टनाम और ऑपरेशन से शुरू करें, फिर उनका स्वामी पहचानें:
| ऑपरेशन | यह मार्ग अपनाएँ |
|---|---|
| रजिस्ट्री लुकअप या इंस्टॉलेशन डाउनलोड | Terraform प्रक्रिया, इंस्टॉलेशन स्रोत और प्रॉक्सी वातावरण |
| Git-आधारित मॉड्यूल फ़ेच | स्रोत URL और Git ट्रांसपोर्ट; SSH और HTTPS अलग-अलग सेटिंग्स का उपयोग करते हैं |
| क्लाउड API कॉल | प्रदाता प्लगइन और उसके SDK का रूटिंग और ट्रस्ट कॉन्फ़िगरेशन |
| रिमोट निष्पादन | रनर का वातावरण और नेटवर्क, लैपटॉप का नहीं |
CONNECT का समर्थन करने वाले HTTP प्रॉक्सी के लिए, यह वातावरण मान HTTPS गंतव्यों के लिए इसे सही ढंग से चुन सकता है:
HTTPS_PROXY=http://proxy.example:3128चर गंतव्य की स्कीम का नाम बताता है; मान प्रॉक्सी के ट्रांसपोर्ट का नाम बताता है। https:// का उपयोग केवल तब करें जब लिसनर TLS प्रदान करे और अनुरोध करने वाला क्लाइंट उसका समर्थन करे। प्रदाता अलग प्लगइन हैं और SDK-विशिष्ट सेटिंग्स का उपयोग कर सकते हैं, इसलिए यह मान हर प्रदाता के बारे में वादा नहीं है।
पहचाने गए स्वामी के पास, सेटिंग बदलने से पहले त्रुटि की परत अलग करें: अस्वीकृत प्रॉक्सी कनेक्शन, प्रॉक्सी 407, अस्वीकृत CONNECT, प्रमाणपत्र त्रुटि और क्लाउड API 403 प्रत्येक अगली जाँच को अलग तरह से सीमित करते हैं। चरण, गंतव्य, निष्पादन वातावरण और पहली त्रुटि साथ रखें।
समर्थित सेटिंग को उस घटक पर लागू करें। लैपटॉप पर निर्यात रिमोट रनर को कॉन्फ़िगर नहीं करता, और प्रॉक्सी क्रेडेंशियल रजिस्ट्री या क्लाउड API के सामने प्रमाणित नहीं करते।