Zašto GitHub webhookovi istječu prema Jenkinsu iza VPN-a

Stranica isporuke prikazuje istek vremena, a Jenkins ne bilježi ništa, što je potpis veze koja nikada nije stigla. GitHub šalje webhook kao odlazni HTTP POST iz vlastite infrastrukture na payload URL koji ste konfigurisali. VPN štiti Jenkins odbijajući upravo takvu vrstu veze. Ništa nije pokvareno ni na jednoj strani. Problem je u smjeru zahtjeva.

Šta isporuka zapravo pokušava

GitHub razrješava ime hosta u payload URL-u i povezuje se s njim s javnog interneta. Ako taj URL pokazuje na privatnu adresu ili na ime koje se razrješava samo unutar vaše mreže, pokušaj propada prije nego što se pošalje bilo kakav zahtjev. Ako pokazuje na javno ime koje vaš rub odbaci, pokušaj umjesto toga istječe.

Ta razlika je važna za dijagnostiku. DNS neuspjeh i filtrirani port izgledaju isto kao da se na strani Jenkinsa ništa nije dogodilo, i oboje se na GitHubu pojavljuje kao neuspjela isporuka s drugim razlogom. Pročitajte taj razlog prije nego što promijenite URL.

Tunel koji se spaja prema van ne stvara slušaoca. Upravo taj dio ljudi očekuju da radi drugačije.

Tri načina da popravite smjer veze

Svako rješenje mijenja ko započinje vezu, a postoje samo tri oblika.

Anketiranje je najmanje elegantno i najlakše za upravljanje. Relay održava gotovo trenutnu povratnu informaciju bez otvaranja porta. Runner je obično pravi odgovor kada povjerljivost payloada isključuje treću stranu, jer posao može raditi na mašini koja već stoji unutar mreže.

Birajte prema tome šta možete upravljati, a ne prema tome šta zvuči moderno.

Proslijedite isporuku prema van pomoću smee

Napravite kanal na relay servisu i sačuvajte njegov URL. Unutar mreže instalirajte klijenta i prosljeđujte isporuke na putanju koju Jenkins očekuje. Payload URL u postavkama repozitorija postaje URL kanala, s tipom sadržaja postavljenim na application/json.

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

Tri detalja odlučuju hoće li raditi. Putanja mora odgovarati onome što Jenkins očekuje za GitHub događaje, a to je po zadanom /github-webhook/. Jenkins mora slušati na portu koji ste predali klijentu. I Jenkins URL konfigurisan u poslu mora se slagati s tom putanjom, inače događaj stigne i zatim bude odbačen.

Neusklađenost završne kose crte proizvodi 404 koji se čita kao neuspjela isporuka, a to nije.

Pokretanje tako da preživi sedmicu

Klijent u prvom planu umire s terminalom, i webhookovi rade jedan dan pa stanu. Dajte mu unit s Restart=always, pokrenite ga kao korisnik Jenkins i pročitajte dnevnik nakon prve stvarne isporuke. Upravo taj posljednji korak razdvaja relay koji radi od konfigurisanog.

[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 stvarnim pushom, a ne dugmetom za ponavljanje. Ponavljanje izvodi pohranjeni payload relayja, a ne putanju od GitHuba do vašeg kanala, pa može proći dok stvarna isporuka još uvijek ne uspijeva.

Postavite upozorenje kada se unit zaustavi. Relay koji je pao tih je po konstrukciji, a tišina je upravo ono što već otklanjate.

Šta relay može vidjeti i kada ga ne koristiti

Relay terminira payload, pa vidi nazive repozitorija, podatke o commitu i sve ostalo što događaj nosi. Tretirajte URL kanala kao javnu krajnju tačku. Držite Jenkins secret token konfigurisan da se lažne isporuke odbiju, i ograničite token koji Jenkins koristi na minimum koji mu treba.

Ako povjerljivost payloada to isključuje, self-hosted runner ili autentificiran obrnuti tunel je odgovor.

Relay je sada infrastruktura i zaslužuje isti pregled kao build koji pokreće. Rotirajte kanal ako procuri i zabilježite datum kada ste posljednji put provjerili stvarnu isporuku. Stavite taj datum u runbook pored URL-a kanala. Relay koji nitko nije pregledao godinu dana javna je krajnja tačka koju nitko ne posjeduje.