Prečo webhooky GitHub vypršia proti Jenkinsu za VPN

Stránka doručenia zobrazuje vypršanie a Jenkins nič nezaznamená, čo je podpis spojenia, ktoré nikdy nedorazilo. GitHub posiela webhook ako odchádzajúci HTTP POST zo svojej vlastnej infraštruktúry na payload URL, ktoré ste nastavili. VPN chráni Jenkins tým, že odmieta presne taký typ spojenia. Na žiadnej strane nie je nič pokazené. Problém je v smere požiadavky.

Čo doručenie vlastne skúša

GitHub preloží názov hostiteľa v payload URL a pripojí sa k nemu z verejného internetu. Ak to URL ukazuje na súkromnú adresu alebo na meno, ktoré sa preloží len vnútri vašej siete, pokus zlyhá skôr, než sa odošle akákoľvek požiadavka. Ak ukazuje na verejné meno, ktoré vaša hrana zahodí, pokus namiesto toho vyprší.

Ten rozdiel je dôležitý pre diagnostiku. Zlyhanie DNS aj filtrovaný port vyzerajú, akoby sa na strane Jenkinsu nič nestalo, a oboje sa v GitHube zobrazí ako neúspešné doručenie s iným pripojeným dôvodom. Prečítajte si ten dôvod skôr, než zmeníte URL.

Tunel, ktorý vytáča spojenie von, nevytvára poslucháča. Práve to ľudia očakávajú, že bude fungovať inak.

Tri spôsoby, ako opraviť smer spojenia

Každé riešenie mení, kto spojenie začína, a existujú len tri podoby.

Dopytovanie je najmenej elegantné a najľahšie prevádzkovateľné. Relay udržiava takmer okamžitú spätnú väzbu bez otvorenia portu. Runner je zvyčajne správna odpoveď, keď dôvernosť payloadu vylučuje tretiu stranu, pretože úloha môže bežať na stroji, ktorý už je vnútri siete.

Vyberajte podľa toho, čo dokážete prevádzkovať, nie podľa toho, čo znie moderne.

Prežeňte doručenie von pomocou smee

Vytvorte kanál v službe relay a jeho URL si uložte. Vnútri siete nainštalujte klienta a preposielajte doručenia na cestu, ktorú Jenkins očakáva. Payload URL v nastaveniach repozitára sa stane URL kanála a typ obsahu sa nastaví na application/json.

sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080

O úspechu rozhodujú tri detaily. Cesta musí zodpovedať tomu, čo Jenkins očakáva pre udalosti GitHubu, čo je štandardne /github-webhook/. Jenkins musí počúvať na porte, ktorý ste klientovi dali. A Jenkins URL nastavené v úlohe musí s touto cestou súhlasiť, inak udalosť dorazí a potom je zahodená.

Nezhoda na koncovej lomke vytvorí 404, ktoré sa číta ako zlyhanie doručenia, ale nie je ním.

Prevádzkovanie tak, aby prežilo týždeň

Klient v popredí umiera s terminálom a webhooky fungujú deň, a potom sa zastavia. Dajte mu unit s Restart=always, spustite ho ako používateľ Jenkins a po prvom skutočnom doručení si prečítajte journal. Práve ten posledný krok oddeľuje funkčný relay od nastaveného.

[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.target

Testujte skutočným push, nie tlačidlom prehratia. Prehratie precvičuje uložený payload relay, nie cestu z GitHubu do vášho kanála, takže môže prejsť, aj keď živé doručenie stále zlyháva.

Nastavte upozornenie, keď sa unit zastaví. Relay, ktorý je mimo prevádzky, je ticho podľa konštrukcie a ticho je presne to, čo už ladíte.

Čo relay vidí a kedy ho nepoužívať

Relay ukončuje payload, takže vidí názvy repozitárov, údaje o commite a všetko ostatné, čo udalosť nesie. Správajte sa k URL kanála ako k verejnému koncovému bodu. Udržujte tajný token Jenkinsu nastavený, aby sa sfalšované doručenia odmietali, a rozsah tokenu, ktorý Jenkins používa, obmedzte na potrebné minimum.

Ak to dôvernosť payloadu vylučuje, runner hostovaný u vás alebo overený reverzný tunel je odpoveď.

Relay je teraz infraštruktúra a zaslúži si rovnakú revíziu ako build, ktorý spúšťa. Ak unikne, rotujte kanál, a poznamenajte si dátum, kedy ste naposledy overili živé doručenie. Ten dátum dajte do runbooku vedľa URL kanála. Relay, ktorý nikto rok neskontroloval, je verejný koncový bod, ktorý nikomu nepatrí.