رجیستری فقط یک فرایند وب نیست
راهنمای رسمی Harbor برای استقرار با دسترس‌پذیری بالا، اجزای خود رجیستری را در کنار وابستگی‌های بیرونی آن قرار می‌دهد. مسیر ورودی، پایگاه داده، Redis و محل نگه‌داری داده ایمیج‌ها هرکدام بخشی از زنجیره خدمت‌اند. نمودار همراه این مقاله از همین راهنما گرفته شده است.
نکته معماری این است که افزایش تعداد نمونه‌های یک مؤلفه، خرابی وابستگی مشترک آن‌ها را حل نمی‌کند. اگر همه نمونه‌ها به یک پایگاه داده بدون مسیر بازیابی متصل باشند، آن پایگاه داده همچنان نقطه شکست مشترک است. راهنما نیز استقرار دسترس‌پذیر وابستگی‌های خارجی را مسئولیتی جدا از خود Harbor می‌داند.
این مرور درباره رابطه اجزاست؛ شماره نسخه‌های قدیمی ذکرشده در بعضی بخش‌های راهنما را حداقل نسخه مناسب برای نصب جدید تلقی نکنید. سازگاری chart، Harbor، Kubernetes و سرویس‌های وابسته باید از مستندات همان انتشار انتخابی بررسی شود.
یک سناریوی فرضی برای طراحی
فرض کنید سه گره دارید و برنامه‌های سازمان از همین رجیستری ایمیج می‌گیرند. ابتدا مسیر یک عملیات pull و یک push را روی کاغذ رسم کنید. کنار هر مرحله بنویسید داده پایدار کجا قرار می‌گیرد و چه اتفاقی می‌افتد اگر همان مؤلفه پاسخ ندهد.
سپس به‌جای خاموش‌کردن چند بخش هم‌زمان، تنها یک نمونه غیرحساس را در محیط آزمایش متوقف کنید. نتیجه را از دید مصرف‌کننده ثبت کنید: آیا دریافت ایمیج تازه موفق است؟ آیا کاربری که قبلاً وارد شده همان رفتار کاربر تازه را می‌بیند؟ آیا فهرست‌کردن ایمیج و دریافت لایه‌های آن هر دو کار می‌کنند؟
آزمون درست، فقط صفحه ورود نیست
برای پذیرش استقرار، چند عملیات نماینده انتخاب کنید: ورود، انتشار یک ایمیج آزمایشی، دریافت آن با digest مشخص و مشاهده نتیجه بررسی امنیتی در صورت فعال‌بودن آن قابلیت. موفقیت رابط وب، سلامت همه این مسیرها را ثابت نمی‌کند.
پیشنهاد تحریریه این است که برای هر شکست، زمان بازیابی و شاهد موفقیت بنویسید. اگر سرویس بعد از بازگشت وابستگی، به مداخله دستی نیاز دارد، همان گام باید در دستورالعمل عملیات ثبت شود. سناریوی بازیابی بدون فردی که همه جزئیات را از حفظ می‌داند نیز باید قابل اجرا باشد.
دسترس‌پذیری با پشتیبان‌گیری فرق دارد
Replica به تحمل بعضی خرابی‌ها کمک می‌کند؛ اما حذف اشتباه داده یا تنظیم نادرست ممکن است به همه نمونه‌ها منتقل شود. برای پشتیبان‌گیری، ارتباط میان داده پایگاه، فایل‌های رجیستری و اطلاعات پیکربندی را جدا طراحی کنید و بازیابی را در مقصدی مستقل بیازمایید. معیار پایان کار، توانایی دریافت ایمیج موردنیاز با هویت صحیح است، نه صرفاً روشن‌شدن Podها.
مسیر push را به چند قرارداد جدا تقسیم کنید
در یک انتشار ایمیج، کلاینت ابتدا باید نام رجیستری را حل کند و ارتباط امن برقرار سازد، سپس هویت و مجوز پروژه بررسی شود و داده لایه‌ها و manifest در مقصد ثبت شوند. این مراحل ممکن است به مؤلفه‌های متفاوت وابسته باشند. اگر صفحه وب باز می‌شود اما push شکست می‌خورد، ابتدا مرحله شکست را از پیام کلاینت و logهای همان زمان پیدا کنید. خطای گواهی، خطای اختیار نوشتن و خطای ذخیره لایه سه علت متفاوت‌اند و افزایش replica هیچ‌کدام را به صورت عمومی حل نمی‌کند.
برای آزمون پذیرش، یک پروژه آزمایشی و حسابی با اختیار محدود بسازید. ایمیجی کوچک با شناسه محتوای شناخته‌شده منتشر کنید و سپس از گره‌ای که cache قبلی ندارد آن را با digest دریافت کنید. استفاده از digest مانع آن می‌شود که تغییر tag نتیجه را مبهم کند. همان کار را با حسابی که فقط حق خواندن دارد تکرار کنید و انتظار داشته باشید دریافت موفق و انتشار ناموفق باشد. این دو آزمون هم مسیر داده و هم مرز مجوز را بررسی می‌کنند.
وابستگی مشترک را روی نقشه نشان دهید
اگر چند نمونه Harbor به یک پایگاه داده، یک Redis یا یک سرویس ذخیره‌سازی مشترک وصل‌اند، تحمل خرابی هر وابستگی باید جدا طراحی شود. تعداد Podها در داشبورد ممکن است زیاد باشد ولی همه آن‌ها منتظر همان مقصد ازکارافتاده بمانند. برای هر وابستگی بنویسید مالک عملیات آن کیست، چگونه خرابی تشخیص داده می‌شود و کلاینت‌ها پس از بازگشت چگونه دوباره وصل می‌شوند. وجود سامانه HA در زیرساخت نیز کافی نیست مگر مسیر اتصال Harbor واقعاً از endpoint مناسب آن استفاده کند.
در پایگاه داده، دسترس‌پذیری و سازگاری را هم‌زمان بررسی کنید. جابه‌جایی نقش نویسنده باید برای اتصال‌های تازه و اتصال‌های قدیمی رفتار قابل توضیح داشته باشد. آزمایش را با عملیات ساختگی انجام دهید و نتیجه را در سطح پروژه و artifact بررسی کنید. از روشن بودن فرایند پایگاه داده نمی‌توان نتیجه گرفت schema و داده‌های مورد انتظار Harbor قابل استفاده‌اند. پس از هر بازیابی، یک عملیات کامل push و pull همچنان لازم است.
ذخیره‌سازی مشترک و معنای پایداری
لایه‌های ایمیج باید در محلی باشند که نمونه‌های لازم به آن دسترسی سازگار دارند. یک volume محلی روی گره، صرفاً با افزایش replica به ذخیره‌سازی مشترک تبدیل نمی‌شود. اگر object storage انتخاب می‌کنید، endpoint، اعتبارنامه، مجوز و رفتار خطای آن را در طراحی وارد کنید. اگر فایل‌سیستم مشترک به کار می‌رود، ویژگی‌های دسترسی و خرابی همان سامانه را بسنجید. انتخاب را بر اساس الگوی واقعی دریافت و انتشار انجام دهید، نه فقط امکان mount شدن اولیه.
مصرف ظرفیت فقط تابع تعداد tagها نیست. لایه‌های مشترک، manifestهای متفاوت و سیاست نگه‌داری روی مقدار فضای مصرفی اثر می‌گذارند. حذف یک tag لزوماً به معنی آزاد شدن فوری همه بایت‌های مرتبط نیست. پیش از عملیات پاک‌سازی، روش مستند نسخه نصب‌شده و اثر آن بر artifactهای قابل دسترسی را بخوانید. در محیط آزمایش، چند ایمیج دارای لایه مشترک بسازید و پس از حذف کنترل‌شده، هم دسترسی ایمیج باقی‌مانده و هم تغییر واقعی ظرفیت را بررسی کنید.
پشتیبان سازگار از چند نوع داده
نسخه پشتیبان Harbor باید رابطه داده پایگاه، محتوای رجیستری و تنظیمات ضروری را حفظ کند. اگر فقط یک بخش از زمان قدیمی و بخش دیگر از زمان تازه بازیابی شود، ممکن است metadata به محتوایی اشاره کند که موجود نیست یا محتوایی باقی بماند که برنامه آن را نمی‌شناسد. روش تهیه نسخه باید با قرارداد سازگاری مستند همان استقرار هماهنگ باشد. زمان آغاز و پایان و دامنه عملیات را ثبت کنید تا وضعیت بازیابی‌شده قابل تفسیر باشد.
تمرین بازیابی را در مقصد مستقل با نام و گواهی آزمایشی انجام دهید. از اتصال ناخواسته برنامه‌های تولید به مقصد آزمایش جلوگیری کنید. پس از راه‌اندازی، فقط شمار پروژه‌ها را نگاه نکنید؛ چند digest نمونه را دریافت و صحت محتوای آن‌ها را بررسی کنید. حساب کاربری، robot account و مجوز پروژه نیز باید مطابق انتظار کار کنند. اگر کلید یا secret بیرون پشتیبان بوده است، این تمرین پیش از حادثه واقعی آن کمبود را آشکار می‌کند.
اعتبارنامه ماشین و مسیر CI
خط ساخت معمولاً به دسترسی تعاملی انسان نیاز ندارد و باید با هویت مخصوص خود کار کند. اختیار انتشار را به پروژه مورد نیاز محدود کنید و برای محیط‌های مختلف حساب‌های جدا داشته باشید. اگر یک اعتبارنامه عمومی در چند pipeline استفاده شود، شناسایی منبع رخداد و چرخش کلید دشوار می‌شود. log باید بتواند انتشار یک artifact را به pipeline و زمان مربوط وصل کند، بدون آنکه خود secret در خروجی ساخت ظاهر شود.
چرخش اعتبارنامه را با یک انتشار و یک دریافت آزمایشی کامل کنید. حذف کلید قدیمی پیش از به‌روزرسانی همه مصرف‌کننده‌ها می‌تواند تنها هنگام مقیاس‌دادن برنامه آشکار شود، زیرا گره‌های قدیمی ایمیج را در cache دارند. برای همین آزمون pull باید روی محیط بدون cache نیز انجام شود. در برنامه نگه‌داری، فهرست مصرف‌کنندگان رجیستری و وابستگی آن‌ها به credential مشخص را نگه دارید؛ این فهرست هنگام حادثه از حدس زدن بسیار بهتر است.
اسکن امنیتی و دسترس‌پذیری artifact
اسکن آسیب‌پذیری یک مسیر پردازش اضافی است و سلامت آن با سلامت دریافت لایه‌ها یکسان نیست. سیاست جلوگیری از دریافت بر اساس نتیجه اسکن باید وضعیت نامشخص، خطای اسکن و داده قدیمی را صریحاً تعریف کند. اگر سرویس اسکن قطع شود، آیا artifact تازه قابل استفاده است یا متوقف می‌شود؟ پاسخ باید تصمیم آگاهانه سازمان باشد. آزمایش این وضعیت در محیط غیرتولیدی مانع غافلگیری هنگام انتشار ضروری می‌شود.
نتیجه اسکن را نیز در زمینه ایمیج و digest بخوانید. tag قابل تغییر ممکن است بعداً به محتوای دیگری اشاره کند. گزارش امنیتی بدون اشاره به محتوای دقیق می‌تواند تیم را درباره نسخه واقعاً مستقر گمراه کند. برنامه اصلاح باید از یافته به بسته یا لایه مربوط و سپس به بازسازی و انتشار digest تازه برسد. پاک‌کردن هشدار در رابط کاربری جای اصلاح artifact مصرف‌شده را نمی‌گیرد.
آزمون خرابی از دید مصرف‌کننده
در یک تمرین، تنها یک نمونه سرویس را از مدار خارج کنید و در طول آن دریافت‌های کوتاه و انتشار آزمایشی انجام دهید. سپس به صورت جدا خرابی یک گره یا قطع کوتاه یک وابستگی آزمایشی را بسنجید. هدف یافتن فاصله میان تشخیص خرابی و بازگشت عملیات واقعی است. اگر کلاینت با retry موفق می‌شود، تعداد تلاش و زمان انتظار را هم بنویسید؛ موفقیت نهایی می‌تواند تأخیر نامطلوب را پنهان کند.
پخش replicaها روی دامنه‌های شکست، readiness مناسب و ظرفیت کافی گره‌های باقی‌مانده باید با هم دیده شوند. اگر پس از خروج یک گره، دو نمونه باقی‌مانده از نظر CPU یا شبکه اشباع شوند، معماری ظاهراً افزونه هنوز تجربه کاربر را حفظ نکرده است. نتیجه تمرین باید به ظرفیت و وابستگی واقعی وصل شود. این اطلاعات مبنای تصمیم درباره تعداد نمونه‌ها، پنجره نگه‌داری و حدود دسترس‌پذیری قابل وعده خواهد بود.
ارتقا بدون گم‌کردن قرارداد داده
ارتقای chart و ارتقای خود برنامه را با فهرست وابستگی‌ها هماهنگ کنید. تغییر schema پایگاه داده ممکن است برگشت به باینری قبلی را به عملیاتی پیچیده‌تر از تغییر image تبدیل کند. پیش از ارتقا، روش بازگشت مستند همان نسخه را بررسی کنید و نسخه پشتیبان قابل بازیابی داشته باشید. در محیط تمرین، چند artifact نمونه و چند حساب با مجوز متفاوت را نگه دارید و بعد از ارتقا همان عملیات را تکرار کنید.
مقادیر سفارشی پیکربندی را از پیش‌فرض‌های chart جدا ثبت کنید تا تغییر پیش‌فرض در انتشار تازه بی‌صدا رفتار را عوض نکند. گواهی، نام خارجی سرویس، مسیر ذخیره و تنظیمات هویت جزو مواردی‌اند که باید صریح بازبینی شوند. موفق شدن فرمان نصب فقط اثبات می‌کند ابزار استقرار کارش را انجام داده؛ پذیرش رجیستری به موفقیت عملیات واقعی مصرف‌کننده وابسته است. پس از پایان، نسخه مؤثر همه اجزا و نتیجه آزمون‌ها را در پرونده همان تغییر ذخیره کنید.
