Miksi GitHub-webhookit aikakatkeavat VPN:n takana olevaa Jenkinsiä vastaan
GitHub lähettää webhookit sisäänpäin, joten Jenkinsiä suojaava VPN hylkää ne. Ohjaa toimitus ulospäin relayn kautta tai korvaa webhook agentilla, joka kyselyttää.
Toimitussivu näyttää aikakatkaisun eikä Jenkins kirjaa mitään, mikä on merkki yhteydestä, joka ei koskaan saapunut. GitHub lähettää webhookin lähtevänä HTTP POSTina omasta infrastruktuuristaan määrittämääsi payload URL-osoitteeseen. VPN suojaa Jenkinsiä hylkäämällä juuri sellaisen yhteyden. Kummallakaan puolella ei ole mitään rikki. Ongelma on pyynnön suunnassa.
Mitä toimitus itse asiassa yrittää
GitHub selvittää payload URL-osoitteen isäntänimen ja yhdistää siihen julkisesta internetistä. Jos osoite viittaa yksityiseen osoitteeseen tai nimeen, joka selvitetään vain verkkosi sisällä, yritys epäonnistuu ennen kuin yhtään pyyntöä tehdään. Jos se viittaa julkiseen nimeen, jonka reunasi pudottaa, yritys sen sijaan aikakatkeaa.
Tällä erolla on merkitystä diagnoosiin. DNS-virhe ja suodatettu portti näyttävät molemmat siltä, ettei Jenkinsin puolella tapahtunut mitään, ja molemmat näkyvät GitHubissa epäonnistuneena toimituksena, johon on liitetty eri syy. Lue se syy ennen kuin muutat URL-osoitetta.
Ulospäin soittava tunneli ei luo kuuntelijaa. Juuri tämän osan ihmiset odottavat toimivan toisin.
Kolme tapaa korjata yhteyden suunta
Jokainen ratkaisu muuttaa sitä, kuka aloittaa yhteyden, ja muotoja on vain kolme.
| 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 |
Kysely on vähiten tyylikäs ja helpoin ylläpitää. Relay pitää lähes välittömän palautteen avaamatta porttia. Runner on yleensä oikea vastaus, kun payloadin luottamuksellisuus sulkee pois kolmannen osapuolen, koska työ voi ajaa koneella, joka on jo verkon sisällä.
Valitse sen mukaan, mitä pystyt ylläpitämään, älä sen mukaan, mikä kuulostaa modernilta.
Ohjaa toimitus ulospäin smeen avulla
Luo kanava relay-palveluun ja säilytä sen URL. Asenna asiakas verkon sisällä ja välitä toimitukset polulle, jota Jenkins odottaa. Repositorion asetuksissa oleva payload URL-osoite muuttuu kanavan URL-osoitteeksi, ja sisältötyypiksi asetetaan application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Kolme yksityiskohtaa ratkaisee, toimiiko se. Polun on vastattava sitä, mitä Jenkins odottaa GitHub-tapahtumille, mikä on oletuksena /github-webhook/. Jenkinsin on kuunneltava porttia, jonka annoit asiakkaalle. Ja työssä määritetyn Jenkins URL-osoitteen on sovittava yhteen tuon polun kanssa, muuten tapahtuma saapuu ja hylätään sitten.
Lopun vinoviivan eroavuus tuottaa 404:n, joka luetaan epäonnistuneeksi toimitukseksi, vaikka ei ole sitä.
Ajaminen niin, että se kestää viikon
Etuplan asiakas kuolee päätteen mukana, ja webhookit toimivat päivän ja pysähtyvät sitten. Anna sille unit, jossa on Restart=always, aja se Jenkins-käyttäjänä ja lue journal ensimmäisen oikean toimituksen jälkeen. Juuri se viimeinen vaihe erottaa toimivan relayn määritetystä.
[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.targetTestaa oikealla pushilla äläkä toistopainikkeella. Toisto harjoittaa relayn tallennettua payloadia, ei polkua GitHubista kanavaasi, joten se voi mennä läpi, vaikka live-toimitus yhä epäonnistuu.
Hälytä, kun unit pysähtyy. Alas oleva relay on rakenteellisesti hiljainen, ja hiljaisuus on juuri se, mitä jo debuggaat.
Mitä relay voi nähdä ja milloin sitä ei pidä käyttää
Relay päättää payloadin, joten se näkee repositorioiden nimet, commit-tiedot ja kaiken muun, mitä tapahtuma kantaa. Kohtele kanavan URL-osoitetta julkisena päätepisteenä. Pidä Jenkinsin salainen token määritettynä, jotta väärennetyt toimitukset hylätään, ja rajaa Jenkinsin käyttämä token tarpeelliseen minimiin.
Jos payloadin luottamuksellisuus sulkee sen pois, itse ylläpidetty runner tai todennettu käänteinen tunneli on vastaus.
Relay on nyt infrastruktuuria ja ansaitsee saman tarkastelun kuin build, jonka se käynnistää. Vaihda kanava, jos se vuotaa, ja merkitse päivä, jolloin viimeksi vahvistit live-toimituksen. Laita se päivä runbookiin kanavan URL-osoitteen viereen. Relay, jota kukaan ei ole tarkastellut vuoteen, on julkinen päätepiste, jota kukaan ei omista.