GitHub वेबहुक निजी Jenkins तक नहीं पहुँचता: रास्ता ठीक करें

आप VPN के ज़रिये Jenkins खोल सकते हैं और फिर भी GitHub को विफल वेबहुक की रिपोर्ट करते देख सकते हैं, क्योंकि ये दो अलग कनेक्शन हैं जिनके दो अलग मालिक हैं। ब्राउज़र उस सुरंग से गुज़रता है जिस पर आपके लैपटॉप ने बातचीत की; GitHub की डिलीवरी सेवा सार्वजनिक इंटरनेट से शुरू होती है और निजी नेटवर्क में उसका कोई रास्ता नहीं है। रिपॉज़िटरी तक पहुँच इसे नहीं बदलती, भले ही Jenkins खुद उसी रिपॉज़िटरी से बिना परेशानी ले सके। कोई इनग्रेस, रिले या पोलिंग चुनें, फिर वह रास्ता जाँचें जो घटना वास्तव में लेती है।

ब्राउज़र सत्र केवल एक दिशा साबित करता है

VPN कनेक्शन एक सवाल का जवाब देता है: क्या यह लैपटॉप आंतरिक होस्ट तक पहुँच सकता है। वेबहुक डिलीवरी दूसरा सवाल पूछती है: क्या कोई बाहरी सेवा उस होस्ट से कनेक्शन खोल सकती है। Jenkins का रिपॉज़िटरी लेना आउटबाउंड ट्रैफ़िक है और इनबाउंड पहुँच के बारे में कुछ नहीं कहता। अपने आरेख में दोनों दिशाएँ अलग पंक्तियों पर रखें, यह भी कि कौन-सा पक्ष हर एक शुरू करता है।

कुछ भी बदलने से पहले डिलीवरी रिकॉर्ड पढ़ें। टाइमआउट, कनेक्शन रीसेट और स्वीकार किया गया वह अनुरोध जो किसी जॉब से मेल नहीं खाया, इनके तीन अलग मालिक हैं: नेटवर्क, प्रॉक्सी और ट्रिगर कॉन्फ़िगरेशन।

विकल्प A: संकरा एंडपॉइंट खोलें

अगर संगठन पहले से मंज़ूर किया गया इनग्रेस प्रकाशित करता है, तो डैशबोर्ड की जगह वेबहुक का रास्ता खोलें। आम तौर पर इसका मतलब है एक रिवर्स प्रॉक्सी नियम जो हुक URL पर POST स्वीकार करता है और उन्हें Jenkins तक भेजता है, जबकि प्रशासनिक इंटरफ़ेस बाहर से अगम्य रहता है।

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

यह परीक्षण VPN पहुँच के बिना किसी नेटवर्क से चलाएँ, क्योंकि सुरंग के भीतर से सफलता कुछ साबित नहीं करती। एंडपॉइंट को साझा रहस्य के बिना अनुरोध अस्वीकार करने चाहिए, जिसे GitHub हस्ताक्षर हेडर के रूप में भेजता है, और केवल वही एक रास्ता और विधि स्वीकार करनी चाहिए जो आपने प्रकाशित की। सार्वजनिक Jenkins कंसोल वेबहुक का समाधान नहीं है; यह अगले स्कैनर का इंतज़ार करती एक घटना है। नियम को इतना सीमित रखें कि बाकी एप्लिकेशन अपने पहले के पहुँच नियंत्रण बनाए रखे।

विकल्प B: रिले से दिशा उलटें

जहाँ इनबाउंड खुलासा मंज़ूर नहीं होगा, वहाँ नेटवर्क के भीतर एक छोटा क्लाइंट रिले तक आउटबाउंड कनेक्शन बनाए रख सकता है और भेजी गई घटनाएँ प्राप्त कर सकता है। तब रिले डिलीवरी रास्ते का हिस्सा बन जाता है, इसलिए उसकी उपलब्धता और प्रमाणीकरण बिल्ड जॉब जितने ही महत्वपूर्ण हैं।

ssh -N -R 9000:localhost:8080 relay.example.net

फ़ायरवॉल के पीछे वेबहुक पर Jenkins का मार्गदर्शन इस आकार का वर्णन करता है, और अपना खुद का फ़ॉरवर्डर लिखने से पहले इसे पढ़ना उचित है। रिले पर TLS समाप्त करें, घटना के जॉब तक पहुँचने से पहले हस्ताक्षर सत्यापित करें, और आउटबाउंड लिंक की निगरानी करें, क्योंकि टूटी सुरंग बिल्कुल वैसी ही दिखती है जैसी कभी न भेजी गई घटना। यह भी पुष्टि करें कि रिले अनुरोध का मुख्य भाग बाइट दर बाइट सुरक्षित रखता है, क्योंकि रास्ते में पार्स और फिर से एन्कोड किए गए JSON पर हस्ताक्षर जाँच विफल होती है।

विकल्प C: इसके बजाय रिपॉज़िटरी पोल करें

पोलिंग विलंब को सरलता से बदलती है और उसे इनबाउंड रास्ते की ज़रूरत ही नहीं। Jenkins अनुसूची के अनुसार पोल कर सकता है, या एक छोटा जॉब API से पूछ सकता है और अनजानी रिवीज़न देखकर बिल्ड शुरू कर सकता है।

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

हर पोल API कॉल खर्च करती है और push तथा बिल्ड के बीच देरी जोड़ती है, जो व्यस्त रिपॉज़िटरी और साझा दर सीमाओं पर दिखती है। इसे वहाँ संग्रहीत क्रेडेंशियल भी चाहिए जहाँ पोलर चलता है, इसलिए टोकन को केवल पढ़ने की रिपॉज़िटरी पहुँच तक सीमित करें और किसी भी अन्य रहस्य की तरह उसे बदलते रहें। इसे तब चुनें जब घटना की मात्रा कम हो या जब कोई इनग्रेस कभी मंज़ूर न हो, और जॉब विवरण में यह लिखें ताकि बाद में किसी को आश्चर्य न हो कि बिल्ड क्यों पिछड़ रहे हैं।

असली डिलीवरी स्वीकारें, पेज लोड नहीं

आपने कोई भी विकल्प चुना हो, स्वीकृति परीक्षण स्रोत प्लेटफ़ॉर्म द्वारा भेजी गई घटना है, विशेषाधिकार प्राप्त लैपटॉप से खोला गया ब्राउज़र टैब नहीं। स्क्रैच ब्रांच पर खाली commit push करें और डिलीवरी प्रतिक्रिया कोड, रिले लॉग या पोलिंग जॉब का आउटपुट इसी क्रम में पढ़ें। एंडपॉइंट से 200 और बिल्ड न होना बताता है कि ट्रिगर फ़िल्टर ग़लत है; टाइमआउट बताता है कि रास्ता अब भी बंद है। दर्ज करें कि तीन डिज़ाइनों में से कौन-सा इस्तेमाल हो रहा है, वरना अगला डिबग करने वाला ब्राउज़र परीक्षण दोहराएगा और उसी बंद गली में पहुँचेगा।

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