Wêrom GitHub-webhooks in time-out krije tsjin in Jenkins efter in VPN
GitHub stjoert webhooks nei binnen, dus in VPN dy’t Jenkins beskermet, wegeret se. Stjoer de levering nei bûten troch in relay, of ferfang de webhook troch in agent dy’t pollt.
De leveringsside toant in time-out en Jenkins logt neat, wat it skaaimerk is fan in ferbining dy’t nea oankaam. GitHub stjoert in webhook as in útgeande HTTP POST fan syn eigen ynfrastruktuer nei de payload-URL dy’t jo ynsteld hawwe. In VPN beskermet Jenkins troch krekt sa’n soarte ferbining te wegerjen. Oan gjinien kant is wat stikken. It probleem is de rjochting fan it fersyk.
Wat de levering eins besiket
GitHub lost de hostnamme yn ’e payload-URL op en ferbynt dêrmei fan it iepenbiere ynternet. As dy URL nei in privee adres wiist, of nei in namme dy’t allinnich binnen jo netwurk oplost, mislearret de poging foardat der in fersyk dien wurdt. As er nei in iepenbiere namme wiist dy’t jo râne ferdwynt, kriget de poging ynstee in time-out.
Dat ûnderskied is wichtich foar diagnose. In DNS-flater en in filtere poarte lykje beide as is der oan ’e Jenkins-kant neat bard, en beide ferskine op GitHub as in mislearre levering mei in oare reden derby. Lês dy reden foardat jo de URL feroarje.
In tunnel dy’t nei bûten syn oprop docht, makket gjin harker. Dat is it part dat minsken ferwachtsje oars te wurkjen.
Trije manieren om de rjochting fan ’e ferbining te reparearjen
Elke oplossing feroaret wa’t de ferbining begjint, en der binne mar trije foarmen.
| 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 |
Pollen is it minst elegante en it maklikst te betsjinjen. In relay hâldt hast fuortendaliks feedback sûnder in poarte te iepenjen. In runner is meastentiids it goede antwurd as payload-fjoulikheid in tredde partij útslút, om’t de taak rinne kin op in masine dy’t al binnen it netwurk stiet.
Kies op basis fan wat jo betsjinje kinne, net fan wat modern klinkt.
Stjoer in levering nei bûten troch mei smee
Meitsje in kanaal op ’e relay-tsjinst en hâld de URL dêrfan. Binnen it netwurk ynstallearje jo de kliïnt en stjoer leverings nei it paad dat Jenkins ferwachtet. De payload-URL yn ’e ynstellingen fan it repository wurdt de kanaal-URL, mei it ynhâldstype ynsteld op application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Trije details bepale oft it wurket. It paad moat oerienkomme mei wat Jenkins ferwachtet foar GitHub-eveneminten, wat standert /github-webhook/ is. Jenkins moat harkje op ’e poarte dy’t jo de kliïnt jûn hawwe. En de Jenkins-URL dy’t yn ’e taak ynsteld is, moat mei dat paad oerienkomme, oars komt it evenemint oan en wurdt it dêrnei fuortgoaid.
In oerstallige of ûntbrekkende skeaunline oan ’e ein jout in 404 dy’t as in mislearre levering lêzen wurdt en dat net is.
It sa draaie litte dat it de wike oerlibbet
In klient op ’e foargrûn stjert mei de terminal, en de webhooks wurkje in dei en stopje dan. Jou him in unit mei Restart=always, draai him as de Jenkins-brûker, en lês it journal nei de earste echte levering. Dy lêste stap is wat in wurkjende relay fan in ynstelde skiedt.
[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.targetTest mei in echte push ynstee fan in werhellingsknop. In werhelling beoefent de bewarre payload fan ’e relay, net it paad fan GitHub nei jo kanaal, dus it kin slagje wylst live levering noch mislearret.
Alarmearje as de unit stopt. In relay dy’t del is, is dat troch syn bou stil, en stilte is krekt wat jo al debugge.
Wat de relay sjen kin, en wannear’t jo der gjin ien brûke moatte
In relay beëiniget de payload, dus it sjocht repositorynammen, commit-gegevens en al wat it evenemint noch meidraacht. Behannelje de kanaal-URL as in iepenbier einpunt. Hâld it geheime token fan Jenkins ynsteld sadat ferfalske leverings wegere wurde, en behein it token dat Jenkins brûkt ta it needsaaklike minimum.
As payload-fjoulikheid dat útslút, is in selshosted runner of in autentisearre omkearde tunnel it antwurd.
In relay is no ynfrastruktuer, en it fertsjinnet deselde beoardieling as de build dy’t it útlokket. Ferwikselje it kanaal as it lekt, en skriuw de datum op wannear’t jo foar it lêst in live levering ferifiearre hawwe. Set dy datum yn ’e runbook njonken de kanaal-URL. In relay dy’t nimmen in jier beoardiele hat, is in iepenbier einpunt dat nimmen hat.