Waarom GitHub-webhooks ’n time-out kry teen ’n Jenkins agter ’n VPN

Die afleweringsblad wys ’n time-out en Jenkins teken niks aan nie, wat die kenmerk is van ’n verbinding wat nooit aangekom het nie. GitHub stuur ’n webhook as ’n uitgaande HTTP POST vanaf sy eie infrastruktuur na die payload-URL wat jy opgestel het. ’n VPN beskerm Jenkins deur juis daardie soort verbinding te weier. Niks is aan enige kant stukkend nie. Die rigting van die versoek is die probleem.

Wat die aflewering werklik probeer

GitHub los die gasheernaam in die payload-URL op en maak van die publieke internet daarmee verbinding. As daardie URL na ’n private adres wys, of na ’n naam wat net binne jou netwerk oplos, misluk die poging voordat enige versoek gemaak word. As dit na ’n publieke naam wys wat jou rand laat val, kry die poging eerder ’n time-out.

Die onderskeid maak saak vir diagnose. ’n DNS-fout en ’n gefiltreerde poort lyk albei of niks aan die Jenkins-kant gebeur het nie, en albei verskyn op GitHub as ’n mislukte aflewering met ’n ander rede aangeheg. Lees daardie rede voordat jy die URL verander.

’n Tonnel wat uitwaarts skakel, skep nie ’n luisteraar nie. Dit is die deel wat mense verwag anders te werk.

Drie maniere om die rigting van die verbinding reg te maak

Elke oplossing verander wie die verbinding begin, en daar is net drie vorms.

Polling is die minste elegant en die maklikste om te bedryf. ’n Relay hou byna onmiddellike terugvoer sonder om ’n poort oop te maak. ’n Runner is gewoonlik die regte antwoord wanneer payload-vertroulikheid ’n derde party uitsluit, want die werk kan op ’n masjien loop wat reeds binne die netwerk sit.

Kies volgens wat jy kan bedryf, nie volgens wat modern klink nie.

Stuur ’n aflewering uitwaarts deur met smee

Skep ’n kanaal op die relay-diens en hou sy URL. Binne die netwerk installeer jy die kliënt en stuur aflewerings na die pad wat Jenkins verwag. Die payload-URL in die bewaarplek se instellings word die kanaal-URL, met die inhoudstipe op application/json gestel.

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

Drie besonderhede bepaal of dit werk. Die pad moet ooreenstem met wat Jenkins vir GitHub-gebeurtenisse verwag, wat by verstek /github-webhook/ is. Jenkins moet luister op die poort wat jy aan die kliënt gegee het. En die Jenkins-URL wat in die werk opgestel is, moet met daardie pad saamstem, anders kom die gebeurtenis aan en word dan weggegooi.

’n Oorblywende skuinsstreep wat nie ooreenstem nie, lewer ’n 404 wat soos ’n afleweringsfout lees en nie een is nie.

Bedryf dit sodat dit die week oorleef

’n Voorgrondkliënt sterf saam met die terminaal, en die webhooks werk ’n dag en stop dan. Gee dit ’n unit met Restart=always, laat dit as die Jenkins-gebruiker loop, en lees die joernaal ná die eerste werklike aflewering. Daardie laaste stap is wat ’n werkende relay van ’n opgestelde een skei.

[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

Toets met ’n werklike push eerder as met ’n herspeelknoppie. ’n Herspeel oefen die relay se gestoorde payload uit, nie die pad van GitHub na jou kanaal nie, so dit kan slaag terwyl lewende aflewering steeds misluk.

Maak ’n waarskuwing wanneer die unit stop. ’n Relay wat af is, is per konstruksie stil, en stilte is juis waarmee jy reeds besig is om te ontfout.

Wat die relay kan sien, en wanneer om nie een te gebruik nie

’n Relay termineer die payload, so dit sien bewaarplekname, commit-data en wat die gebeurtenis ook al dra. Behandel die kanaal-URL as ’n publieke eindpunt. Hou die Jenkins-geheime token opgestel sodat vervalste aflewerings verwerp word, en beperk die token wat Jenkins gebruik tot die minimum wat dit nodig het.

As payload-vertroulikheid dit uitsluit, is ’n self-gehoste runner of ’n geauthentiseerde terugwaartse tonnel die antwoord.

’n Relay is nou infrastruktuur, en dit verdien dieselfde hersiening as die bou wat dit aktiveer. Roteer die kanaal as dit lek, en noteer die datum waarop jy laas ’n lewende aflewering geverifieer het. Sit daardie datum in die runbook langs die kanaal-URL. ’n Relay wat niemand ’n jaar lank hersien het nie, is ’n publieke eindpunt wat niemand besit nie.