Hvorfor GitHub-webhooks timer ut mot en Jenkins bak en VPN
GitHub sender webhooks innover, så en VPN som beskytter Jenkins avviser dem. Send leveringen utover via en relay, eller bytt ut webhooken med en agent som poller.
Leveringssiden viser en timeout og Jenkins logger ingenting, som er signaturen på en tilkobling som aldri kom frem. GitHub sender en webhook som en utgående HTTP POST fra sin egen infrastruktur til payload-URL-en du konfigurerte. En VPN beskytter Jenkins ved å avvise nettopp den typen tilkobling. Ingenting er ødelagt på noen av sidene. Problemet er retningen på forespørselen.
Hva leveringen faktisk forsøker
GitHub slår opp vertsnavnet i payload-URL-en og kobler til det fra det offentlige internettet. Hvis den URL-en peker på en privat adresse, eller på et navn som bare slås opp inne i nettverket ditt, feiler forsøket før noen forespørsel sendes. Hvis den peker på et offentlig navn som kanten din dropper, timer forsøket ut i stedet.
Forskjellen betyr noe for diagnostikken. En DNS-feil og en filtrert port ser begge ut som om ingenting skjedde på Jenkins-siden, og begge vises i GitHub som en mislykket levering med en annen årsak vedlagt. Les den årsaken før du endrer URL-en.
En tunnel som ringer utover oppretter ikke en lytter. Det er den delen folk forventer fungerer annerledes.
Tre måter å rette retningen på tilkoblingen
Hver løsning endrer hvem som starter tilkoblingen, og det finnes bare 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 |
Polling er det minst elegante og det enkleste å drifte. En relay holder nesten umiddelbar tilbakemelding uten å åpne en port. En runner er vanligvis det riktige svaret når payload-konfidensialitet utelukker en tredjepart, fordi jobben kan kjøre på en maskin som allerede står inne i nettverket.
Velg etter hva du kan drifte, ikke etter hva som høres moderne ut.
Send en levering utover med smee
Opprett en kanal på relay-tjenesten og ta vare på URL-en. Inne i nettverket installerer du klienten og videresender leveringer til stien Jenkins forventer. Payload-URL-en i repooppsettet blir kanalens URL, med innholdstypen satt til application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tre detaljer avgjør om det virker. Stien må samsvare med det Jenkins forventer for GitHub-hendelser, som som standard er /github-webhook/. Jenkins må lytte på porten du ga klienten. Og Jenkins-URL-en som er konfigurert i jobben må stemme med den stien, ellers kommer hendelsen inn og blir deretter forkastet.
Uoverensstemmelse med skråstreken på slutten gir en 404 som leses som en mislykket levering og ikke er det.
Kjøre det slik at det overlever uken
En klient i forgrunnen dør med terminalen, og webhooks fungerer en dag og stopper så. Gi den en unit med Restart=always, kjør den som Jenkins-brukeren, og les journalen etter den første virkelige leveringen. Det siste trinnet er det som skiller en fungerende relay fra en konfigurert.
[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 en ekte push i stedet for en replay-knapp. En replay øver på relayens lagrede payload, ikke veien fra GitHub til kanalen din, så den kan bestå mens direktesendingen fortsatt feiler.
Varsle når uniten stopper. En relay som er nede er stille av konstruksjon, og stillheten er nettopp det du allerede feilsøker.
Hva relayen kan se, og når du ikke bør bruke en
En relay terminerer payloaden, så den ser reponavn, commit-data og alt annet hendelsen bærer. Behandle kanalens URL som et offentlig endepunkt. Hold Jenkins’ hemmelige token konfigurert slik at forfalskede leveringer avvises, og begrens tokenet Jenkins bruker til det nødvendige minimum.
Hvis payload-konfidensialitet utelukker det, er en selvhostet runner eller en autentisert revers-tunnel svaret.
En relay er infrastruktur nå, og den fortjener samme gjennomgang som bygget den utløser. Roter kanalen hvis den lekker, og noter datoen du sist verifiserte en direktesending. Sett den datoen i runbooken ved siden av kanalens URL. En relay ingen har gjennomgått på et år er et offentlig endepunkt ingen eier.