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