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 સત્ર હોય ત્યારે પણ. ડિલિવરી માર્ગ એપ્લિકેશનની ડિઝાઇનનો ભાગ છે, નેટવર્કિંગ પાદટીપનો નહીં.