VPN ortidagi Jenkins oldida GitHub webhook’lari nima uchun vaqt tugaydi
GitHub webhook’larni ichkariga yuboradi, shuning uchun Jenkins’ni himoya qiluvchi VPN ularni rad etadi. Yetkazib berishni relay orqali tashqariga o’tkazing yoki webhook’ni so’rov yuboradigan agent bilan almashtiring.
Yetkazib berish sahifasi vaqt tugashini ko’rsatadi va Jenkins hech narsa yozmaydi, bu esa hech qachon yetib kelmagan ulanish alomatidir. GitHub webhook’ni o’z infratuzilmasidan siz sozlagan payload URL’ga qarab chiquvchi HTTP POST sifatida yuboradi. VPN Jenkins’ni aynan shunday ulanishni rad etish bilan himoya qiladi. Ikkala tomonda ham hech narsa buzilmagan. Muammo so’rov yo’nalishida.
Yetkazib berish aslida nimaga urinadi
GitHub payload URL’dagi xost nomini hal qiladi va unga ochiq internetdan ulanadi. Agar bu URL shaxsiy manzilga yoki faqat sizning tarmog’ingiz ichida hal qilinadigan nomga ishora qilsa, urinish har qanday so’rov yuborilishidan oldin muvaffaqiyatsiz bo’ladi. Agar u sizning chekingiz tashlab yuboradigan ochiq nomga ishora qilsa, urinish buning o’rniga vaqt tugaydi.
Bu farq diagnostika uchun muhim. DNS xatosi va filtrlangan port ikkalasi ham Jenkins tomonida hech narsa bo’lmagandek ko’rinadi va ikkalasi GitHub’da boshqa sabab ilova qilingan muvaffaqiyatsiz yetkazib berish sifatida ko’rinadi. URL’ni o’zgartirishdan oldin o’sha sababni o’qing.
Tashqariga qo’ng’iroq qiladigan tunnel tinglovchi yaratmaydi. Odamlar boshqacha ishlashini kutadigan qism aynan shu.
Ulanish yo’nalishini tuzatishning uch yo’li
Har bir yechim ulanishni kim boshlashini o’zgartiradi va faqat uchta shakl mavjud.
| 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 |
So’rov yuborish eng kam nafis va boshqarish eng oson usuldir. Relay port ochmasdan deyarli bir zumda qayta aloqani saqlaydi. Payload maxfiyligi uchinchi tomonni istisno qilganda runner odatda to’g’ri javob bo’ladi, chunki ish allaqachon tarmoq ichida turgan mashinada bajarilishi mumkin.
Boshqara oladigan narsangizga qarab tanlang, zamonaviy eshitiladigan narsaga qarab emas.
Yetkazib berishni smee bilan tashqariga o’tkazing
Relay xizmatida kanal yarating va uning URL’ini saqlang. Tarmoq ichida klientni o’rnating va yetkazib berishlarni Jenkins kutgan yo’lga yuboring. Repozitoriy sozlamalaridagi payload URL kanalning URL’iga aylanadi, kontent turi application/json ga o’rnatiladi.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Uch tafsilot uning ishlashini hal qiladi. Yo’l GitHub hodisalari uchun Jenkins kutganiga mos kelishi kerak, u sukut bo’yicha /github-webhook/. Jenkins siz klientga bergan portda tinglashi kerak. Va ishda sozlangan Jenkins URL o’sha yo’lga mos bo’lishi kerak, aks holda hodisa yetib keladi va keyin tashlab yuboriladi.
Oxirgi qiyshiq chiziqning mos kelmasligi 404 hosil qiladi, u yetkazib berish xatosi kabi o’qiladi, lekin unday emas.
Uni haftani yengib o’tadigan qilib ishga tushirish
Old plandagi klient terminal bilan birga o’ladi va webhook’lar bir kun ishlaydi, keyin to’xtaydi. Unga Restart=always bo’lgan unit bering, uni Jenkins foydalanuvchisi sifatida ishga tushiring va birinchi haqiqiy yetkazib berishdan keyin journal’ni o’qing. Aynan o’sha oxirgi qadam ishlaydigan relay’ni sozlangan relay’dan ajratadi.
[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.targetQayta ijro etish tugmasi o’rniga haqiqiy push bilan sinab ko’ring. Qayta ijro relay’ning saqlangan payload’ini ishlatadi, GitHub’dan kanalingizgacha bo’lgan yo’lni emas, shuning uchun jonli yetkazib berish hali ham muvaffaqiyatsiz bo’lsa-da, u o’tishi mumkin.
unit to’xtaganda ogohlantiring. O’chgan relay tabiatan jim bo’ladi va sukunat siz allaqachon tuzatayotgan narsadir.
relay nimalarni ko’ra oladi va qachon undan foydalanmaslik kerak
relay payload’ni tugatadi, shuning uchun u repozitoriy nomlarini, commit ma’lumotlarini va hodisa olib yuradigan hamma narsani ko’radi. Kanal URL’iga ochiq yakuniy nuqta sifatida qarang. Soxta yetkazib berishlar rad etilishi uchun Jenkins’ning maxfiy token’i sozlangan holda tursin va Jenkins ishlatadigan token doirasini zarur minimum bilan cheklang.
Agar payload maxfiyligi buni istisno qilsa, o’zingiz joylashtirgan runner yoki autentifikatsiyalangan teskari tunnel javobdir.
relay endi infratuzilma va u ishga tushiradigan build kabi ko’rib chiqilishga loyiqdir. Kanal oqib ketsa uni almashtiring va jonli yetkazib berishni oxirgi marta qachon tekshirganingiz sanasini yozib qo’ying. O’sha sanani kanal URL’i yonida runbook’ka qo’ying. Bir yil davomida hech kim ko’rib chiqmagan relay hech kimga tegishli bo’lmagan ochiq yakuniy nuqtadir.