Hvorfor GitHub-webhooks timer ud mod en Jenkins bag en VPN
GitHub sender webhooks indad, så en VPN, der beskytter Jenkins, afviser dem. Send leveringen udad via en relay, eller erstat webhooken med en agent, der poller.
Leveringssiden viser en timeout, og Jenkins logger intet, hvilket er signaturen på en forbindelse, der aldrig nåede frem. GitHub sender en webhook som et udgående HTTP POST fra sin egen infrastruktur til den payload-URL, du konfigurerede. En VPN beskytter Jenkins ved at afvise netop den slags forbindelse. Intet er i stykker på nogen af siderne. Problemet er retningen på anmodningen.
Hvad leveringen faktisk forsøger
GitHub slår værtsnavnet i payload-URL’en op og forbinder til det fra det offentlige internet. Hvis den URL peger på en privat adresse eller på et navn, der kun slås op internt i dit netværk, fejler forsøget, før nogen anmodning sendes. Hvis den peger på et offentligt navn, som din edge dropper, timer forsøget ud i stedet.
Forskellen betyder noget for diagnostikken. En DNS-fejl og en filtreret port ser begge ud, som om der ikke skete noget på Jenkins-siden, og begge vises i GitHub som en mislykket levering med en anden årsag vedhæftet. Læs den årsag, før du ændrer URL’en.
En tunnel, der ringer udad, opretter ikke en lytter. Det er den del, folk forventer fungerer anderledes.
Tre måder at rette forbindelsens retning
Hver løsning ændrer, hvem der starter forbindelsen, og der findes kun 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 mindst elegante og det nemmeste at drive. En relay holder næsten øjeblikkelig feedback uden at åbne en port. En runner er normalt det rigtige svar, når payload-fortrolighed udelukker en tredjepart, fordi jobbet kan køre på en maskine, der allerede står inde i netværket.
Vælg efter, hvad du kan drive, ikke efter, hvad der lyder moderne.
Send en levering udad med smee
Opret en kanal på relay-tjenesten, og gem dens URL. Inde i netværket installerer du klienten og videresender leveringer til den sti, Jenkins forventer. Payload-URL’en i repositoryindstillingerne bliver kanalens URL, med indholdstypen sat til application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tre detaljer afgør, om det virker. Stien skal matche det, Jenkins forventer til GitHub-begivenheder, hvilket som standard er /github-webhook/. Jenkins skal lytte på den port, du gav klienten. Og den Jenkins-URL, der er konfigureret i jobbet, skal stemme overens med den sti, ellers ankommer begivenheden og kasseres derefter.
Uoverensstemmelse med en afsluttende skråstreg giver en 404, der læses som en mislykket levering og ikke er det.
Kør det, så det overlever ugen
En klient i forgrunden dør med terminalen, og webhooks virker en dag og stopper så. Giv den en unit med Restart=always, kør den som Jenkins-brugeren, og læs journalen efter den første rigtige levering. Det sidste skridt er det, der adskiller en fungerende relay fra en konfigureret.
[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 et rigtigt push i stedet for en replay-knap. En replay kører relayens gemte payload, ikke vejen fra GitHub til din kanal, så den kan bestå, mens live-leveringen stadig fejler.
Alarmer, når uniten stopper. En relay, der er nede, er tavs af konstruktion, og tavshed er præcis det, du allerede fejlfinder.
Hvad relayen kan se, og hvornår du ikke bør bruge en
En relay terminerer payloaden, så den ser repositorynavne, commit-data og alt andet, begivenheden bærer. Behandl kanalens URL som et offentligt endepunkt. Hold Jenkins’ hemmelige token konfigureret, så forfalskede leveringer afvises, og begræns det token, Jenkins bruger, til det minimum, der er nødvendigt.
Hvis payload-fortrolighed udelukker det, er en selvhostet runner eller en autentificeret omvendt tunnel svaret.
En relay er infrastruktur nu, og den fortjener samme gennemgang som det build, den udløser. Roter kanalen, hvis den lækker, og noter datoen for, hvornår du sidst verificerede en live-levering. Sæt den dato i runbooken ved siden af kanalens URL. En relay, som ingen har gennemgået i et år, er et offentligt endepunkt, som ingen ejer.