Miért fut időtúllépésbe a GitHub webhook egy VPN mögötti Jenkins felé
A GitHub a webhookokat befelé küldi, ezért a Jenkinset védő VPN elutasítja őket. Tolja ki a kézbesítést egy relayen keresztül, vagy cserélje le a webhookot egy lekérdező agentre.
A kézbesítési oldal időtúllépést mutat, és a Jenkins semmit nem naplóz, ami egy soha meg nem érkezett kapcsolat jele. A GitHub a webhookot kimenő HTTP POSTként küldi a saját infrastruktúrájából a beállított payload URL-re. A VPN úgy védi a Jenkinst, hogy éppen az ilyen kapcsolatot utasítja el. Egyik oldalon sem tört el semmi. A probléma a kérés iránya.
Mit próbál valójában a kézbesítés
A GitHub feloldja a payload URL hosztnevét, és a nyilvános internetről kapcsolódik hozzá. Ha az az URL privát címre mutat, vagy olyan névre, amely csak a hálózatán belül oldódik fel, a kísérlet még azelőtt meghiúsul, hogy bármilyen kérés elindulna. Ha olyan nyilvános névre mutat, amelyet az éle kiejt, a kísérlet helyette időtúllépésbe fut.
Ez a különbség a diagnózis szempontjából számít. A DNS-hiba és a szűrt port egyaránt úgy néz ki, mintha a Jenkins oldalán semmi nem történt volna, és mindkettő sikertelen kézbesítésként jelenik meg a GitHubon, más-más okkal. Olvassa el azt az okot, mielőtt módosítja az URL-t.
A kifelé tárcsázó alagút nem hoz létre figyelőt. Pontosan ezt a részt várják az emberek másként működni.
Három mód a kapcsolat irányának javítására
Minden megoldás megváltoztatja, ki indítja a kapcsolatot, és csak három forma létezik.
| 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 |
A lekérdezés a legkevésbé elegáns és a legkönnyebben üzemeltethető. A relay közel azonnali visszajelzést tart fenn anélkül, hogy portot nyitna. A runner általában a helyes válasz, amikor a payload bizalmassága kizárja a harmadik felet, mert a feladat olyan gépen futhat, amely már a hálózaton belül van.
Aszerint válasszon, mit tud üzemeltetni, nem aszerint, mi hangzik modernnek.
Tolja ki a kézbesítést a smee segítségével
Hozzon létre egy csatornát a relay szolgáltatásban, és őrizze meg az URL-jét. A hálózaton belül telepítse a klienst, és továbbítsa a kézbesítéseket arra az útvonalra, amelyet a Jenkins elvár. A repozitórium beállításaiban szereplő payload URL lesz a csatorna URL-je, a tartalomtípus pedig application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Három részlet dönti el, működik-e. Az útvonalnak meg kell egyeznie azzal, amit a Jenkins a GitHub-eseményekhez elvár, ami alapértelmezésben /github-webhook/. A Jenkinsnek azon a porton kell figyelnie, amelyet a kliensnek adott. És a feladatban beállított Jenkins URL-nek egyeznie kell ezzel az útvonallal, különben az esemény megérkezik, majd eldobódik.
A záró perjel eltérése 404-et eredményez, amely sikertelen kézbesítésnek látszik, de nem az.
Úgy futtatni, hogy kibírja a hetet
Az előtérben futó kliens meghal a terminállal, és a webhookok egy napig működnek, majd leállnak. Adjon neki egy unitot Restart=always beállítással, futtassa Jenkins-felhasználóként, és az első valódi kézbesítés után olvassa el a journalt. Ez az utolsó lépés választja el a működő relayt a beállítottól.
[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.targetValódi push-sal teszteljen az újrajátszás gomb helyett. Az újrajátszás a relay tárolt payloadját gyakorolja, nem a GitHubtól a csatornáig vezető utat, ezért átmehet, miközben az élő kézbesítés még mindig meghiúsul.
Riasztást, amikor a unit leáll. A leállt relay a felépítésénél fogva csendes, és a csend az, amit már most is hibakeres.
Mit láthat a relay, és mikor ne használjon egyet
A relay lezárja a payloadot, így látja a repozitóriumneveket, a commit-adatokat és mindent, amit az esemény hordoz. Kezelje a csatorna URL-jét nyilvános végpontként. Tartsa beállítva a Jenkins titkos tokenjét, hogy a hamisított kézbesítések elutasításra kerüljenek, és korlátozza a Jenkins által használt tokent a szükséges minimumra.
Ha a payload bizalmassága ezt kizárja, egy saját üzemeltetésű runner vagy egy hitelesített fordított alagút a válasz.
A relay ma már infrastruktúra, és ugyanazt a felülvizsgálatot érdemli, mint a build, amelyet kivált. Forgassa a csatornát, ha kiszivárog, és jegyezze fel a dátumot, amikor utoljára ellenőrzött egy élő kézbesítést. Tegye ezt a dátumot a runbookba a csatorna URL-je mellé. Az a relay, amelyet senki nem vizsgált felül egy évig, olyan nyilvános végpont, amelynek nincs gazdája.