GitHub-webhooken når inte privata Jenkins: rätta till vägen

Du kan öppna Jenkins över VPN och ändå se GitHub rapportera en misslyckad webhook, eftersom det är två olika anslutningar med två olika ägare. Webbläsaren färdas i en tunnel som laptopen förhandlade; GitHubs leveranstjänst börjar på det publika internet och har ingen väg in i det privata nätet. Åtkomst till repot ändrar inte det, även om Jenkins självt kan hämta från samma repo utan problem. Välj en ingång, en relay eller polling och testa sedan den väg händelsen faktiskt tar.

En webbläsarsession bevisar bara en riktning

En VPN-anslutning svarar på en fråga: kan den här laptopen nå den interna värden. Leverans av webhooks frågar något annat: kan en extern tjänst öppna en anslutning till den värden. Att Jenkins hämtar från ett repo är utgående trafik och säger inget om inkommande nåbarhet. Håll båda riktningarna på separata rader i diagrammet, inklusive vilken sida som startar var och en.

Läs leveransposten innan du ändrar något. En timeout, en återställd anslutning och en accepterad begäran som inte matchade något jobb har tre olika ägare: nätverk, proxy och utlösarens konfiguration.

Alternativ A: exponera en smal slutpunkt

Om organisationen redan publicerar en godkänd ingång, exponera webhookens väg i stället för instrumentpanelen. Det betyder oftast en regel för omvänd proxy som tar emot POST på hookens URL och vidarebefordrar dem till Jenkins, medan administrationsgränssnittet förblir oåtkomligt utifrån.

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

Kör det testet från ett nätverk utan VPN-åtkomst, eftersom en framgång inifrån tunneln inte bevisar något. Slutpunkten bör avvisa begäranden utan den delade hemligheten, som GitHub skickar som signaturhuvud, och bara acceptera den enda väg och metod du publicerade. En offentlig Jenkins-konsol är inte en webhook-fix; det är en incident som väntar på nästa skanner. Avgränsa regeln tillräckligt snävt för att resten av applikationen behåller sina tidigare åtkomstkontroller.

Alternativ B: vänd riktningen med en relay

Där inkommande exponering inte kommer att godkännas kan en liten klient inne i nätet hålla en utgående anslutning till en relay och ta emot vidarebefordrade händelser. Reläet blir då en del av leveransvägen, så dess tillgänglighet och autentisering är lika viktiga som byggjobbet.

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

Jenkins vägledning om webhooks bakom brandväggar beskriver den här formen, och den är värd att läsa innan du skriver en egen vidarebefordrare. Avsluta TLS vid reläet, verifiera signaturen innan händelsen når jobbet och övervaka den utgående länken, eftersom en bruten tunnel ser precis ut som en händelse som aldrig skickades. Bekräfta också att reläet bevarar begärans brödtext byte för byte, eftersom signaturkontroller misslyckas på JSON som har parsats och kodats om på vägen.

Alternativ C: polla repot i stället

Polling byter väntetid mot enkelhet och behöver ingen inkommande väg alls. Jenkins kan polla enligt ett schema, eller ett litet jobb kan fråga API:et och starta ett bygge när det ser en okänd revision.

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

Varje polling förbrukar API-anrop och lägger till en fördröjning mellan push och bygge, vilket syns på trafikerade repon och delade hastighetsgränser. Det kräver också inloggningsuppgifter lagrade där pollaren körs, så begränsa token till skrivskyddad åtkomst till repot och rotera det som varje annan hemlighet. Välj detta när händelsevolymen är låg eller när en ingång aldrig kommer att godkännas, och säg det i jobbeskrivningen så att ingen senare undrar varför byggena släpar efter.

Acceptera en riktig leverans, inte en sidladdning

Vilket alternativ du än valde är acceptanstestet en händelse som skickas av källplattformen, inte en webbläsarflik öppnad från en privilegierad laptop. Skicka en tom commit till en skräpgren och läs leveransens svarskod, reläets logg eller pollingjobbets utdata, i den ordningen. Ett 200 från slutpunkten utan bygge betyder att utlösarens filter är fel; en timeout betyder att vägen fortfarande är stängd. Notera vilken av de tre designerna som används, annars upprepar nästa person som felsöker webbläsartestet och hamnar i samma återvändsgränd.

Tillämpa samma resonemang på betalnings-callbacks och andra externa aviseringar: var och en behöver sin egen väg in i den privata applikationen, även när varje människa redan har en VPN-session. Leveransvägen hör till applikationens design, inte till en fotnot om nätverk.