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 हा कोणाच्याही मालकीचा नसलेला सार्वजनिक अंतिम बिंदू आहे.