Zakaj webhooki GitHub potečejo proti Jenkinsu za VPN

Stran dostave prikaže potek časa in Jenkins ne zabeleži ničesar, kar je podpis povezave, ki nikoli ni prispela. GitHub pošlje webhook kot odhodni HTTP POST iz svoje lastne infrastrukture na payload URL, ki ste ga nastavili. VPN ščiti Jenkins tako, da zavrača natanko takšno vrsto povezave. Na nobeni strani ni nič pokvarjeno. Težava je v smeri zahteve.

Kaj dostava pravzaprav poskuša

GitHub razreši ime gostitelja v payload URL in se nanj poveže z javnega interneta. Če ta URL kaže na zasebni naslov ali na ime, ki se razreši samo znotraj vašega omrežja, poskus spodleti, preden je poslana kakršna koli zahteva. Če kaže na javno ime, ki ga vaš rob zavrže, poskus namesto tega poteče.

Ta razlika je pomembna za diagnostiko. Napaka DNS in filtrirana vrata sta videti, kot da se na strani Jenkinsa ni zgodilo nič, in oboje se v GitHubu prikaže kot neuspešna dostava z drugim priloženim razlogom. Preberite ta razlog, preden spremenite URL.

Predor, ki kliče navzven, ne ustvari poslušalca. Prav tega dela ljudje pričakujejo, da bo deloval drugače.

Trije načini, kako popraviti smer povezave

Vsaka rešitev spremeni, kdo začne povezavo, in obstajajo le tri oblike.

Poizvedovanje je najmanj elegantno in najlažje za upravljanje. Relay ohranja skoraj takojšnjo povratno informacijo, ne da bi odprl vrata. Runner je običajno pravi odgovor, ko zaupnost payloada izključuje tretjo stran, ker lahko opravilo teče na stroju, ki že stoji znotraj omrežja.

Izberite glede na to, kar lahko upravljate, ne glede na to, kar zveni moderno.

Preusmerite dostavo navzven s smee

Ustvarite kanal v storitvi relay in shranite njegov URL. Znotraj omrežja namestite odjemalca in posredujte dostave na pot, ki jo Jenkins pričakuje. Payload URL v nastavitvah repozitorija postane URL kanala, vrsta vsebine pa je nastavljena na application/json.

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

Tri podrobnosti odločajo, ali deluje. Pot se mora ujemati s tem, kar Jenkins pričakuje za dogodke GitHub, kar je privzeto /github-webhook/. Jenkins mora poslušati na vratih, ki ste jih dali odjemalcu. In Jenkins URL, nastavljen v opravilu, se mora ujemati s to potjo, sicer dogodek prispe in je nato zavržen.

Neujemanje končne poševnice ustvari 404, ki se bere kot neuspešna dostava in ni.

Izvajanje tako, da preživi teden

Odjemalec v ospredju umre s terminalom in webhooki delujejo en dan, nato se ustavijo. Dajte mu unit z Restart=always, zaženite ga kot uporabnik Jenkins in po prvi resnični dostavi preberite journal. Prav ta zadnji korak loči delujoč relay od nastavljenega.

[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

Testirajte s pravim push, ne z gumbom za predvajanje. Predvajanje izvaja shranjeni payload relayja, ne poti od GitHuba do vašega kanala, zato lahko uspe, medtem ko dostava v živo še vedno spodleti.

Alarmirajte, ko se unit ustavi. Relay, ki je padel, je po zgradbi tih, in tišina je natanko tisto, kar že odpravljate.

Kaj relay lahko vidi in kdaj ga ne uporabiti

Relay zaključi payload, zato vidi imena repozitorijev, podatke o commitu in vse drugo, kar dogodek nosi. Obravnavajte URL kanala kot javno končno točko. Ohranite skrivnostni token Jenkinsa nastavljen, da se ponarejene dostave zavrnejo, in omejite token, ki ga Jenkins uporablja, na potreben minimum.

Če zaupnost payloada to izključuje, samogostujoči runner ali overjen obratni predor je odgovor.

Relay je zdaj infrastruktura in si zasluži enak pregled kot build, ki ga sproži. Zavrtite kanal, če pušča, in zapišite datum, ko ste nazadnje preverili dostavo v živo. Ta datum postavite v runbook poleg URL kanala. Relay, ki ga nihče ni pregledal eno leto, je javna končna točka, ki ni v lasti nikogar.