Hindi naaabot ng webhook ng GitHub ang pribadong Jenkins: ayusin ang landas

Maaari mong buksan ang Jenkins sa VPN at makita pa ring iniuulat ng GitHub ang nabigong webhook, dahil dalawang magkaibang koneksyon ito na may dalawang magkaibang may-ari. Dumadaan ang browser sa isang tunnel na pinag-usapan ng laptop mo; ang serbisyo ng paghahatid ng GitHub ay nagsisimula sa pampublikong internet at walang ruta papasok sa pribadong network. Hindi ito binabago ng access sa repository, kahit na ang Jenkins mismo ay nakakakuha mula sa parehong repository nang walang problema. Pumili ng papasok na daan, relay o polling, pagkatapos subukan ang landas na talagang dinaraanan ng kaganapan.

Isang direksyon lang ang pinatutunayan ng sesyon ng browser

Ang koneksyon ng VPN ay sumasagot sa isang tanong: naaabot ba ng laptop na ito ang panloob na host. Ang paghahatid ng webhook ay nagtatanong ng iba: makakabukas ba ang isang panlabas na serbisyo ng koneksyon sa host na iyon. Ang pagkuha ng Jenkins mula sa repository ay palabas na trapiko at wala itong sinasabi tungkol sa papasok na pag-abot. Panatilihin ang dalawang direksyon sa magkahiwalay na linya sa diagram, kasama kung aling panig ang nagpapasimula ng bawat isa.

Basahin ang talaan ng paghahatid bago magbago ng kahit ano. Ang pag-timeout, pag-reset ng koneksyon at tinanggap na kahilingan na hindi tumugma sa anumang trabaho ay may tatlong magkaibang may-ari: network, proxy at configuration ng trigger.

Opsyon A: ilantad ang makitid na endpoint

Kung naglalathala na ang organisasyon ng aprubadong papasok na daan, ilantad ang landas ng webhook sa halip na ang dashboard. Karaniwang ibig sabihin nito ay isang tuntunin ng reverse proxy na tumatanggap ng POST sa URL ng hook at nagpapasa sa kanila sa Jenkins habang nananatiling hindi maabot mula sa labas ang interface ng administrasyon.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

Patakbuhin ang pagsubok na iyon mula sa network na walang access sa VPN, dahil ang tagumpay mula sa loob ng tunnel ay walang pinatutunayan. Dapat tanggihan ng endpoint ang mga kahilingang walang pinagsamang lihim, na ipinapadala ng GitHub bilang header ng lagda, at dapat tanggapin lamang ang nag-iisang landas at paraan na inilathala mo. Ang pampublikong console ng Jenkins ay hindi pag-aayos ng webhook; ito ay insidente na naghihintay sa susunod na scanner. Higpitan ang tuntunin nang sapat upang mapanatili ng natitirang aplikasyon ang mga kontrol sa access na mayroon ito.

Opsyon B: baliktarin ang direksyon gamit ang relay

Kung saan hindi aprubahan ang papasok na paglantad, ang isang maliit na kliyente sa loob ng network ay maaaring panatilihin ang palabas na koneksyon sa isang relay at tumanggap ng mga ipinasang kaganapan. Ang relay ay nagiging bahagi ng landas ng paghahatid, kaya ang pagiging magagamit at pagpapatunay nito ay kasinghalaga ng trabaho ng build.

ssh -N -R 9000:localhost:8080 relay.example.net

Ang patnubay ng Jenkins tungkol sa mga webhook sa likod ng firewall ay naglalarawan ng anyong ito, at sulit basahin bago magsulat ng sariling forwarder. Tapusin ang TLS sa relay, tiyakin ang lagda bago maabot ng kaganapan ang trabaho, at subaybayan ang palabas na link, dahil ang nahulog na tunnel ay mukhang eksaktong kaganapang hindi kailanman naipadala. Tiyakin din na pinapanatili ng relay ang katawan ng kahilingan bawat byte, dahil nabibigo ang mga pagsusuri ng lagda sa JSON na na-parse at na-encode muli sa daan.

Opsyon C: i-poll ang repository

Ang polling ay nagpapalit ng latency sa simple at hindi nangangailangan ng papasok na landas. Maaaring mag-poll ang Jenkins ayon sa iskedyul, o maaaring magtanong ang maliit na trabaho sa API at magsimula ng build kapag nakakita ng hindi pamilyar na rebisyon.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

Ang bawat polling ay gumagastos ng mga tawag sa API at nagdaragdag ng pagkaantala sa pagitan ng push at build, na nakikita sa abalang repository at pinagsamang limitasyon sa bilis. Kailangan din nito ng mga kredensyal na nakaimbak saanman tumatakbo ang poller, kaya limitahan ang token sa pagbabasa lamang sa repository at paikutin ito tulad ng anumang ibang lihim. Piliin ito kapag mababa ang dami ng kaganapan o kapag hindi kailanman aprubahan ang papasok na daan, at sabihin ito sa paglalarawan ng trabaho upang walang magtanong mamaya kung bakit nahuhuli ang mga build.

Tanggapin ang tunay na paghahatid, hindi pag-load ng pahina

Anuman ang napili mong opsyon, ang pagsubok sa pagtanggap ay kaganapang ipinadala ng pinagmulang plataporma, hindi tab ng browser na binuksan mula sa pribilehiyadong laptop. I-push ang walang laman na commit sa pansamantalang sangay at basahin ang code ng tugon ng paghahatid, ang log ng relay o ang output ng trabaho ng polling, sa ganoong pagkakasunod-sunod. Ang 200 mula sa endpoint na walang build ay nangangahulugang mali ang filter ng trigger; ang pag-timeout ay nangangahulugang sarado pa rin ang landas. Itala kung alin sa tatlong disenyo ang ginagamit, dahil kung hindi ay uulitin ng susunod na mag-debug ang pagsubok sa browser at makakarating sa parehong dead end.

Ilapat ang parehong pangangatwiran sa mga callback ng bayad at iba pang panlabas na abiso: bawat isa ay nangangailangan ng sariling ruta papasok sa pribadong aplikasyon, kahit na may sesyon ng VPN na ang bawat tao. Ang landas ng paghahatid ay bahagi ng disenyo ng aplikasyon, hindi ng talababa tungkol sa mga network.