Kvifor GitHub-webhooks går ut på tid mot ein Jenkins bak ein VPN
GitHub sender webhooks innover, så ein VPN som vernar Jenkins avviser dei. Send leveringa utover via ein relay, eller byt ut webhooken med ein agent som spør.
Leveringssida viser tidsavbrot og Jenkins loggar ingenting, som er signaturen på ei tilkopling som aldri kom fram. GitHub sender ein webhook som ein utgåande HTTP POST frå sin eigen infrastruktur til payload-URL-en du sette opp. Ein VPN vernar Jenkins ved å avvise nettopp den typen tilkopling. Ingenting er øydelagt på nokon av sidene. Problemet er retninga på førespurnaden.
Kva leveringa faktisk prøver på
GitHub slår opp vertsnamnet i payload-URL-en og koplar til det frå det opne internettet. Viss den URL-en peikar på ei privat adresse, eller på eit namn som berre blir slått opp inne i nettverket ditt, feilar forsøket før nokon førespurnad blir send. Viss han peikar på eit offentleg namn som kanten din droppar, går forsøket ut på tid i staden.
Skilnaden har noko å seie for diagnostikken. Ein DNS-feil og ein filtrert port ser begge ut som om ingenting skjedde på Jenkins-sida, og begge viser i GitHub som ei mislukka levering med ein annan grunn vedlagd. Les den grunnen før du endrar URL-en.
Ein tunnel som ringjer utover lagar ikkje ein lyttar. Det er den delen folk ventar fungerer annleis.
Tre måtar å rette retninga på tilkoplinga
Kvar løysing endrar kven som startar tilkoplinga, og det finst berre tre former.
| 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 |
Spørjing er det minst elegante og det enklaste å drifte. Ein relay held nesten umiddelbar tilbakemelding utan å opne ein port. Ein runner er vanlegvis det rette svaret når payload-konfidensialitet stengjer ute ein tredjepart, fordi jobben kan køyre på ein maskin som allereie står inne i nettverket.
Vel etter kva du kan drifte, ikkje etter kva som høyrest moderne ut.
Send ei levering utover med smee
Opprett ein kanal på relay-tenesta og ta vare på URL-en. Inne i nettverket installerer du klienten og videresender leveringar til stigen Jenkins ventar. Payload-URL-en i repooppsettet blir kanalens URL, med innhaldstypen sett til application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tre detaljar avgjer om det verkar. Stigen må samsvare med det Jenkins ventar for GitHub-hendingar, som som standard er /github-webhook/. Jenkins må lytte på porten du gav klienten. Og Jenkins-URL-en som er sett opp i jobben må stemme med den stigen, elles kjem hendinga inn og blir deretter kasta.
Uoverensstemm med skråstreken på slutten gjev ein 404 som blir lesen som ei mislukka levering og ikkje er det.
Køyre det slik at det overlever veka
Ein klient i forgrunnen døyr med terminalen, og webhooks fungerer ein dag og stoppar så. Gje han ein unit med Restart=always, køyr han som Jenkins-brukaren, og les journalen etter den første verkelege leveringa. Det siste steget er det som skil ein fungerande relay frå ein oppsett.
[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.targetTest med ein ekte push i staden for ein replay-knapp. Ein replay øver på den lagra payloaden til relayen, ikkje vegen frå GitHub til kanalen din, så han kan gå gjennom medan direktesendinga framleis feilar.
Varsle når uniten stoppar. Ein relay som er nede er stille av konstruksjon, og stilla er nettopp det du allereie feilsøkjer.
Kva relayen kan sjå, og når du ikkje bør bruke ein
Ein relay terminerer payloaden, så han ser reponamn, commit-data og alt anna hendinga ber. Handsame kanalens URL som eit offentleg endepunkt. Hald Jenkins’ hemmelege token sett opp slik at forfalska leveringar blir avviste, og avgrens tokenet Jenkins brukar til det naudsynte minimumet.
Viss payload-konfidensialitet stengjer ute det, er ein sjølvhosta runner eller ein autentisert revers-tunnel svaret.
Ein relay er infrastruktur no, og han fortener same gjennomgang som bygget han utløyser. Roter kanalen viss han lekk, og noter datoen du sist verifiserte ei direktesending. Set den datoen i runbooken ved sida av kanalens URL. Ein relay ingen har gått gjennom på eitt år er eit offentleg endepunkt ingen eig.