Зашто GitHub webhook-ови истичу пред Jenkins-ом иза VPN-а

Страница испоруке приказује истек времена, а Jenkins ништа не бележи, што је знак везе која никада није стигла. GitHub шаље webhook као одлазни HTTP POST из сопствене инфраструктуре на payload URL који сте конфигурисали. VPN штити Jenkins одбијајући управо такву врсту везе. Ништа није покварено ни на једној страни. Проблем је у смеру захтева.

Шта испорука заправо покушава

GitHub разрешава име домаћина у payload URL-у и повезује се са њим са јавног интернета. Ако тај URL показује на приватну адресу или на име које се разрешава само унутар ваше мреже, покушај пропада пре него што било који захтев буде послат. Ако показује на јавно име које ваша ивица одбацује, покушај уместо тога истиче.

Та разлика је важна за дијагностику. DNS квар и филтриран порт оба изгледају као да се на страни Jenkins-а ништа није догодило, и оба се на GitHub-у појављују као неуспешна испорука са другим приложеним разлогом. Прочитајте тај разлог пре него што промените URL.

Тунел који позива напоље не ствара слушаоца. Управо тај део људи очекују да ради другачије.

Три начина да поправите смер везе

Свако решење мења то ко започиње везу, и постоје само три облика.

Анкетирање је најмање елегантно и најлакше за управљање. Relay одржава готово тренутну повратну информацију без отварања порта. Runner је обично прави одговор када поверљивост payload-а искључује трећу страну, јер посао може да ради на машини која већ стоји унутар мреже.

Изаберите према ономе чиме можете да управљате, а не према ономе што звучи модерно.

Проследите испоруку напоље помоћу smee

Направите канал на relay услузи и сачувајте његов URL. Унутар мреже инсталирајте клијента и прослеђујте испоруке на путању коју Jenkins очекује. Payload URL у подешавањима репозиторијума постаје URL канала, са типом садржаја постављеним на application/json.

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

Три детаља одлучују да ли ради. Путања мора да се поклапа са оним што Jenkins очекује за GitHub догађаје, што је по задатом /github-webhook/. Jenkins мора да слуша на порту који сте дали клијенту. И Jenkins URL конфигурисан у послу мора да се слаже са том путањом, иначе догађај стигне и затим буде одбачен.

Неслагање завршне косе црте производи 404 који се чита као неуспешна испорука, а није.

Покретање тако да преживи недељу

Клијент у првом плану умире са терминалом, и webhook-ови раде један дан, а затим стану. Дајте му unit са Restart=always, покрените га као корисник Jenkins и прочитајте journal након прве стварне испоруке. Управо тај последњи корак раздваја relay који ради од конфигурисаног.

[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

Тестирајте правим push-ом, а не дугметом за понављање. Понављање изводи сачувани payload relay-а, а не путању од GitHub-а до вашег канала, па може да прође док жива испорука још увек не успева.

Упозорите када се unit заустави. Relay који је пао тих је по конструкцији, а тишина је управо оно што већ отклањате.

Шта relay може да види и када да га не користите

Relay терминира payload, па види имена репозиторијума, commit податке и све остало што догађај носи. Третирајте URL канала као јавну крајњу тачку. Држите тајни token Jenkins конфигурисан да се фалсификоване испоруке одбију, и ограничите token који Jenkins користи на потребан минимум.

Ако поверљивост payload-а то искључује, self-hosted runner или аутентификовани обрнути тунел је одговор.

Relay је сада инфраструктура и заслужује исти преглед као build који покреће. Ротирајте канал ако процури и забележите датум када сте последњи пут проверили живу испоруку. Ставите тај датум у runbook поред URL-а канала. Relay који нико није прегледао годину дана је јавна крајња тачка коју нико не поседује.