Pse webhook-et e GitHub skadojnë ndaj një Jenkins pas VPN
GitHub i dërgon webhook-et nga brenda, ndaj një VPN që mbron Jenkins i refuzon ato. Përcillni dorëzimin nga jashtë përmes një relay, ose zëvendësoni webhook-un me një agjent që bën sondazh.
Faqja e dorëzimit tregon një skadim kohe dhe Jenkins nuk regjistron asgjë, që është shenja e një lidhjeje që nuk arriti kurrë. GitHub e dërgon webhook-un si një HTTP POST në dalje nga infrastruktura e vet drejt payload URL-së që keni konfiguruar. Një VPN mbron Jenkins duke refuzuar pikërisht atë lloj lidhjeje. Asgjë nuk është prishur në asnjërën anë. Problemi është drejtimi i kërkesës.
Çfarë përpiqet në të vërtetë dorëzimi
GitHub zgjidh emrin e hostit në payload URL dhe lidhet me të nga interneti publik. Nëse ai URL tregon një adresë private, ose një emër që zgjidhet vetëm brenda rrjetit tuaj, përpjekja dështon përpara se të bëhet ndonjë kërkesë. Nëse tregon një emër publik që e hedh skaji juaj, përpjekja në vend të kësaj skadon.
Ky dallim ka rëndësi për diagnostikimin. Një dështim DNS dhe një port i filtruar duken të dy sikur nuk ndodhi asgjë në anën e Jenkins, dhe të dy shfaqen në GitHub si dorëzim i dështuar me një arsye tjetër të bashkangjitur. Lexoni atë arsye përpara se të ndryshoni URL-në.
Një tunel që merr jashtë nuk krijon një dëgjues. Pikërisht atë pjesë njerëzit presin të punojë ndryshe.
Tre mënyra për të rregulluar drejtimin e lidhjes
Çdo zgjidhje ndryshon kush e nis lidhjen, dhe ka vetëm tre forma.
| 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 |
Sondazhi është më pak elegant dhe më i lehtë për t’u operuar. Një relay mban reagim pothuajse të menjëhershëm pa hapur një port. Një runner është zakonisht përgjigja e duhur kur konfidencialiteti i payload-it përjashton një palë të tretë, sepse puna mund të ekzekutohet në një makinë që tashmë ndodhet brenda rrjetit.
Zgjidhni sipas asaj që mund të operoni, jo sipas asaj që tingëllon moderne.
Përcillni një dorëzim nga jashtë me smee
Krijoni një kanal në shërbimin relay dhe mbani URL-në e tij. Brenda rrjetit, instaloni klientin dhe përcillni dorëzimet në rrugën që pret Jenkins. Payload URL në cilësimet e depove bëhet URL-ja e kanalit, me llojin e përmbajtjes të vendosur në application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tre detaje vendosin nëse funksionon. Rruga duhet të përputhet me atë që pret Jenkins për ngjarjet e GitHub, që si parazgjedhje është /github-webhook/. Jenkins duhet të dëgjojë në portin që i dhatë klientit. Dhe Jenkins URL i konfiguruar në punë duhet të pajtohet me atë rrugë, përndryshe ngjarja arrin dhe më pas hidhet.
Një mospërputhje e pjerrësisë së fundit prodhon një 404 që lexohet si dështim dorëzimi dhe nuk është.
Ekzekutimi në mënyrë që t’i mbijetojë javës
Një klient në plan të parë vdes me terminalin, dhe webhook-et punojnë një ditë dhe pastaj ndalen. Jepini një unit me Restart=always, ekzekutoni si përdorues Jenkins dhe lexoni journal pas dorëzimit të parë të vërtetë. Pikërisht ai hap i fundit ndan një relay që punon nga një i konfiguruar.
[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.targetTestoni me një push të vërtetë në vend të butonit të ripërsëritjes. Ripërsëritja ushtron payload-in e ruajtur të relay-it, jo rrugën nga GitHub në kanalin tuaj, ndaj mund të kalojë ndërsa dorëzimi drejtpërdrejt ende dështon.
Sinjalizoni kur unit-i ndalon. Një relay i rënë është i qetë nga ndërtimi, dhe qetësia është pikërisht ajo që ju tashmë po korrigjoni.
Çfarë mund të shohë relay-i, dhe kur të mos përdorni një
Një relay e përfundon payload-in, ndaj shikon emrat e depove, të dhënat e commit dhe çdo gjë tjetër që mbart ngjarja. Trajtoni URL-në e kanalit si një pikë fundore publike. Mbani token-in sekret të Jenkins të konfiguruar që dorëzimet e falsifikuara të refuzohen, dhe kufizoni token-in që përdor Jenkins në minimumin e nevojshëm.
Nëse konfidencialiteti i payload-it e përjashton këtë, një runner i vetë-hostuar ose një tunel i kundërt i vërtetuar është përgjigja.
Një relay tani është infrastrukturë dhe meriton të njëjtën rishikim si build-i që aktivizon. Rrotulloni kanalin nëse rrjedh, dhe shënoni datën kur keni verifikuar për herë të fundit një dorëzim drejtpërdrejt. Vendoseni atë datë në runbook pranë URL-së së kanalit. Një relay që askush nuk e ka rishikuar për një vit është një pikë fundore publike që askush nuk e zotëron.