GitHub वेबहूक खाजगी Jenkins पर्यंत पोहोचत नाही: मार्ग दुरुस्त करा
तुमच्या लॅपटॉपवरील VPN सत्र 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 सत्र असले तरी प्रत्येकाला खाजगी अनुप्रयोगात स्वतःचा मार्ग हवा. डिलिव्हरी मार्ग अनुप्रयोगाच्या रचनेचा भाग आहे, नेटवर्किंग तळटीपेचा नाही.