Miks GitHubi webhookid aeguvad VPN-i taga oleva Jenkinsi vastu

Tarnete leht näitab aegumist ja Jenkins ei logi midagi, mis on märk ühendusest, mis kunagi kohale ei jõudnud. GitHub saadab webhooki väljuva HTTP POST-ina oma infrastruktuurist payload URL-ile, mille te seadistasite. VPN kaitseb Jenkinsit, keeldudes täpselt sellist tüüpi ühendusest. Kummaltki poolt pole midagi katki. Probleem on päringu suunas.

Mida tarne tegelikult üritab

GitHub lahendab payload URL-is oleva hostinime ja ühendub sellega avalikust internetist. Kui see URL osutab privaatsele aadressile või nimele, mis laheneb ainult teie võrgus, ebaõnnestub katse enne, kui ükski päring tehakse. Kui see osutab avalikule nimele, mille teie serv välja viskab, aegub katse selle asemel.

See vahe on diagnoosimisel oluline. DNS-i tõrge ja filtreeritud port näevad mõlemad välja nii, nagu Jenkinsi poolel ei juhtunud midagi, ja mõlemad ilmuvad GitHubis ebaõnnestunud tarnena, millele on lisatud erinev põhjus. Lugege seda põhjust enne, kui URL-i muudate.

Väljapoole helistav tunnel ei loo kuulajat. Just seda osa ootavad inimesed teistmoodi töötavat.

Kolm viisi ühenduse suuna parandamiseks

Iga lahendus muudab seda, kes ühenduse algatab, ja vorme on ainult kolm.

Küsitlemine on kõige vähem elegantne ja kõige lihtsam käitada. Relay hoiab peaaegu kohest tagasisidet, ilma porti avamata. Runner on tavaliselt õige vastus, kui payload-i konfidentsiaalsus välistab kolmanda osapoole, sest töö saab joosta masinas, mis juba asub võrgu sees.

Valige selle järgi, mida suudate käitada, mitte selle järgi, mis kõlab moodsalt.

Suunake tarne smee abil väljapoole

Looge relay-teenuses kanal ja hoidke selle URL-i. Võrgu sees installige klient ja suunake tarned teele, mida Jenkins ootab. Repositooriumi seadetes olev payload URL muutub kanali URL-iks, sisutüübiks on application/json.

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

Kolm detaili otsustavad, kas see töötab. Tee peab vastama sellele, mida Jenkins GitHubi sündmuste jaoks ootab, mis on vaikimisi /github-webhook/. Jenkins peab kuulama pordil, mille te kliendile andsite. Ja töös seadistatud Jenkins URL peab selle teega kokku sobima, muidu sündmus saabub ja visatakse seejärel ära.

Lõpus oleva kaldkriipsu mittevastavus tekitab 404, mis loetakse ebaõnnestunud tarneks, aga ei ole seda.

Käitamine nii, et see nädala üle elaks

Esiplaanil klient sureb koos terminaliga ja webhookid töötavad päeva ning siis lakkavad. Andke sellele unit, millel on Restart=always, käivitage see Jenkinsi kasutajana ja lugege journali pärast esimest tõelist tarnet. Just see viimane samm eristab toimivat relay-d seadistatud relay-st.

[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

Testige tõelise push-iga, mitte kordusnupuga. Kordus harjutab relay hoiustatud payload-i, mitte teed GitHubist teie kanalini, seega võib see läbida, kuigi reaalajas tarne ikka ebaõnnestub.

Häiresignaal, kui unit peatub. Maas olev relay on konstruktsiooni tõttu vaikne, ja vaikus ongi see, mida te juba silute.

Mida relay näha võib ja millal seda mitte kasutada

Relay lõpetab payload-i, seega näeb see repositooriumide nimesid, commit-andmeid ja kõike muud, mida sündmus kannab. Käsitlege kanali URL-i avaliku lõpp-punktina. Hoidke Jenkinsi salajane token seadistatud, et võltsitud tarned tagasi lükataks, ja piirake Jenkinsi kasutatav token vajaliku miinimumini.

Kui payload-i konfidentsiaalsus seda välistab, on isemajutatav runner või autenditud pöördunnel vastus.

Relay on nüüd infrastruktuur ja väärib sama ülevaatust kui build, mille see käivitab. Kui kanal lekib, roteerige see, ja märkige kuupäev, millal te viimati reaalajas tarnet kontrollisite. Pange see kuupäev runbooki kanali URL-i kõrvale. Relay, mida keegi aasta jooksul üle vaadanud pole, on avalik lõpp-punkt, mida keegi ei oma.