Por que os webhooks de GitHub esgotan o tempo contra un Jenkins detrás dunha VPN
GitHub envía os webhooks cara a dentro, así que unha VPN que protexe Jenkins rexeitaos. Reenvía a entrega cara a fóra cun relay ou substitúe o webhook por un axente que faga sondaxe.
A páxina de entrega mostra un tempo de espera e Jenkins non rexistra nada, que é a sinatura dunha conexión que nunca chegou. GitHub envía un webhook como un HTTP POST de saída desde a súa propia infraestrutura cara ao URL de payload que configurases. Unha VPN protexe Jenkins rexeitando exactamente ese tipo de conexión. Nada está roto en ningún dos dous lados. O problema é a dirección da petición.
Que intenta realmente a entrega
GitHub resolve o nome de host no URL de payload e conéctase a el desde internet público. Se ese URL apunta a un enderezo privado, ou a un nome que só se resolve dentro da túa rede, o intento falla antes de que se faga ningunha petición. Se apunta a un nome público que a túa borde descarta, o intento esgota o tempo no seu lugar.
A distinción importa para o diagnóstico. Un fallo de DNS e un porto filtrado parecen ambos que non pasou nada no lado de Jenkins, e ambos aparecen en GitHub como unha entrega fallida cun motivo distinto anexado. Le ese motivo antes de cambiar o URL.
Un túnel que marca cara a fóra non crea un escoitador. Esa é a parte que a xente espera que funcione doutra maneira.
Tres formas de corrixir a dirección da conexión
Cada solución cambia quen inicia a conexión, e só hai tres formas.
| 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 sondaxe é a menos elegante e a máis fácil de operar. Un relay mantén retroalimentación case instantánea sen abrir un porto. Un runner adoita ser a resposta correcta cando a confidencialidade do payload descarta un terceiro, porque o traballo pode executarse nunha máquina que xa está dentro da rede.
Escolle polo que podes operar, non polo que soa moderno.
Reenvía unha entrega cara a fóra con smee
Crea unha canle no servizo de relay e garda o seu URL. Dentro da rede, instala o cliente e reenvía as entregas á ruta que Jenkins espera. O URL de payload nos axustes do repositorio convértese no URL da canle, co tipo de contido establecido en application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tres detalles deciden se funciona. A ruta debe coincidir co que Jenkins espera para os eventos de GitHub, que por defecto é /github-webhook/. Jenkins debe estar escoitando no porto que lle deches ao cliente. E o URL de Jenkins configurado no traballo ten que concordar con esa ruta, ou o evento chega e logo descártase.
Unha barra final que non coincide produce un 404 que se le como unha entrega fallida e non o é.
Executalo de xeito que sobreviva á semana
Un cliente en primeiro plano morre co terminal, e os webhooks funcionan un día e logo detéñense. Dálle unha unit con Restart=always, execútaa como o usuario Jenkins e le o journal despois da primeira entrega real. Ese último paso é o que separa un relay que funciona dun configurado.
[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.targetProba cun push real en lugar do botón de repetición. Unha repetición exercita o payload almacenado do relay, non o camiño de GitHub á túa canle, así que pode pasar mentres a entrega en vivo segue fallando.
Avisa cando a unit se deteña. Un relay caído é silencioso por construción, e o silencio é xusto o que xa estás depurando.
Que pode ver o relay e cando non usalo
Un relay termina o payload, así que ve nomes de repositorios, datos de commit e todo o demais que leva o evento. Trata o URL da canle como un punto final público. Mantén configurado o token secreto de Jenkins para que se rexeiten as entregas falsificadas, e limita o token que usa Jenkins ao mínimo que necesita.
Se a confidencialidade do payload o descarta, un runner autoaloxado ou un túnel inverso autenticado é a resposta.
Un relay agora é infraestrutura, e merece a mesma revisión que a build que dispara. Rota a canle se se filtra e anota a data en que verificaches por última vez unha entrega en vivo. Pon esa data no runbook xunto ao URL da canle. Un relay que ninguén revisou durante un ano é un punto final público que ninguén posúe.