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 ఎవరికీ సొంతం కాని పబ్లిక్ చివరి బిందువు.