Kāpēc GitHub webhook beidzas ar taimautu pret Jenkins aiz VPN

Piegādes lapa rāda taimautu, un Jenkins neko nefiksē, kas ir pazīme savienojumam, kurš tā arī nenonāca. GitHub sūta webhook kā izejošu HTTP POST no savas infrastruktūras uz jūsu konfigurēto payload URL. VPN aizsargā Jenkins, noraidot tieši šāda veida savienojumu. Nevienā pusē nekas nav salūzis. Problēma ir pieprasījuma virzienā.

Ko piegāde faktiski mēģina

GitHub atrisina payload URL esošo resursdatora nosaukumu un pieslēdzas tam no publiskā interneta. Ja šis URL norāda uz privātu adresi vai uz nosaukumu, kas atrisinās tikai jūsu tīklā, mēģinājums neizdodas, pirms tiek nosūtīts jebkurš pieprasījums. Ja tas norāda uz publisku nosaukumu, ko jūsu mala izmet, mēģinājums tā vietā beidzas ar taimautu.

Šī atšķirība ir svarīga diagnostikai. DNS kļūme un filtrēts ports abi izskatās tā, it kā Jenkins pusē nekas nebūtu noticis, un abi GitHub parādās kā neveiksmīga piegāde ar citu pievienotu iemeslu. Izlasiet šo iemeslu pirms URL maiņas.

Tunelis, kas zvana uz āru, neveido klausītāju. Tieši šo daļu cilvēki sagaida strādājam citādi.

Trīs veidi, kā izlabot savienojuma virzienu

Katrs risinājums maina to, kas uzsāk savienojumu, un ir tikai trīs formas.

Aptauja ir vismazāk eleganta un visvieglāk pārvaldāma. Relay nodrošina gandrīz tūlītēju atgriezenisko saiti, neatverot portu. Runner parasti ir pareizā atbilde, ja payload konfidencialitāte izslēdz trešo pusi, jo darbs var darboties mašīnā, kas jau atrodas tīkla iekšpusē.

Izvēlieties pēc tā, ko varat pārvaldīt, nevis pēc tā, kas izklausās moderni.

Pārvirziet piegādi uz āru ar smee

Izveidojiet kanālu relay servisā un saglabājiet tā URL. Tīkla iekšpusē instalējiet klientu un pārsūtiet piegādes uz ceļu, kuru Jenkins gaida. Payload URL repozitorija iestatījumos kļūst par kanāla URL, un satura tips ir iestatīts uz application/json.

sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080

Trīs detaļas izšķir, vai tas darbosies. Ceļam jāatbilst tam, ko Jenkins gaida GitHub notikumiem, kas pēc noklusējuma ir /github-webhook/. Jenkins jāklausās portā, kuru jūs devāt klientam. Un darbā konfigurētajam Jenkins URL jāsakrīt ar šo ceļu, citādi notikums ierodas un pēc tam tiek izmests.

Beigu slīpsvītras neatbilstība rada 404, kas lasās kā neveiksmīga piegāde un tāda nav.

Palaist to tā, lai tas pārdzīvotu nedēļu

Priekšplāna klients mirst kopā ar termināli, un webhook strādā dienu un pēc tam apstājas. Dodiet tam unit ar Restart=always, palaidiet to kā Jenkins lietotāju un izlasiet žurnālu pēc pirmās reālās piegādes. Tieši šis pēdējais solis atšķir strādājošu relay no konfigurēta.

[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.target

Testējiet ar īstu push, nevis atkārtošanas pogu. Atkārtošana izmanto relay saglabāto payload, nevis ceļu no GitHub uz jūsu kanālu, tāpēc tā var izturēt, kamēr tiešraides piegāde joprojām neizdodas.

Brīdiniet, kad unit apstājas. Relay, kas ir uz leju, pēc uzbūves ir kluss, un klusums ir tieši tas, ko jūs jau atkļūdojat.

Ko relay var redzēt, un kad to neizmantot

Relay pabeidz payload, tāpēc tas redz repozitoriju nosaukumus, commit datus un visu pārējo, ko notikums nes. Uztveriet kanāla URL kā publisku galapunktu. Turiet Jenkins slepeno token konfigurētu, lai viltotas piegādes tiktu noraidītas, un ierobežojiet Jenkins izmantoto token līdz nepieciešamajam minimumam.

Ja payload konfidencialitāte to izslēdz, pašmitināts runner vai autentificēts apgrieztais tunelis ir atbilde.

Relay tagad ir infrastruktūra, un tas ir pelnījis tādu pašu pārskatu kā build, ko tas ierosina. Rotējiet kanālu, ja tas noplūst, un pierakstiet datumu, kad pēdējo reizi pārbaudījāt tiešraides piegādi. Ielieciet šo datumu runbook blakus kanāla URL. Relay, ko neviens nav pārskatījis gadu, ir publisks galapunkts, kam neviens nepieder.