Kial GitHub-webhookoj tempas el kontraŭ Jenkins malantaŭ VPN
GitHub sendas webhookojn enen, do VPN, kiu protektas Jenkins, rifuzas ilin. Plusendu la liveron eksteren per relay, aŭ anstataŭigu la webhookon per agento, kiu enketas.
La livera paĝo montras tempolimon kaj Jenkins registras nenion, kio estas la signo de konekto, kiu neniam alvenis. GitHub sendas webhookon kiel eliran HTTP POST el sia propra infrastrukturo al la payload URL, kiun vi agordis. VPN protektas Jenkins rifuzante ĝuste tian konekton. Nenio estas rompita ĉe iu ajn flanko. La problemo estas la direkto de la peto.
Kion la livero efektive provas
GitHub solvas la gastigantnomon en la payload URL kaj konektas al ĝi el la publika interreto. Se tiu URL montras al privata adreso, aŭ al nomo, kiu solviĝas nur ene de via reto, la provo malsukcesas antaŭ ol iu peto estas farita. Se ĝi montras al publika nomo, kiun via rando forĵetas, la provo anstataŭe tempas el.
Tiu distingo gravas por diagnozo. DNS-malsukceso kaj filtrita pordo ambaŭ aspektas kvazaŭ nenio okazis ĉe la flanko de Jenkins, kaj ambaŭ aperas en GitHub kiel malsukcesa livero kun alia kialo alkroĉita. Legu tiun kialon antaŭ ol ŝanĝi la URL.
Tunelo, kiu alvokas eksteren, ne kreas aŭskultanton. Ĝuste tion homoj atendas funkcii alimaniere.
Tri manieroj ripari la direkton de la konekto
Ĉiu solvo ŝanĝas, kiu iniciatas la konekton, kaj ekzistas nur tri formoj.
| 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 |
Enketado estas la plej negracia kaj la plej facila por funkciigi. Relay tenas preskaŭ tujan reagon sen malfermi pordon. Runner kutime estas la ĝusta respondo, kiam konfidenco de la payload ekskludas trian partion, ĉar la tasko povas kuri sur maŝino, kiu jam staras ene de la reto.
Elektu laŭ tio, kion vi povas funkciigi, ne laŭ tio, kio sonas moderna.
Plusendu liveron eksteren per smee
Kreu kanalon ĉe la relay-servo kaj konservu ĝian URL. Ene de la reto, instalu la klienton kaj plusendu liverojn al la vojo, kiun Jenkins atendas. La payload URL en la deponejaj agordoj fariĝas la URL de la kanalo, kun la enhavtipo agordita al application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Tri detaloj decidas, ĉu ĝi funkcias. La vojo devas kongrui kun tio, kion Jenkins atendas por GitHub-eventoj, kio defaŭlte estas /github-webhook/. Jenkins devas aŭskulti sur la pordo, kiun vi donis al la kliento. Kaj la Jenkins URL agordita en la tasko devas kongrui kun tiu vojo, alie la evento alvenas kaj poste estas forĵetata.
Miskongruo de fina oblikvo produktas 404, kiu legiĝas kiel malsukcesa livero kaj ne estas.
Funkciigi ĝin tiel, ke ĝi postvivu la semajnon
Kliento en la malfono mortas kun la terminalo, kaj la webhookoj funkcias unu tagon kaj poste haltas. Donu al ĝi unit kun Restart=always, rulu ĝin kiel uzanto Jenkins, kaj legu la ĵurnalon post la unua vera livero. Ĝuste tiu lasta paŝo apartigas funkciantan relay de agordita.
[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.targetTestu per vera push anstataŭ per ripeta butono. Ripeto ekzercas la konservitan payload de la relay, ne la vojon de GitHub al via kanalo, do ĝi povas pasi dum la viva livero ankoraŭ malsukcesas.
Alarmu, kiam la unit haltas. Relay, kiu estas malsupre, estas silenta laŭ konstruo, kaj silento estas ĝuste tio, kion vi jam sencimigas.
Kion la relay povas vidi, kaj kiam ne uzi unu
Relay finigas la payload, do ĝi vidas deponejajn nomojn, commit-datumojn kaj ĉion alian, kion la evento portas. Traktu la URL de la kanalo kiel publikan finpunkton. Tenu la sekretan token de Jenkins agordita, por ke falsitaj liveroj estu rifuzitaj, kaj limigu la token, kiun Jenkins uzas, al la minimuma bezonata.
Se konfidenco de la payload ekskludas tion, memhostigita runner aŭ aŭtentikigita inversa tunelo estas la respondo.
Relay estas nun infrastrukturo, kaj ĝi meritas la saman revizion kiel la build, kiun ĝi ekigas. Rotaciu la kanalon, se ĝi likas, kaj notu la daton, kiam vi laste kontrolis vivan liveron. Metu tiun daton en la runbook apud la URL de la kanalo. Relay, kiun neniu reviziis dum jaro, estas publika finpunkto, kiun neniu posedas.