Bakit nag-time out ang mga webhook ng GitHub laban sa isang Jenkins sa likod ng VPN
Nagpapadala ang GitHub ng mga webhook papasok, kaya tinatanggihan ng VPN na nagpoprotekta sa Jenkins ang mga ito. Ipadala ang paghahatid palabas sa pamamagitan ng relay, o palitan ang webhook ng agent na nagsasagawa ng polling.
Nagpapakita ng timeout ang pahina ng paghahatid at walang naitatala ang Jenkins, na siyang tanda ng koneksyong hindi kailanman dumating. Ipinapadala ng GitHub ang webhook bilang palabas na HTTP POST mula sa sarili nitong imprastraktura patungo sa payload URL na na-configure mo. Pinoprotektahan ng VPN ang Jenkins sa pamamagitan ng pagtanggi sa eksaktong ganoong uri ng koneksyon. Walang sira sa alinmang panig. Ang problema ay ang direksyon ng kahilingan.
Ano ang talagang sinusubukan ng paghahatid
Nireresolba ng GitHub ang hostname sa payload URL at kumokonekta rito mula sa pampublikong internet. Kung ang URL na iyon ay tumuturo sa isang pribadong address, o sa isang pangalang nireresolba lamang sa loob ng iyong network, nabibigo ang pagtatangka bago pa man magawa ang anumang kahilingan. Kung tumuturo ito sa isang pampublikong pangalan na itinatapon ng iyong gilid, nag-time out naman ang pagtatangka.
Mahalaga ang pagkakaibang ito para sa diagnosis. Ang pagkabigo ng DNS at ang na-filter na port ay parehong mukhang walang nangyari sa panig ng Jenkins, at parehong lumilitaw sa GitHub bilang nabigong paghahatid na may ibang kadahilanang nakalakip. Basahin ang kadahilanang iyon bago mo baguhin ang URL.
Ang isang tunnel na tumatawag palabas ay hindi gumagawa ng tagapakinig. Iyon ang bahaging inaasahan ng mga tao na gumana nang iba.
Tatlong paraan upang ayusin ang direksyon ng koneksyon
Binabago ng bawat solusyon kung sino ang nag-uumpisa ng koneksyon, at mayroon lamang tatlong hugis.
| 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 |
Ang polling ang pinakamababa sa kagandahan at pinakamadaling patakbuhin. Ang isang relay ay nagpapanatili ng halos agarang feedback nang hindi nagbubukas ng port. Ang isang runner ay karaniwang tamang sagot kapag ang pagiging lihim ng payload ay nagbubukod ng ikatlong partido, dahil ang trabaho ay maaaring tumakbo sa isang makina na nasa loob na ng network.
Pumili batay sa kung ano ang kaya mong patakbuhin, hindi batay sa kung ano ang tunog moderno.
Ipadala ang isang paghahatid palabas gamit ang smee
Gumawa ng channel sa serbisyo ng relay at itago ang URL nito. Sa loob ng network, i-install ang client at ipasa ang mga paghahatid sa landas na inaasahan ng Jenkins. Ang payload URL sa mga setting ng repository ay nagiging URL ng channel, na ang uri ng nilalaman ay nakatakda sa application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tatlong detalye ang nagpapasya kung ito ay gagana. Ang landas ay dapat tumugma sa inaasahan ng Jenkins para sa mga kaganapan ng GitHub, na bilang default ay /github-webhook/. Dapat makinig ang Jenkins sa port na ibinigay mo sa client. At ang Jenkins URL na naka-configure sa trabaho ay dapat sumang-ayon sa landas na iyon, kung hindi, darating ang kaganapan at pagkatapos ay itatapon.
Ang hindi pagtutugma ng trailing slash ay gumagawa ng 404 na parang nabigong paghahatid at hindi naman.
Patakbuhin ito upang mabuhay sa loob ng linggo
Ang isang client sa harapan ay namamatay kasama ng terminal, at ang mga webhook ay gumagana nang isang araw at pagkatapos ay humihinto. Bigyan ito ng unit na may Restart=always, patakbuhin ito bilang user ng Jenkins, at basahin ang journal pagkatapos ng unang tunay na paghahatid. Ang huling hakbang na iyon ang naghihiwalay sa gumaganang relay mula sa naka-configure.
[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.targetSubukan gamit ang tunay na push sa halip na replay button. Sinasanay ng replay ang naka-store na payload ng relay, hindi ang landas mula GitHub patungo sa iyong channel, kaya maaari itong pumasa habang nabibigo pa rin ang live na paghahatid.
Mag-alerto kapag huminto ang unit. Ang relay na down ay tahimik ayon sa konstruksyon, at ang katahimikan ang eksaktong dinadebug mo na.
Ano ang nakikita ng relay, at kailan hindi dapat gumamit ng isa
Tinatapos ng relay ang payload, kaya nakikita nito ang mga pangalan ng repository, datos ng commit at lahat ng iba pang dala ng kaganapan. Ituring ang URL ng channel bilang pampublikong endpoint. Panatilihing naka-configure ang secret token ng Jenkins upang tanggihan ang mga pekeng paghahatid, at limitahan ang token na ginagamit ng Jenkins sa pinakamababang kailangan.
Kung ang pagiging lihim ng payload ay nagbubukod niyon, isang self-hosted na runner o isang authenticated na reverse tunnel ang sagot.
Ang relay ay imprastraktura na ngayon, at karapat-dapat ito sa parehong pagsusuri gaya ng build na pinapagana nito. I-rotate ang channel kung ito ay tumagas, at itala ang petsa kung kailan mo huling na-verify ang isang live na paghahatid. Ilagay ang petsang iyon sa runbook sa tabi ng URL ng channel. Ang relay na walang nagrepaso sa loob ng isang taon ay isang pampublikong endpoint na walang nagmamay-ari.