GitHub-webhook ne atingas privatan Jenkins: riparu la vojon
VPN-sesio sur via tekkomputilo ne donas al GitHub vojon en Jenkins. Komparu envenan finpunkton, relajson kaj enketadon, poste testu la vojon, kiun la eventoj sekvas.
Vi povas malfermi Jenkins per la VPN kaj tamen vidi, ke GitHub raportas malsukcesan webhook, ĉar temas pri du malsamaj konektoj kun du malsamaj posedantoj. La retumilo veturas tra tunelo, kiun intertraktis via tekkomputilo; la livera servo de GitHub komenciĝas en la publika interreto kaj havas neniun vojon en la privatan reton. Aliro al la deponejo tion ne ŝanĝas, eĉ se Jenkins mem povas senprobleme elpreni el la sama deponejo. Elektu envenan punkton, relajson aŭ enketadon, poste testu la vojon, kiun la evento efektive sekvas.
Retumila sesio pruvas nur unu direkton
VPN-konekto respondas al unu demando: ĉu ĉi tiu tekkomputilo povas atingi la internan gastiganton. Liverado de webhook demandas alian: ĉu ekstera servo povas malfermi konekton al tiu gastiganto. Elpreno de deponejo fare de Jenkins estas elira trafiko kaj diras nenion pri enira atingeblo. Tenu ambaŭ direktojn sur apartaj linioj en via diagramo, inkluzive de tiu flanko, kiu komencas ĉiun.
Legi la liveran registron antaŭ ol ŝanĝi ion ajn. Timeout, restarigo de konekto kaj akceptita peto, kiu kongruis kun neniu tasko, havas tri malsamajn posedantojn: reton, prokuron kaj agordan konfiguradon.
Opcio A: elmeti mallarĝan finpunkton
Se la organizo jam publikigas aprobitan envenan punkton, elmetu la webhook-vojon anstataŭ la regpanelo. Tio kutime signifas regulon de inversa prokuro, kiu akceptas POST en la hoka URL kaj plusendas ilin al Jenkins, dum la administra interfaco restas neatingebla de ekstere.
curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/Rulu tiun teston el reto sen VPN-aliro, ĉar sukceso el interne de la tunelo pruvas nenion. La finpunkto devus malakcepti petojn sen la komuna sekreto, kiun GitHub sendas kiel subskriban kaplinion, kaj akcepti nur la ununuran vojon kaj metodon, kiujn vi publikigis. Publika Jenkins-konzolo ne estas webhook-riparo; ĝi estas incidento atendanta la sekvan skanilon. Limigu la regulon sufiĉe strikte, por ke la resto de la aplikaĵo konservu la alirkontrolojn, kiujn ĝi havis.
Opcio B: inversigi la direkton per relajso
Tie, kie envena elmeto ne estos aprobita, malgranda kliento ene de la reto povas teni eliran konekton al relajso kaj ricevi plusenditajn eventojn. La relajso tiam fariĝas parto de la livera vojo, do ĝia disponebleco kaj aŭtentigo gravas same kiel la konstrua tasko.
ssh -N -R 9000:localhost:8080 relay.example.netLa gvidilo de Jenkins pri webhook malantaŭ fajroŝirmiloj priskribas ĉi tiun formon, kaj indas legi ĝin antaŭ ol verki propran plusendilon. Finkondu TLS ĉe la relajso, kontrolu la subskribon antaŭ ol la evento atingos la taskon, kaj observu la eliran ligilon, ĉar falinta tunelo aspektas ĝuste kiel evento, kiu neniam estis sendita. Konfirmu ankaŭ, ke la relajso konservas la petan korpon bajte post bajte, ĉar subskribaj kontroloj malsukcesas ĉe JSON, kiu estis analizita kaj rekodita survoje.
Opcio C: anstataŭe enketi la deponejon
Enketado interŝanĝas latentan tempon kontraŭ simpleco kaj tute ne bezonas eniran vojon. Jenkins povas enketi laŭ horaro, aŭ malgranda tasko povas demandi la API kaj startigi konstruon, kiam ĝi vidas nekonatan revizion.
curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"Ĉiu enketo elspezas API-alvokojn kaj aldonas prokraston inter push kaj konstruo, kio videblas en okupataj deponejoj kaj dividitaj rapidolimoj. Ĝi ankaŭ bezonas akreditaĵojn konservitajn tie, kie ajn la enketilo funkcias, do limigu la ĵetonon al nurlega aliro al la deponejo kaj rotaciu ĝin kiel ĉiun alian sekreton. Elektu ĉi tion, kiam la evento-kvanto estas malalta aŭ kiam neniu envena punkto iam estos aprobita, kaj diru tion en la priskribo de la tasko, por ke neniu poste demandu, kial konstruoj malfruas.
Akceptu veran liveradon, ne paĝan ŝarĝon
Kiun ajn opcion vi elektis, la akcepta testo estas evento sendita de la fonta platformo, ne retumila langeto malfermita de privilegia tekkomputilo. Puŝu malplenan commit al proviza branĉo kaj legu la respondan kodon de la liverado, la protokolon de la relajso aŭ la eligon de la enketa tasko, en tiu ordo. Respondo 200 de la finpunkto sen konstruo signifas, ke la agorda filtrilo estas malĝusta; timeout signifas, ke la vojo ankoraŭ estas fermita. Notu, kiu el la tri dezajnoj estas uzata, ĉar alie la sekva persono, kiu sencimigos, ripetos la retumilan teston kaj atingos la saman sakstraton.
Apliku la saman rezonadon al pagaj resalvokoj kaj aliaj eksteraj sciigoj: ĉiu bezonas sian propran vojon en la privatan aplikaĵon, eĉ kiam ĉiu homo jam havas VPN-sesion. La livera vojo apartenas al la dezajno de la aplikaĵo, ne al piednoto pri retoj.