CI رنر VPN: کیا ٹنل build سے زیادہ زندہ رہتا ہے؟
مشترکہ CI رنر کاموں کے درمیان راستے اور عمل محفوظ رکھتا ہے۔ VPN کی پیشگی، دوران اور بعد کی حالتیں منصوبہ بندی کریں، اور صرف اُس کنکشن کو صاف کریں جو کام کی ملکیت ہے۔
ڈیپلائمنٹ کام جڑتا ہے، اپنا آرٹی فیکٹ نقل کرتا ہے اور کامیابی کی اطلاع دیتا ہے۔ اُس کا کھولا ہوا ٹنل اگلا کام شروع ہونے پر بھی چل رہا ہو سکتا ہے، اور اُس کا بدلا ہوا راستہ پورے ہوسٹ کا ہے۔ build کا نتیجہ کمانڈ بیان کرتا ہے، وہ حالت نہیں جو اُس نے پیچھے چھوڑی۔ VPN کو زندگی کی مدت والا وسیلہ سمجھیں، نہ کہ کسی مرحلے کے آغاز میں ایک سطر۔
اِس ہوسٹ پر اور کیا چلتا ہے
Jenkins نوڈ بیک وقت کئی ایگزیکیوٹر چلا سکتا ہے، اور وہ کام جو ہوسٹ کے راستے، resolver کی ترتیبات یا نظامی سطح کا کنکشن بدلتا ہے، وہ سب کے لیے بدل دیتا ہے۔ کوئی دوسرا کام اِسے دیکھے گا یا نہیں، یہ راستوں اور فلٹرنگ کی پالیسی پر منحصر ہے، VPN کے بارے میں کسی عام اصول پر نہیں۔ ریپوزٹری تک رسائی، آرٹی فیکٹ تک رسائی اور کنٹرول چینل وہ الگ الگ تقاضے ہیں جو رنر کو اب بھی درکار ہیں۔ مکمل ٹنل چننے سے پہلے اُنہیں ڈیپلائمنٹ منزل کی فہرست میں شامل کریں۔
اگر کنٹرول چینل ٹنل سے گزرے گا، تو ڈیزائن کو یہ دانستہ کہنا ہوگا۔ rollback کے دوران یہ دریافت کرنا کوئی منصوبہ نہیں۔ دونوں فہرستیں لکھیں: کام کو نجی طور پر کیا پانا ہے اور رنر کو ہر حال میں کیا پانا ہے۔
کیا اِس کام کو نجی رسائی کی ضرورت ہے ہی بھی؟
ٹنل شامل کرنے سے پہلے پوچھیں کہ کیا build مرحلے کو اِس کی ضرورت ہے۔ نجی ڈیپلائمنٹ ایجنٹ منظور شدہ آرٹی فیکٹ لا کر ڈیپلائمنٹ کر سکتا ہے، جس سے عام build مرحلہ نجی نیٹ ورک سے باہر رہتا ہے۔ یہ تقسیم عام طور پر ہر build قدم کو ٹنل سے گزرنا سکھانے سے سستی ہے۔
حد کو عادت سے نہیں، ورک فلو سے چنیں۔ اگر جواب نہیں ہے، تو اِس صفحے کا باقی حصہ غیر ضروری ہے، اور یہی بہترین دستیاب نتیجہ ہے۔
وہ حالت جو اگلا کام ورثے میں پاتا ہے
بیان کریں کہ کام سے پہلے، جب اُس کے پاس نجی رسائی ہو، اور اُس کے ختم ہونے کے بعد، منسوخی سمیت، کیا درست ہونا چاہیے۔ آخری حالت ہی سب سے زیادہ غیر بیان شدہ رہتی ہے، اور وہی اگلے کام کو ورثے میں ملتی ہے۔ اُسے کسی کی یادداشت میں چھوڑنے کے بجائے pipeline کے پاس لکھیں۔
| Moment | What proves it | What leaks if it is skipped |
|---|---|---|
| Job start: pre-flight route check | The route table shows no tunnel from an earlier job, and the profile list is empty | A stale route sends deployment traffic into a dead tunnel |
| Job end: disconnect and shred | The profile is down and the temporary key file is gone | The next job inherits an open tunnel and a usable credential |
| Cancelled job: reboot or disposal | The host is replaced or rebooted before the next job starts | A killed process leaves the tunnel up with no owner |
مخصوص یا ایک بار استعمال ہونے والا ایجنٹ اِن حدود کو نافذ کرنا آسان بناتا ہے۔ container یا namespace صرف اُس وقت مدد دیتا ہے جب اُس کی نیٹ ورک اور مراعات کی ترتیب واقعی تبدیلی کو الگ کرے۔
پروگرام نہیں، کنکشن روکیں
اِس کام نے جو کنکشن شروع کیا اُسے بند کرنے اور اُس کی عارضی اسناد ہٹانے کے لیے pipeline کے اختتامی راستے کو استعمال کریں۔ اُس ہوسٹ پر جسے دوسرے کام بھی استعمال کرتے ہیں، پروگرام کے نام سے عمل نہ ملائیں؛ مخصوص کنکشن روکیں۔ نیچے دی گئی دو کمانڈز پوری صفائی ہیں، اور کوئی بھی کسی عمل کو ڈھونڈنے پر منحصر نہیں۔
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"اختتام الگ تھلگ کرنا نہیں: مرنے والا رنر اپنا کھولا ہوا ٹنل رکھ لیتا ہے، اور زبردستی روکا گیا عمل اُس بلاک کو مکمل طور پر چھوڑ دیتا ہے۔ اِسی لیے صرف صفائی کی کمانڈ پورا ڈیزائن نہیں ہو سکتی۔ عملاً یہ اِس طرح ناکام ہوتا ہے: ڈیپلائمنٹ کام نقل کے مرحلے پر منسوخ ہو جاتا ہے، اختتامی بلاک کبھی نہیں چلتا، اور اُسی ہوسٹ پر اگلا کام زندہ ٹنل اور اُس راستے کے ساتھ شروع ہوتا ہے جو ایسے نیٹ ورک کی طرف ہے جہاں وہ پہنچ نہیں سکتا۔ ناکامی اگلے build میں 'DNS' کے مسئلے کی طرح نظر آتی ہے، اُس کام کے ختم ہونے کے گھنٹوں بعد جس نے اِسے پیدا کیا۔
کام کے آؤٹ پٹ میں profile کا نام اور اسناد کا راستہ درج کریں۔ بغیر شناخت کے ننگا ڈس کنیکٹ حکم بعد میں آڈٹ کرنا مشکل ہے۔ لاگ کی سطر ہی یہ ثابت کرتی ہے کہ بلاک چلا، جب بعد کی تحقیقات پوچھیں۔
کام کو ایسا ہوسٹ دیں جو کوئی اور استعمال نہ کرے
ایک بار استعمال ہونے والا ڈھانچہ وراثت کے مسئلے کو سنبھالنے کے بجائے ختم کر دیتا ہے۔ ہر کام کے لیے نیا ایجنٹ بغیر راستے، بغیر profile اور کسی اور کی اسناد کے بغیر شروع ہوتا ہے، اور اُس کی تباہی وہ سب صاف کر دیتی ہے جو کام نے چھوڑا۔ اِس کی فی build زیادہ لاگت آتی ہے، اور یہ اُس حد کی ایماندار قیمت ہے جو صفائی کے کوڈ پر منحصر نہیں۔ ایسے کاموں کے لیے جو پروڈکشن نیٹ ورک کو چھوتے ہیں، واقعات گننے کے بعد یہ عام طور پر سستا آپشن ہے۔
جہاں مشترکہ رنر رکنا ہی ہے، ناکامی اور منسوخی کو کامیاب نقل کی طرح احتیاط سے جانچیں۔ جانچ کو دکھانا چاہیے کہ اگلا کام کیا دیکھتا اگر یہ آدھے راستے میں منسوخ ہو جاتا۔ کام اُس وقت مکمل ہوتا ہے جب اُس کی رسائی اور عارضی حالت ختم ہو جائے، نہ کہ جب نقل کی کمانڈ صفر واپس کرے۔