Zergatik GitHub-en webhook-ek denbora agortzen duten VPN baten atzeko Jenkins baten aurka
GitHub-ek webhook-ak barrualdera bidaltzen ditu, beraz Jenkins babesten duen VPN batek ukatzen ditu. Bidali entrega kanporantz relay baten bidez, edo ordezkatu webhook-a inkesta egiten duen agente batekin.
Entrega-orriak denbora-muga erakusten du eta Jenkins-ek ez du ezer erregistratzen, inoiz iritsi ez zen konexio baten seinalea da. GitHub-ek webhook bat HTTP POST irteerako gisa bidaltzen du bere azpiegituratik konfiguratu duzun payload URL-ra. VPN batek Jenkins babesten du hain zuzen horrelako konexioari uko eginez. Ez dago ezer hautsita inongo aldean. Eskaeraren norabidea da arazoa.
Zer saiatzen duen entrepak benetan
GitHub-ek payload URL-ko ostalari-izena ebazten du eta internet publikotik konektatzen da harekin. URL horrek helbide pribatu batera edo zure sarearen barruan soilik ebazten den izen batera seinalatzen badu, saiakerak huts egiten du eskaerarik egin aurretik. Zure ertzak baztertzen duen izen publiko batera seinalatzen badu, berriz, saiakerak denbora agortzen du.
Bereizketa hori garrantzitsua da diagnostikorako. DNS hutsegite batek eta portu iragazi batek biak dirudite Jenkins-en aldean ezer gertatu ez balitz bezala, eta biak agertzen dira GitHub-en huts egindako entrega gisa arrazoi desberdin bat erantsita. Irakurri arrazoi hori URL-a aldatu aurretik.
Kanporantz markatzen duen tunel batek ez du entzulerik sortzen. Jendeak desberdin funtzionatzea espero duen zatia da hori.
Konexioaren norabidea zuzentzeko hiru modu
Irtenbide bakoitzak aldatzen du nork hasten duen konexioa, eta hiru forma baino ez daude.
| 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 |
Inkesta da gutxien dotorea eta ustiatzeko errazena. Relay batek ia berehalako feedbacka mantentzen du porturik ireki gabe. Runner bat izan ohi da erantzun zuzena payload-aren konfidentzialtasunak hirugarren bat baztertzen duenean, zeren lana sarearen barruan dagoen makina batean exekuta baitaiteke.
Aukeratu ustiatu dezakezunaren arabera, ez moderno entzuten duenaren arabera.
Bidali entrega bat kanporantz smee-rekin
Sortu kanal bat relay zerbitzuan eta gorde haren URL-a. Sarearen barruan, instalatu bezeroa eta birbidali entregak Jenkins-ek espero duen bidera. Biltegiaren ezarpenetako payload URL-a kanalaren URL bihurtzen da, edukia mota application/json ezarrita.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Hiru xehetasunek erabakitzen dute funtzionatzen duen. Bideak bat etorri behar du Jenkins-ek GitHub gertaeretarako espero duenarekin, lehenespenez /github-webhook/ dena. Jenkins-ek bezeroari eman diozun portuan entzun behar du. Eta lanean konfiguratutako Jenkins URL-ak bide horrekin bat etorri behar du, bestela gertaera iritsi eta gero baztertu egiten da.
Amaierako barrak bat ez etortzeak 404 bat sortzen du, huts egindako entrega gisa irakurtzen dena eta hala ez dena.
Astea iraun dezan exekutatzea
Aurreko planoko bezero bat terminalarekin hiltzen da, eta webhook-ek egun bat funtzionatzen dute eta gero gelditu. Eman iezaiozu Restart=always duen unit bat, exekutatu Jenkins erabiltzaile gisa, eta irakurri journal-a lehen benetako entrega ondoren. Azken urrats horrek bereizten du funtzionatzen duen relay bat konfiguratutako batetik.
[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.targetProbatu push erreal batekin, erreproduzitzeko botoiarekin beharrean. Erreprodukzioak relay-ren gordetako payload-a erabiltzen du, ez GitHub-etik zure kanalara doan bidea, beraz pasea egin dezake zuzeneko entrega oraindik huts egiten duen bitartean.
Alerta ezarri unit-a gelditzen denean. Jaitsita dagoen relay bat isila da eraikuntzaz, eta isiltasuna da jada arazotzen ari zarena.
Zer ikus dezakeen relay-ek, eta noiz ez erabili bat
Relay batek payload-a amaitzen du, beraz biltegien izenak, commit datuak eta gertaerak daraman guztia ikusten du. Tratatu kanalaren URL-a amaiera-puntu publiko gisa. Euts iezaiozu Jenkins-en secret token-a konfiguratuta entrega faltsuak baztertzeko, eta mugatu Jenkins-ek erabiltzen duen token-a behar duen gutxienekora.
Payload-aren konfidentzialtasunak hori baztertzen badu, norberak ostatatutako runner bat edo autentifikatutako alderantzizko tunel bat da erantzuna.
Relay bat azpiegitura da orain, eta abiarazten duen build-ak beste berrikuspen merezi du. Errotatu kanala filtratzen bada, eta idatzi zuzeneko entrega bat azken aldiz egiaztatu zenuen data. Jarri data hori runbook-ean kanalaren URL-aren ondoan. Inork urtebetez berrikusi ez duen relay bat inork jabetzen ez duen amaiera-puntu publikoa da.