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 அமர்வைக் கொண்டிருந்தாலும் ஒவ்வொன்றுக்கும் தனியார் பயன்பாட்டுக்குள் அதன் சொந்தப் பாதை தேவை. விநியோகப் பாதை பயன்பாட்டின் வடிவமைப்புக்கு உரியது, வலையமைப்பு பற்றிய அடிக்குறிப்புக்கு அல்ல.