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 என்பது யாருக்கும் சொந்தமில்லாத பொது இறுதிப் புள்ளி.