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 ને કોઈએ વર્ષ સુધી સમીક્ષા ન કરી તે જાહેર અંતિમ બિંદુ છે જેનો કોઈ માલિક નથી.