VPN برای رانر CI: آیا تونل از بیلد زنده‌تر می‌ماند؟
یک رانر CI مشترک مسیرها و فرایندها را بین کارها نگه می‌دارد. حالت‌های VPN را پیش از کار، در طول آن و پس از آن برنامه‌ریزی کنید و فقط اتصالی را پاک کنید که کار مالک آن است.
یک کار استقرار متصل می‌شود، آرتیفکت خود را کپی می‌کند و موفقیت را گزارش می‌دهد. تونلی که باز کرده ممکن است هنگام شروع کار بعدی هنوز فعال باشد، و مسیری که تغییر داده به کل میزبان تعلق دارد. نتیجه بیلد دستور را توصیف می‌کند، نه حالتی که پشت سر گذاشته است. با VPN مانند منبعی با طول عمر رفتار کنید، نه مثل یک خط در ابتدای یک مرحله.
چه چیز دیگری روی این میزبان اجرا می‌شود
یک نود Jenkins می‌تواند چند اجراکننده را همزمان اجرا کند، و کاری که مسیرهای میزبان، تنظیمات resolver یا اتصال سراسری سیستم را تغییر می‌دهد، آن را برای همه تغییر می‌دهد. اینکه کار دیگری متوجه شود به سیاست مسیر و فیلتر بستگی دارد، نه به یک قاعده کلی درباره VPN. دسترسی به مخزن، دسترسی به آرتیفکت‌ها و کانال کنترل نیازهای جدایی هستند که رانر هنوز به آن‌ها نیاز دارد. پیش از انتخاب تونل کامل، آن‌ها را به فهرست مقصدهای استقرار اضافه کنید.
اگر کانال کنترل قرار است از تونل عبور کند، طراحی باید آگاهانه این را بگوید. کشف آن هنگام عقب‌نشینی، برنامه نیست. دو فهرست را بنویسید: چه چیزی باید به‌صورت خصوصی برای کار قابل دسترس باشد و چه چیزی باید در هر حال برای رانر قابل دسترس باشد.
آیا این کار اصلاً به دسترسی خصوصی نیاز دارد؟
پیش از افزودن تونل بپرسید آیا مرحله بیلد به آن نیاز دارد. یک ایجنت استقرار خصوصی می‌تواند آرتیفکت تأییدشده را بگیرد و استقرار را انجام دهد، که مرحله عمومی بیلد را بیرون از شبکه خصوصی نگه می‌دارد. این تفکیک معمولاً ارزان‌تر از آموزش مسیریابی از تونل به هر گام بیلد است.
مرز را از جریان کار انتخاب کنید، نه از عادت. اگر پاسخ منفی است، باقی این صفحه لازم نیست، و این بهترین نتیجه ممکن است.
حالتی که کار بعدی به ارث می‌برد
توصیف کنید پیش از کار، در حالی که دسترسی خصوصی دارد و پس از پایان آن، از جمله لغو، چه چیزی باید درست باشد. حالت پایانی همان چیزی است که بیشتر از همه ضمنی رها می‌شود، و همان است که کار بعدی به ارث می‌برد. آن را کنار 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 |
یک ایجنت اختصاصی یا یک‌بارمصرف اجرای این مرزها را آسان‌تر می‌کند. کانتینر یا namespace فقط زمانی کمک می‌کند که چیدمان شبکه و دسترسی‌های آن واقعاً تغییر را جدا کند.
اتصال را متوقف کنید، نه برنامه را
از مسیر نهایی‌سازی pipeline استفاده کنید تا اتصالی را ببندید که این کار آغاز کرده و اعتبارنامه‌های موقت آن را حذف کنید. روی میزبانی که کارهای دیگر استفاده می‌کنند فرایندها را با نام برنامه تطبیق ندهید؛ به‌جای آن همان اتصال مشخص را متوقف کنید. دو دستور زیر تمام پاک‌سازی است و هیچ‌یک به پیدا کردن یک فرایند وابسته نیست.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"نهایی‌سازی جداسازی نیست: رانری که می‌میرد تونلی را که باز کرده نگه می‌دارد، و فرایندی که به‌زور متوقف می‌شود بلوک را کاملاً رد می‌کند. به همین دلیل دستور پاک‌سازی به‌تنهایی نمی‌تواند تمام طراحی باشد. در عمل این‌گونه شکست می‌خورد: یک کار استقرار در گام کپی لغو می‌شود، بلوک نهایی‌سازی هرگز اجرا نمی‌شود و کار بعدی روی همان میزبان با تونلی فعال و مسیری شروع می‌شود که به شبکه‌ای اشاره می‌کند که به آن دسترسی ندارد. این خرابی در بیلد بعدی شبیه مشکل 'DNS' به نظر می‌رسد، ساعت‌ها پس از پایان کاری که آن را ایجاد کرده بود.
نام پروفایل و مسیر اعتبارنامه را در خروجی کار ثبت کنید. یک دستور قطع اتصال خالی و بدون شناسه، بعداً سخت قابل بررسی است. خط لاگ همچنین همان چیزی است که ثابت می‌کند بلوک اجرا شده، وقتی بررسی بعدی آن را می‌پرسد.
به کار میزبانی بدهید که هیچ‌کس دیگری استفاده نمی‌کند
زیرساخت یک‌بارمصرف مشکل ارث‌بری را به‌جای مدیریت آن برمی‌دارد. یک ایجنت تازه برای هر کار بدون مسیر، بدون پروفایل و بدون اعتبارنامه دیگران شروع می‌شود و نابودی آن هر چه کار باقی گذاشته پاک می‌کند. این برای هر بیلد هزینه بیشتری دارد، و قیمت صادقانه مرزی است که به کد پاک‌سازی وابسته نیست. برای کارهایی که به شبکه‌های تولید دست می‌زنند، وقتی حوادث شمرده شوند معمولاً گزینه ارزان‌تر همین است.
جایی که یک رانر مشترک باید بماند، شکست و لغو را به همان دقت کپی موفق آزمایش کنید. آزمایش باید نشان دهد اگر این کار در میانه لغو می‌شد، کار بعدی چه می‌دید. کار زمانی تمام است که دسترسی و حالت موقت آن پایان یافته باشد، نه وقتی دستور کپی صفر برمی‌گرداند.