Per què els webhooks de GitHub fan temps d’espera contra un Jenkins darrere una VPN
GitHub envia els webhooks cap endins, així que una VPN que protegeix Jenkins els rebutja. Reenvieu el lliurament cap a fora amb un relay o substituïu el webhook per un agent que faci sondejos.
La pàgina de lliurament mostra un temps d’espera i Jenkins no registra res, que és la signatura d’una connexió que mai no va arribar. GitHub envia un webhook com un HTTP POST de sortida des de la seva pròpia infraestructura cap a l’URL de payload que heu configurat. Una VPN protegeix Jenkins rebutjant exactament aquest tipus de connexió. No hi ha res trencat a cap dels dos costats. El problema és la direcció de la petició.
Què intenta realment el lliurament
GitHub resol el nom d’amfitrió de l’URL de payload i s’hi connecta des d’internet públic. Si aquest URL apunta a una adreça privada, o a un nom que només es resol dins de la vostra xarxa, l’intent falla abans que es faci cap petició. Si apunta a un nom públic que la vostra vora descarta, l’intent fa temps d’espera.
Aquesta distinció importa per al diagnòstic. Una fallada de DNS i un port filtrat semblen tots dos que no ha passat res a la banda de Jenkins, i tots dos apareixen a GitHub com un lliurament fallit amb un motiu diferent adjunt. Llegiu aquest motiu abans de canviar l’URL.
Un túnel que marca cap a fora no crea cap oient. Aquesta és la part que la gent espera que funcioni d’una altra manera.
Tres maneres d’arreglar la direcció de la connexió
Cada solució canvia qui inicia la connexió, i només hi ha tres formes.
| 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 |
El sondeig és el menys elegant i el més fàcil d’operar. Un relay manté retroalimentació gairebé instantània sense obrir cap port. Un runner sol ser la resposta correcta quan la confidencialitat del payload descarta un tercer, perquè la feina pot córrer en una màquina que ja és dins de la xarxa.
Trieu pel que podeu operar, no pel que sona modern.
Reenvieu un lliurament cap a fora amb smee
Creeu un canal al servei de relay i guardeu-ne l’URL. Dins de la xarxa, instal·leu el client i reenvieu els lliuraments al camí que Jenkins espera. L’URL de payload de la configuració del repositori es converteix en l’URL del canal, amb el tipus de contingut establert a application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tres detalls decideixen si funciona. El camí ha de coincidir amb el que Jenkins espera per als esdeveniments de GitHub, que per defecte és /github-webhook/. Jenkins ha d’escoltar al port que heu donat al client. I l’URL de Jenkins configurat a la feina ha de concordar amb aquest camí, o l’esdeveniment arriba i després es descarta.
Una barra final que no coincideix produeix un 404 que es llegeix com un lliurament fallit i no ho és.
Executar-lo de manera que sobrevisqui la setmana
Un client en primer pla mor amb el terminal, i els webhooks funcionen un dia i després s’aturen. Doneu-li una unit amb Restart=always, executeu-lo com a usuari Jenkins i llegiu el registre després del primer lliurament real. Aquest darrer pas és el que separa un relay funcional d’un de configurat.
[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.targetProveu amb un push real en lloc del botó de repetició. Una repetició executa el payload desat del relay, no el camí de GitHub al vostre canal, així que pot passar mentre el lliurament en directe encara falla.
Avisa quan la unit s’atura. Un relay caigut és silenciós per construcció, i el silenci és el que ja esteu depurant.
Què pot veure el relay, i quan no fer-lo servir
Un relay termina el payload, així que veu noms de repositoris, dades de commit i tot el que l’esdeveniment transporta. Tracteu l’URL del canal com un punt final públic. Mantingueu el token secret de Jenkins configurat perquè es rebutgin els lliuraments falsificats, i limiteu el token que fa servir Jenkins al mínim que necessita.
Si la confidencialitat del payload ho descarta, un runner autoallotjat o un túnel invers autenticat és la resposta.
Un relay ara és infraestructura, i mereix la mateixa revisió que la build que desencadena. Roteu el canal si es filtra, i anoteu la data en què vau verificar per darrera vegada un lliurament en directe. Posa aquesta data al runbook al costat de l’URL del canal. Un relay que ningú no ha revisat durant un any és un punt final públic que ningú no posseeix.