VPN पछाडिको Jenkins विरुद्ध GitHub webhook किन समय सकिन्छ
GitHub webhook हरू भित्रतिर पठाउँछ, त्यसैले Jenkins जोगाउने VPN ले तिनीहरूलाई अस्वीकार गर्छ। डेलिभरी relay मार्फत बाहिर पठाउनुहोस्, वा webhook लाई पोलिङ गर्ने agent ले बदल्नुहोस्।
डेलिभरी पृष्ठले समय सकिएको देखाउँछ र Jenkins ले केही पनि लग गर्दैन, जुन कहिल्यै नआएको जडानको संकेत हो। GitHub आफ्नै पूर्वाधारबाट तपाईंले कन्फिगर गरेको payload URL मा बाहिर जाने HTTP POST को रूपमा webhook पठाउँछ। VPN ले ठ्याक्कै त्यस्तै प्रकारको जडान अस्वीकार गरेर Jenkins जोगाउँछ। दुवै तर्फ केही पनि बिग्रिएको छैन। समस्या अनुरोधको दिशामा छ।
डेलिभरीले वास्तवमा के प्रयास गर्छ
GitHub ले payload URL मा भएको होस्टनाम समाधान गर्छ र सार्वजनिक इन्टरनेटबाट त्यसमा जोडिन्छ। यदि त्यो URL निजी ठेगानामा, वा तपाईंको नेटवर्कभित्र मात्र समाधान हुने नाममा संकेत गर्छ भने, कुनै पनि अनुरोध पठाउनु अघि नै प्रयास असफल हुन्छ। यदि त्यो तपाईंको एजले फाल्ने सार्वजनिक नाममा संकेत गर्छ भने, प्रयास बरु समय सकिन्छ।
निदानका लागि यो भिन्नता महत्त्वपूर्ण छ। DNS असफलता र फिल्टर गरिएको पोर्ट दुवै Jenkins तर्फ केही भएन जस्तो देखिन्छन्, र दुवै GitHub मा फरक कारण संलग्न असफल डेलिभरीको रूपमा देखिन्छन्। URL परिवर्तन गर्नु अघि त्यो कारण पढ्नुहोस्।
बाहिरतिर डायल गर्ने सुरुङले श्रोता बनाउँदैन। मानिसहरूले फरक तरिकाले काम गर्ने अपेक्षा गर्ने भाग यही हो।
जडानको दिशा सुधार्ने तीन तरिका
हरेक समाधानले जडान कसले सुरु गर्छ भन्ने परिवर्तन गर्छ, र तीनवटा आकार मात्र छन्।
| Approach | Who initiates | What you give up |
|---|---|---|
| Relay service | An outbound client inside the network | A third party sees every payload |
| Reverse tunnel or ingress | The public edge, into a controlled listener | An inbound surface you must secure |
| Runner or polling | The agent, outbound to GitHub | Instant delivery, replaced by a schedule |
पोलिङ सबैभन्दा कम सुरुचिपूर्ण र चलाउन सबैभन्दा सजिलो हो। relay ले पोर्ट नखोली लगभग तत्काल प्रतिक्रिया राख्छ। payload को गोपनीयताले तेस्रो पक्षलाई बाहिर राख्दा runner सामान्यतया सही उत्तर हो, किनकि काम पहिले नै नेटवर्कभित्र रहेको मेसिनमा चल्न सक्छ।
तपाईंले चलाउन सक्ने आधारमा छान्नुहोस्, आधुनिक सुनिने आधारमा होइन।
smee प्रयोग गरेर डेलिभरी बाहिर पठाउनुहोस्
relay सेवामा च्यानल बनाउनुहोस् र त्यसको URL राख्नुहोस्। नेटवर्कभित्र, क्लाइन्ट स्थापना गर्नुहोस् र Jenkins ले अपेक्षा गर्ने मार्गमा डेलिभरी पठाउनुहोस्। रिपोजिटरी सेटिङमा भएको payload URL च्यानलको URL बन्छ, सामग्री प्रकार application/json मा सेट हुन्छ।
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080तीन विवरणले यो काम गर्छ कि गर्दैन भन्ने निर्धारण गर्छन्। मार्ग GitHub घटनाहरूका लागि Jenkins ले अपेक्षा गर्नेसँग मिल्नुपर्छ, जुन पूर्वनिर्धारित रूपमा /github-webhook/ हो। Jenkins ले तपाईंले क्लाइन्टलाई दिएको पोर्टमा सुन्नुपर्छ। र जागिरमा कन्फिगर गरिएको Jenkins URL त्यो मार्गसँग सहमत हुनुपर्छ, नत्र घटना आउँछ र त्यसपछि फालिन्छ।
अन्तमा स्ल्याश नमिल्दा 404 उत्पन्न हुन्छ, जुन डेलिभरी असफलता जस्तो पढिन्छ र त्यस्तो होइन।
हप्ता टिक्ने गरी यसलाई चलाउनु
फोरग्राउन्ड क्लाइन्ट टर्मिनलसँगै मर्छ, र webhook हरू एक दिन चल्छन् अनि रोकिन्छन्। यसलाई Restart=always भएको unit दिनुहोस्, Jenkins प्रयोगकर्ताको रूपमा चलाउनुहोस्, र पहिलो वास्तविक डेलिभरीपछि journal पढ्नुहोस्। त्यही अन्तिम चरणले काम गर्ने relay लाई कन्फिगर गरिएको relay बाट अलग गर्छ।
[Unit]
Description=smee webhook relay
After=network.target
[Service]
Type=simple
Restart=always
RestartSec=2
User=jenkins
ExecStart=/usr/bin/smee -u CHANNEL_URL --path /github-webhook/ --port 8080
[Install]
WantedBy=multi-user.targetरिप्ले बटनको सट्टा वास्तविक push सँग परीक्षण गर्नुहोस्। रिप्लेले relay को भण्डारित payload अभ्यास गर्छ, GitHub बाट तपाईंको च्यानलसम्मको मार्ग होइन, त्यसैले प्रत्यक्ष डेलिभरी अझै असफल हुँदा पनि यो पास हुन सक्छ।
unit रोकिँदा सचेत गर्नुहोस्। बन्द relay निर्माणबाटै मौन हुन्छ, र मौनता त्यही हो जुन तपाईं पहिले नै डिबग गर्दै हुनुहुन्छ।
relay ले के देख्न सक्छ, र कहिले यो प्रयोग नगर्ने
relay ले payload अन्त्य गर्छ, त्यसैले यसले रिपोजिटरीका नाम, commit डेटा र घटनाले बोकेको सबै देख्छ। च्यानलको URL लाई सार्वजनिक अन्तिम बिन्दु मान्नुहोस्। नक्कली डेलिभरी अस्वीकार होऊन् भनेर Jenkins को secret token कन्फिगर राख्नुहोस्, र Jenkins ले प्रयोग गर्ने token को दायरा आवश्यक न्यूनतममा सीमित गर्नुहोस्।
यदि payload को गोपनीयताले त्यो बाहिर राख्छ भने, स्वयं-होस्ट गरिएको runner वा प्रमाणित रिभर्स सुरुङ उत्तर हो।
relay अब पूर्वाधार हो, र यो ट्रिगर गर्ने build जत्तिकै समीक्षाको योग्य छ। च्यानल चुहियो भने यसलाई घुमाउनुहोस्, र प्रत्यक्ष डेलिभरी अन्तिम पटक कहिले प्रमाणित गर्नुभयो त्यो मिति नोट गर्नुहोस्। त्यो मिति च्यानलको URL नजिकै runbook मा राख्नुहोस्। वर्षभर कसैले समीक्षा नगरेको relay कसैको स्वामित्व नभएको सार्वजनिक अन्तिम बिन्दु हो।