GitHub-webhook når ikke privat Jenkins: rett opp stien

Du kan åpne Jenkins over VPN og likevel se GitHub rapportere en mislykket webhook, fordi det er to forskjellige forbindelser med to forskjellige eiere. Nettleseren kjører på en tunnel som den bærbare forhandlet; GitHubs leveringstjeneste starter på det offentlige internettet og har ingen rute inn i det private nettverket. Tilgang til repositoriet endrer ikke det, selv om Jenkins selv kan hente fra samme repositorium uten problemer. Velg et inngangspunkt, en relay eller polling, og test deretter veien hendelsen faktisk tar.

En nettleserøkt beviser bare én retning

En VPN-forbindelse svarer på ett spørsmål: kan denne bærbare nå den interne verten. Levering av webhooks spør om noe annet: kan en ekstern tjeneste åpne en forbindelse til den verten. At Jenkins henter fra et repositorium, er utgående trafikk og sier ingenting om inngående tilgjengelighet. Hold begge retningene på hver sin linje i diagrammet ditt, inkludert hvilken side som starter hver av dem.

Les leveringsposten før du endrer noe. En timeout, en tilbakestilt forbindelse og en akseptert forespørsel som ikke samsvarte med noen jobb har tre forskjellige eiere: nettverk, proxy og triggerkonfigurasjon.

Alternativ A: eksponer et smalt endepunkt

Hvis organisasjonen allerede publiserer et godkjent inngangspunkt, eksponer webhook-stien i stedet for dashbordet. Det betyr vanligvis en regel for omvendt proxy som godtar POST på hook-URL-en og videresender dem til Jenkins, mens administrasjonsgrensesnittet forblir utilgjengelig utenfra.

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

Kjør den testen fra et nettverk uten VPN-tilgang, fordi en suksess inne fra tunnelen ikke beviser noe. Endepunktet bør avvise forespørsler uten den delte hemmeligheten, som GitHub sender som signaturheader, og det bør bare godta den ene stien og metoden du publiserte. En offentlig Jenkins-konsoll er ikke en webhook-rettelse; det er en hendelse som venter på neste skanner. Avgrense regelen stramt nok til at resten av applikasjonen beholder tilgangskontrollene den hadde.

Alternativ B: snu retningen med en relay

Der inngående eksponering ikke vil bli godkjent, kan en liten klient inne i nettverket holde en utgående forbindelse til en relay og motta videresendte hendelser. Relaysen blir da en del av leveringsveien, så dens tilgjengelighet og autentisering er like viktig som byggejobben.

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

Jenkins’ veiledning om webhooks bak brannmurer beskriver denne formen, og den er verdt å lese før du skriver din egen videresender. Avslutt TLS ved relaysen, verifiser signaturen før hendelsen når jobben, og overvåk den utgående lenken, fordi en brutt tunnel ser nøyaktig ut som en hendelse som aldri ble sendt. Bekreft også at relaysen bevarer forespørselens kropp byte for byte, siden signaturkontroller feiler på JSON som er blitt parset og kodet på nytt underveis.

Alternativ C: poll repositoriet i stedet

Polling bytter ventetid mot enkelhet og trenger ingen inngående vei i det hele tatt. Jenkins kan polle etter en tidsplan, eller en liten jobb kan spørre API-et og starte et bygg når den ser en ukjent revisjon.

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

Hver polling bruker API-kall og legger til en forsinkelse mellom push og bygg, noe som blir synlig på travle repositorier og delte hastighetsgrenser. Det krever også legitimasjon lagret der polleren kjører, så begrens tokenet til skrivebeskyttet tilgang til repositoriet og roter det som enhver annen hemmelighet. Velg dette når hendelsesvolumet er lavt eller når et inngangspunkt aldri blir godkjent, og si det i jobbbeskrivelsen slik at ingen senere lurer på hvorfor byggene henger etter.

Godta en ekte levering, ikke en sidevisning

Uansett hvilket alternativ du valgte, er aksepttesten en hendelse sendt av kildeplattformen, ikke en nettleserfane åpnet fra en privilegert bærbar. Skyv en tom commit til en skrapegren og les leveringens svarkode, relaysens logg eller pollingjobbens utdata, i den rekkefølgen. Et 200 fra endepunktet uten et bygg betyr at triggerfilteret er feil; en timeout betyr at veien fortsatt er stengt. Noter hvilket av de tre designene som er i bruk, ellers vil den neste som feilsøker gjenta nettlesertesten og ende på samme blindgate.

Bruk samme resonnement på betalings-callbacks og andre eksterne varsler: hver av dem trenger sin egen rute inn i den private applikasjonen, selv når hvert menneske allerede har en VPN-økt. Leveringsveien hører hjemme i applikasjonens design, ikke i en nettverksfotnote.