VPN کے پیچھے Jenkins کے خلاف GitHub webhook کیوں وقت سے تجاوز کرتے ہیں
GitHub webhook اندر کی طرف بھیجتا ہے، اس لیے Jenkins کی حفاظت کرنے والا VPN انہیں مسترد کرتا ہے۔ ترسیل کو relay کے ذریعے باہر بھیجیں، یا webhook کو پولنگ کرنے والے agent سے بدل دیں۔
ترسیل کا صفحہ وقت ختم ہونا دکھاتا ہے اور Jenkins کچھ بھی درج نہیں کرتا، جو کبھی نہ پہنچنے والے کنکشن کی نشانی ہے۔ GitHub webhook کو اپنی بنیادی ڈھانچے سے آپ کے ترتیب کردہ payload URL تک جانے والے HTTP POST کے طور پر بھیجتا ہے۔ 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 پورٹ کھولے بغیر تقریباً فوری فیڈبیک رکھتا ہے۔ جب payload کی رازداری تیسرے فریق کو خارج کرتی ہے تو runner عام طور پر درست جواب ہوتا ہے، کیونکہ کام ایسی مشین پر چل سکتا ہے جو پہلے ہی نیٹ ورک کے اندر ہے۔
جسے آپ چلا سکتے ہیں اس کی بنیاد پر چنیں، جدید سننے والی بات کی بنیاد پر نہیں۔
smee کے ساتھ ترسیل باہر بھیجیں
relay سروس پر چینل بنائیں اور اس کا URL رکھیں۔ نیٹ ورک کے اندر، کلائنٹ انسٹال کریں اور ترسیل کو اس راستے پر بھیجیں جس کی Jenkins توقع کرتا ہے۔ ریپوزٹری کی ترتیبات میں payload URL چینل کا URL بن جاتا ہے، مواد کی قسم application/json پر مقرر ہوتی ہے۔
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080تین تفصیلات طے کرتی ہیں کہ یہ کام کرے گا یا نہیں۔ راستہ GitHub واقعات کے لیے Jenkins کی توقع سے میل کھانا چاہیے، جو بطور طے شدہ /github-webhook/ ہے۔ Jenkins کو اس پورٹ پر سننا چاہیے جو آپ نے کلائنٹ کو دیا۔ اور جاب میں ترتیب دیا گیا Jenkins URL اس راستے سے متفق ہونا چاہیے، ورنہ واقعہ پہنچ کر پھر پھینک دیا جاتا ہے۔
آخر میں سلیش کا نہ ملنا 404 پیدا کرتا ہے جو ترسیل کی ناکامی جیسا پڑھا جاتا ہے اور ایسا نہیں ہے۔
اسے اس طرح چلانا کہ ہفتہ گزر جائے
پیش منظر کلائنٹ ٹرمینل کے ساتھ مر جاتا ہے، اور webhook ایک دن چلتے ہیں پھر رک جاتے ہیں۔ اسے Restart=always والا unit دیں، Jenkins صارف کے طور پر چلائیں، اور پہلی حقیقی ترسیل کے بعد journal پڑھیں۔ یہی آخری قدم کام کرنے والے relay کو ترتیب شدہ 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 سے جانچیں۔ دوبارہ چلانا relay کے محفوظ payload کی مشق کرتا ہے، GitHub سے آپ کے چینل تک کے راستے کی نہیں، اس لیے یہ تب بھی پاس ہو سکتا ہے جب براہ راست ترسیل اب بھی ناکام ہو۔
unit رکنے پر انتباہ دیں۔ بند relay اپنی ساخت سے ہی خاموش ہوتا ہے، اور خاموشی وہی ہے جسے آپ پہلے ہی ڈیبگ کر رہے ہیں۔
relay کیا دیکھ سکتا ہے، اور کب اسے استعمال نہ کریں
relay payload کو ختم کرتا ہے، اس لیے یہ ریپوزٹریوں کے نام، commit ڈیٹا اور واقعہ جو کچھ لے کر جاتا ہے سب دیکھتا ہے۔ چینل کے URL کو عوامی آخری نقطہ سمجھیں۔ جعلی ترسیل مسترد ہونے کے لیے Jenkins کا secret token ترتیب شدہ رکھیں، اور Jenkins جو token استعمال کرتا ہے اس کی حد ضروری کم سے کم تک رکھیں۔
اگر payload کی رازداری اسے خارج کرتی ہے، تو خود میزبان runner یا تصدیق شدہ معکوس سرنگ جواب ہے۔
relay اب بنیادی ڈھانچہ ہے، اور یہ اس build کے برابر جائزے کا حقدار ہے جسے یہ متحرک کرتا ہے۔ چینل لیک ہو تو اسے گھمائیں، اور وہ تاریخ نوٹ کریں جب آپ نے آخری بار براہ راست ترسیل کی تصدیق کی تھی۔ وہ تاریخ چینل کے URL کے ساتھ runbook میں رکھیں۔ جس relay کا کسی نے سال بھر جائزہ نہ لیا ہو وہ عوامی آخری نقطہ ہے جس کا کوئی مالک نہیں۔