Защо webhook-ите на GitHub получават таймаут срещу Jenkins зад VPN
GitHub изпраща webhook-ите навътре, затова VPN, който пази Jenkins, ги отказва. Прекарайте доставката навън през relay или заменете webhook-а с агент, който прави анкети.
Страницата за доставка показва таймаут, а Jenkins не записва нищо — това е признакът за връзка, която така и не е пристигнала. GitHub изпраща webhook като изходящ HTTP POST от собствената си инфраструктура към URL адреса за payload, който сте задали. VPN пази Jenkins, като отказва точно такъв вид връзка. Нищо не е счупено от нито една страна. Проблемът е в посоката на заявката.
Какво всъщност опитва доставката
GitHub резолвва името на хоста в URL адреса за payload и се свързва с него от публичния интернет. Ако този адрес сочи към частен адрес или към име, което се резолвва само във вашата мрежа, опитът се проваля, преди да бъде изпратена каквато и да е заявка. Ако сочи към публично име, което вашият ръб отхвърля, опитът вместо това изтича.
Разликата е важна за диагностиката. DNS отказ и филтриран порт изглеждат еднакво — все едно на страната на Jenkins не се е случило нищо — и двете се показват в GitHub като неуспешна доставка с различна причина. Прочетете тази причина, преди да смените адреса.
Тунел, който се свързва навън, не създава слушател. Именно тази част хората очакват да работи различно.
Три начина да поправите посоката на връзката
Всяко решение сменя кой започва връзката и има само три форми.
| 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 |
Анкетирането е най-малко елегантното и най-лесното за експлоатация. Relay поддържа почти мигновена обратна връзка, без да отваря порт. Runner обикновено е правилният отговор, когато поверителността на payload изключва трета страна, защото задачата може да върви на машина, която вече е вътре в мрежата.
Избирайте по това, което можете да експлоатирате, а не по това, което звучи модерно.
Прекарайте доставка навън със smee
Създайте канал в relay услугата и запазете URL адреса му. Вътре в мрежата инсталирайте клиента и прехвърляйте доставките към пътя, който Jenkins очаква. URL адресът за payload в настройките на хранилището става URL на канала, а типът съдържание се задава като application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Три детайла решават дали ще работи. Пътят трябва да съвпада с това, което Jenkins очаква за GitHub събития, а по подразбиране това е /github-webhook/. Jenkins трябва да слуша на порта, който сте дали на клиента. И конфигурираният в задачата URL на Jenkins трябва да съвпада с този път, иначе събитието пристига и след това бива отхвърлено.
Несъответствие с наклонена черта в края дава 404, който се чете като неуспешна доставка, но не е.
Стартиране така, че да издържи седмицата
Клиент на преден план умира с терминала и webhook-ите работят един ден, а после спират. Дайте му unit с Restart=always, пуснете го като потребител Jenkins и прочетете журнала след първата истинска доставка. Именно последната стъпка отличава работещ 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 вече е инфраструктура и заслужава същия преглед като билда, който задейства. Сменете канала, ако изтече, и отбележете датата, на която последно сте проверили жива доставка. Сложете тази дата в runbook-а до URL адреса на канала. Relay, който никой не е преглеждал година, е публична крайна точка, която никой не притежава.