Зошто GitHub webhook-овите истекуваат наспроти Jenkins зад VPN
GitHub ги праќа webhook-овите навнатре, па VPN што го штити Jenkins ги одбива. Пренесете ја испораката нанадвор преку relay или заменете го webhook-от со агент што анкетира.
Страницата за испорака покажува истек на време, а Jenkins не запишува ништо, што е знак за врска што никогаш не пристигнала. GitHub го праќа webhook-от како излезен HTTP POST од својата инфраструктура кон payload URL-то што сте го конфигурирале. VPN го штити Jenkins одбивајќи токму таков вид врска. Ништо не е скршено на ниту една страна. Проблемот е во насоката на барањето.
Што всушност се обидува испораката
GitHub го решава името на домаќинот во payload URL-то и се поврзува со него од јавниот интернет. Ако тоа URL покажува на приватна адреса, или на име што се решава само внатре во вашата мрежа, обидот пропаѓа пред да биде испратено било какво барање. Ако покажува на јавно име што вашиот раб го отфрла, обидот наместо тоа истекува.
Оваа разлика е важна за дијагнозата. DNS дефект и филтриран порт и двата изгледаат како на страната на Jenkins да не се случило ништо, и двата се појавуваат на GitHub како неуспешна испорака со различен додаден причина. Прочитајте ја таа причина пред да го смените URL-то.
Тунел што ѕвони нанадвор не создава слушач. Токму тој дел луѓето очекуваат да работи поинаку.
Три начини да ја поправите насоката на врската
Секое решение го менува тоа кој ја започнува врската, и има само три форми.
| 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. 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 и прочитајте го журналот по првата вистинска испорака. Токму тој последен чекор го дели 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 што никој не го прегледал една година е јавна крајна точка што никој не ја поседува.