Firwat GitHub-Webhooks géint e Jenkins hannert engem VPN an en Timeout lafen
GitHub schéckt Webhooks no bannen, dofir refuséiert e VPN, deen Jenkins schützt, se. Leet d'Liwwerung no baussen duerch en Relay, oder ersetzt de Webhook duerch en Agent, dee pollt.
D'Liwwerungssäit weist en Timeout a Jenkins loggt näischt, wat d'Signatur vun enger Verbindung ass, déi ni ukomm ass. GitHub schéckt e Webhook als erausgängigen HTTP POST aus senger eegener Infrastruktur un d'Payload-URL, déi Dir konfiguréiert hutt. E VPN schützt Jenkins, andeems et genee déi Zort Verbindung refuséiert. Op kenger Säit ass eppes futti. D'Richtung vun der Ufro ass de Problem.
Wat d'Liwwerung tatsächlech probéiert
GitHub léist den Hostnumm an der Payload-URL op a verbënnt sech aus dem ëffentlechen Internet domat. Wann déi URL op eng privat Adress weist, oder op en Numm, deen nëmmen an Ärem Netz opgeléist gëtt, feelt den Versuch, ier iergendeng Ufro gemaach gëtt. Wann se op en ëffentlechen Numm weist, deen Äre Rand verwerft, leeft den Versuch amplaz an en Timeout.
Den Ënnerscheed ass wichteg fir d'Diagnos. En DNS-Fehler an en gefilterte Port gesinn allebéid aus, wéi wann op der Jenkins-Säit näischt geschitt wier, a béid erschéngen op GitHub als feelgeschloen Liwwerung mat engem aneren ugehaangene Grond. Liest deen Grond, ier Dir d'URL ännert.
En Tunnel, dee no baussen wielt, schaaft keen Nolauschterer. Genau deen Deel erwaarden d'Leit anescht ze funktionéieren.
Dräi Weeër, fir d'Richtung vun der Verbindung ze flécken
All Léisung ännert, wien d'Verbindung ufänkt, an et gëtt just dräi Formen.
| 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 ass déi mannst elegant an déi einfachst ze bedreiwen. En Relay hält bal direkt Feedback, ouni ee Port opzemaachen. En Runner ass meeschtens déi richteg Äntwert, wann d'Vertraulechkeet vum Payload en Drëtten ausschléisst, well d'Aarbecht op enger Maschinn ka lafen, déi schonn am Netz steet.
Wielt no deem, wat Dir kënnt bedreiwen, net no deem, wat modern kléngt.
Leet eng Liwwerung mat smee no baussen
Maacht en Kanal um Relay-Service an haalt seng URL. Am Netz installéiert Dir de Client a leet d'Liwwerungen op de Wee, deen Jenkins erwaart. D'Payload-URL an den Astellunge vum Repository gëtt d'Kanal-URL, mam Inhaltstyp op application/json gesat.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Dräi Detailer entscheeden, ob et funktionéiert. De Wee muss deem entspriechen, wat Jenkins fir GitHub-Evenementer erwaart, wat standardméisseg /github-webhook/ ass. Jenkins muss op deem Port lauschteren, deen Dir dem Client ginn hutt. An d'Jenkins-URL, déi an der Aarbecht konfiguréiert ass, muss mat deem Wee iwwerenee stëmmen, soss kënnt den Evenement un a gëtt dann verworf.
En ënnerschiddlechen Ofschloss-Schrägstréch produzéiert eng 404, déi wéi eng feelgeschloen Liwwerung gelies gëtt an et net ass.
Et sou bedreiwen, datt et d'Woch iwwersteht
En Client am Virdergrond stierft mam Terminal, an d'Webhooks schaffen een Dag a stoppen dann. Gitt him eng Unit mat Restart=always, bedreift se als Jenkins-Benotzer a liest de Journal no der éischter richteger Liwwerung. Genau dee leschten Schrëtt trennt en funktionéierende Relay vun engem konfiguréierten.
[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.targetTestt mat engem richtege Push amplaz vun engem Replay-Knäppchen. E Replay üübt de gespäicherte Payload vum Relay, net de Wee vun GitHub bis an Äre Kanal, dofir kann et duerchgoen, während d'Live-Liwwerung nach ëmmer feelt.
Alarméiert, wann d'Unit stoppt. En Relay, deen erof ass, ass duerch seng Konstruktioun stëll, an d'Stëllt ass genee dat, wat Dir schonn debuggert.
Wat den Relay ka gesinn, a wéini Dir keen benotze sollt
En Relay terminéiert de Payload, dofir gesäit en Repository-Nimm, Commit-Daten an alles anescht, wat den Evenement dréit. Behandelt d'Kanal-URL als ëffentlechen Endpunkt. Halt den geheimen Token vu Jenkins konfiguréiert, sou datt gefälschte Liwwerungen ofgeleent ginn, a beschränkt den Token, deen Jenkins benotzt, op dat néidegt Minimum.
Wann d'Vertraulechkeet vum Payload dat ausschléisst, ass en selbst gehostete Runner oder en authentifizéierten Ëmkéiertunnel d'Äntwert.
En Relay ass elo Infrastruktur, an et verdéngt déiselwecht Iwwerpréiwung wéi de Build, deen et ausléist. Rotéiert de Kanal, wann en leckt, a notéiert den Datum, op deem Dir fir d'lescht eng Live-Liwwerung verifizéiert hutt. Setzt deen Datum am Runbook nieft d'Kanal-URL. En Relay, deen een Joer laang keen iwwerpréift huet, ass en ëffentlechen Endpunkt, deen keen huet.