GitHub-webhook kan ikke nå privat Jenkins: ret stien op

Du kan åbne Jenkins over VPN og alligevel se GitHub rapportere en mislykket webhook, fordi det er to forskellige forbindelser med to forskellige ejere. Browseren kører på en tunnel, som din bærbare har forhandlet; GitHubs leveringstjeneste starter på det offentlige internet og har ingen rute ind i det private netværk. Adgang til repositoriet ændrer ikke det, selv om Jenkins selv kan hente fra samme repositorium uden problemer. Vælg et indgangspunkt, en relay eller polling, og test derefter den vej, begivenheden faktisk tager.

En browsersession beviser kun én retning

En VPN-forbindelse besvarer ét spørgsmål: kan denne bærbare nå den interne vært. Levering af webhooks spørger om noget andet: kan en ekstern tjeneste åbne en forbindelse til den vært. Når Jenkins henter fra et repositorium, er det udgående trafik og siger intet om indgående tilgængelighed. Hold begge retninger på hver sin linje i dit diagram, inklusive hvilken side der starter hver af dem.

Læs leveringsposten, før du ændrer noget. En timeout, en nulstillet forbindelse og en accepteret anmodning, der ikke matchede noget job, har tre forskellige ejere: netværk, proxy og triggerkonfiguration.

Mulighed A: eksponer et smalt endepunkt

Hvis organisationen allerede offentliggør et godkendt indgangspunkt, så eksponer webhook-stien i stedet for kontrolpanelet. Det betyder normalt en regel for omvendt proxy, der accepterer POST på hook-URL’en og videresender dem til Jenkins, mens administrationsgrænsefladen forbliver utilgængelig udefra.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

Kør den test fra et netværk uden VPN-adgang, fordi en succes inde fra tunnelen ikke beviser noget. Endepunktet bør afvise anmodninger uden den fælles hemmelighed, som GitHub sender som signaturheader, og det bør kun acceptere den ene sti og metode, du offentliggjorde. En offentlig Jenkins-konsol er ikke en webhook-rettelse; det er en hændelse, der venter på den næste scanner. Afgræns reglen stramt nok til, at resten af applikationen beholder de adgangskontroller, den havde.

Mulighed B: vend retningen med en relay

Hvor indgående eksponering ikke vil blive godkendt, kan en lille klient inde i netværket holde en udgående forbindelse til en relay og modtage videresendte begivenheder. Relaysen bliver så en del af leveringsvejen, så dens tilgængelighed og godkendelse er lige så vigtig som byggejobbet.

ssh -N -R 9000:localhost:8080 relay.example.net

Jenkins’ vejledning om webhooks bag firewalls beskriver denne form, og den er værd at læse, før du skriver en egen videresender. Afslut TLS ved relaysen, verificer signaturen før begivenheden når jobbet, og overvåg det udgående link, fordi en brudt tunnel ser præcis ud som en begivenhed, der aldrig blev sendt. Bekræft også, at relaysen bevarer anmodningens krop byte for byte, da signaturkontroller fejler på JSON, der er blevet parset og kodet igen undervejs.

Mulighed C: poll repositoriet i stedet

Polling bytter ventetid for enkelhed og kræver slet ingen indgående vej. Jenkins kan polle efter en tidsplan, eller et lille job kan forespørge API’et og starte et byg, når det ser en ukendt revision.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

Hver polling bruger API-kald og tilføjer en forsinkelse mellem push og byg, hvilket bliver synligt på travle repositorier og delte hastighedsgrænser. Det kræver også legitimationsoplysninger gemt, hvor polleren kører, så begræns tokenet til skrivebeskyttet adgang til repositoriet og rotér det som enhver anden hemmelighed. Vælg dette, når begivenhedsmængden er lav, eller når et indgangspunkt aldrig bliver godkendt, og skriv det i jobbeskrivelsen, så ingen senere undrer sig over, hvorfor byggene halter.

Accepter en rigtig levering, ikke en sidevisning

Uanset hvilken mulighed du valgte, er accepttesten en begivenhed sendt af kildeplatformen, ikke en browservane åbnet fra en privilegeret bærbar. Skub et tomt commit til en skrubbegren og læs leveringens svarkode, relayens log eller pollingjobbets output, i den rækkefølge. Et 200 fra endepunktet uden et byg betyder, at triggerfilteret er forkert; en timeout betyder, at vejen stadig er lukket. Noter, hvilket af de tre designs der er i brug, for ellers gentager den næste, der fejlfinder, browsertesten og ender samme sted.

Anvend samme ræsonnement på betalings-callbacks og andre udefrakommende notifikationer: hver af dem har brug for sin egen rute ind i den private applikation, selv når hvert menneske allerede har en VPN-session. Leveringsvejen hører til i applikationens design, ikke i en netværksfodnote.