سناریوی مرجع
کل زیرساخت، روی سختافزار خودمان، بدون هیچ خط تلفنی به بیرون
کل زیرساخت روی سختافزار خودمان، بدون هیچ اتصال اجباری
این یک مطالعهٔ موردی مشتری نیست. یک الگوی پیادهسازی است: وضعیتی که در ارزیابی الزامات سازمانی جمع کردهایم، با معماری راهحل و مکانیزم دقیقی که آن را ممکن میکند. چرا هنوز مشتری مرجع عمومی نداریم
یک سازمان با حدود ۳۰۰ نفر، ۴۰ سرور فیزیکی، ترکیبی از ماشین مجازی و container، و یک الزام صریح: هیچ سامانهای نباید به سرویس خارجی وابسته باشد.
امروز: یک پلتفرم مجازیسازی لایسنسی، یک کلاستر Kubernetes دستساز، سه ابزار مانیتورینگ که هیچکدام کامل نیست، و یک نگرانی دائمی دربارهٔ روزی که لایسنس تمدید نشود.
سؤال محوری
اگر فردا اینترنتِ این سازمان قطع شود، چه چیزی از کار میافتد؟
| مؤلفه | قبل | با دزکوب |
|---|---|---|
| فعالسازی لایسنس | وابسته به سرور خارجی | وجود ندارد |
| بروزرسانی ایمیج | از رجیستری عمومی | از رجیستری داخلی |
| صدور گواهی | از ACME عمومی | از مرجع صدور داخلی |
| تصمیمگیری کنترلپلن | برخی ابزارها گزارش میدهند | کاملاً داخلی |
| احراز هویت | ترکیبی | IdP داخلی سازمان |
معماری راهحل
هیچ فلشی از این کادر بیرون نمیرود.
این تنها چیزی است که «مستقل» را از یک ادعا به یک وضعیت قابل بررسی تبدیل میکند: میتوانید هر مسیر خروجی را بشمارید و ببینید به کجا میرسد.
مکانیزمهایی که این را ممکن میکنند
- سقف خروجی «فقط داخلی»
- هیچ سطحی نمیتواند بازش کند؛ اعتبارنامهٔ ممنوع در لحظهٔ ثبت رد میشود
- کاتالوگ افزونهٔ پینشده و allow-list
- نصب فقط از منابع تأییدشده
- بستهٔ آفلاین
- برای نصب و بروزرسانی بدون اینترنت
- آینهٔ رجیستری
- برای سایتِ نیمهمتصل
- مرجع صدور داخلی
- گواهی بدون ACME عمومی
- KeyProvider با Vault
- کلید در اختیار سازمان
- ورود با IdP داخلی
- بدون وابستگی به هویت خارجی
چه چیزی همچنان لازم است
- سختافزار. دزکوب سرور نمیسازد. برآورد ظرفیت در جلسهٔ ارزیابی انجام میشود.
- یک مالک. حداقل یک نفر باید مالک زیرساخت باشد.
- بروزرسانی. برای دریافت نسخهٔ جدید، بستهٔ امضاشده باید به داخل منتقل شود. این یک فرآیند دستیِ عمدی است.
اینها را هم ببینید
وابستگیهای فعلیتان را فهرست کنیم.
در جلسه، هر مسیر بیرونیِ زیرساخت فعلی را میشماریم و میگوییم کدام حذف میشود.