یک تیم توسعه برای هر سرویس به پایگاه داده، حساب دسترسی و تنظیم اتصال نیاز دارد. اگر هر تیم مستقیماً تمام جزئیات ارائه‌دهنده زیرساخت را انتخاب کند، تفاوت‌های کوچک در شبکه، نسخه یا مالکیت داده به هزینه نگه‌داری تبدیل می‌شوند. تیم پلتفرم می‌خواهد یک درخواست روشن در اختیار توسعه‌دهنده بگذارد. توسعه‌دهنده نام محیط و اندازه مورد نیاز را بیان کند و تیم پلتفرم تعیین کند کدام منابع این قرارداد را پیاده می‌کنند. در Crossplane، تعریف منبع ترکیبی و Composition امکان ساخت چنین APIای را فراهم می‌کند. کیفیت طراحی را می‌توان از رفتار درخواست هنگام ایجاد، تغییر، خطا و حذف سنجید.
ابتدا قرارداد توسعه‌دهنده را بنویسید
پیش از انتخاب منابع ابری، مشخص کنید توسعه‌دهنده واقعاً کدام تصمیم‌ها را باید بگیرد. اندازه پایگاه داده، محیط آزمایش یا تولید و مدت نگه‌داری داده ممکن است بخشی از قرارداد باشند. شناسه داخلی شبکه یا نام دقیق کلاس ماشین شاید بهتر باشد در اختیار تیم پلتفرم بماند. اگر تمام فیلدهای ارائه‌دهنده بدون تغییر در API جدید تکرار شوند، توسعه‌دهنده همچنان ناچار است همان پیچیدگی را بشناسد و تیم پلتفرم تعهد بیشتری برای نگه‌داری نسخه‌ها پیدا می‌کند. از طرف دیگر پنهان کردن انتخابی که مستقیماً روی هزینه یا زمان بازیابی اثر دارد می‌تواند تصمیم‌گیری مسئولانه را دشوار کند.
برای هر فیلد یک نمونه معتبر، یک نمونه نامعتبر و معنای تغییر آن را مشخص کنید. مثلاً افزایش ظرفیت ذخیره‌سازی ممکن است قابل پشتیبانی باشد، اما کاهش آن نیازمند انتقال داده یا ایجاد منبع تازه باشد. API باید این تفاوت را در اعتبارسنجی و مستندات بازتاب دهد. یک فیلد اختیاری که امروز با مقدار پیش‌فرض کوچک ایجاد می‌شود، پس از تغییر پیش‌فرض نباید بی‌برنامه همه محیط‌های قدیمی را دگرگون کند. تصمیم درباره مقدارهای پیش‌فرض و رفتار ارتقا بخشی از قرارداد بلندمدت است. هزینه اصلاح یک قرارداد عمومی پس از استفاده چند تیم معمولاً از اصلاح قالب داخلی بیشتر است.
XRD شکل منبع ترکیبی را تعریف می‌کند
CompositeResourceDefinition یا XRD نوع منبع، گروه API، نسخه و طرح فیلدها را توصیف می‌کند. از این تعریف، نوعی منبع برای استفاده از طریق API Kubernetes در دسترس قرار می‌گیرد. نمونه‌ای که توسعه‌دهنده ایجاد می‌کند معمولاً XR خوانده می‌شود. XRD مانند قرارداد نوع درخواست عمل می‌کند و XR درخواست مشخصی برای یک محیط است. ایجاد XRD به تنهایی زیرساخت یک تیم را نمی‌سازد. باید نمونه‌ای با مشخصات مورد نیاز ایجاد شود و روشی برای تبدیل آن مشخصات به منابع مطلوب وجود داشته باشد. در بررسی خطا، نبود نوع API با انتظار یک XR برای ساخت منابع زیرمجموعه دو مرحله متفاوت‌اند.
محدوده منبع در طراحی امنیت و مالکیت اثر دارد. بسته به نسخه و شیوه تعریف، منبع می‌تواند در محدوده نام‌فضا یا خوشه باشد و قواعد منابع قابل ترکیب باید با آن سازگار باشند. قرارداد را بر اساس مستندات نسخه نصب‌شده طراحی کنید، زیرا الگوهای قدیمی claim و الگوهای جدید منابع نام‌فضایی یکسان نیستند. اگر تیم‌ها با namespace جدا کار می‌کنند، اختیار ایجاد XR، انتخاب Composition و خواندن خروجی‌ها را جدا ارزیابی کنید. اجازه ثبت درخواست در یک namespace نباید به شکل ناخواسته امکان انتخاب زیرساخت یا حساب مدیریتی تیم دیگری را ایجاد کند.
Composition شیوه تحقق قرارداد را بیان می‌کند
Composition مشخص می‌کند Crossplane چگونه با مشاهده XR مجموعه‌ای از منابع مطلوب را بسازد. در روش pipeline، توابع composition پشت سر هم اجرا می‌شوند و داده مشاهده‌شده و وضعیت مطلوب را دریافت یا تکمیل می‌کنند. یک تابع ممکن است منابع ابتدایی را بسازد و تابع دیگری سیاست نام‌گذاری یا وضعیت آمادگی را بر آن‌ها اعمال کند. ترتیب این مراحل مهم است. اگر مرحله بعد بر فیلدی تکیه داشته باشد که مرحله قبل همیشه تولید نمی‌کند، درخواست‌هایی با ورودی خاص ممکن است به نتیجه ناقص برسند. آزمون باید هم مسیر معمول و هم ورودی‌های مرزی را پوشش دهد.
خروجی یک چرخه مطلوب با وضعیت واقعی منابع فرق دارد. تابع می‌تواند اعلام کند یک پایگاه داده باید وجود داشته باشد، اما ساخت واقعی آن به کنترل‌گر مربوط و پاسخ سامانه بیرونی وابسته است. در نتیجه موفقیت اجرای تابع پایان عملیات کاربر محسوب نمی‌شود. تیم پلتفرم باید تعیین کند چه زمانی XR آماده اعلام شود و کدام شرط‌های منابع زیرمجموعه برای آن معنا دارند. برای یک پایگاه داده، ایجاد شناسه سرویس ممکن است قبل از آماده بودن اتصال رخ دهد. اگر وضعیت آماده زود گزارش شود، برنامه توسعه‌دهنده با خطا مواجه می‌شود، هرچند فرایند ساخت در ظاهر موفق است.
منابع ترکیبی و رابطه با ارائه‌دهنده
یک Composition می‌تواند چند منبع با مسئولیت متفاوت بسازد. برای نمونه، تعریف پایگاه داده، یک تنظیم شبکه و یک منبع مربوط به دسترسی می‌توانند اجزای قرارداد باشند. اگر منابع مدیریتی ارائه‌دهنده استفاده شوند، کنترل‌گر ارائه‌دهنده وضعیت مطلوب Kubernetes را با سامانه بیرونی تطبیق می‌دهد. در این زنجیره باید مشخص باشد کدام مؤلفه مالک کدام تغییر است. تغییر دستی روی سامانه بیرونی ممکن است در چرخه بعد با وضعیت مطلوب همسو شود یا بر اساس سیاست مدیریت رفتار دیگری داشته باشد. فرض اینکه هر تغییر بیرونی همیشه حفظ می‌شود می‌تواند هنگام عملیات اضطراری نتیجه غیرمنتظره بسازد.
وابستگی میان منابع نیازمند توجه است. اطلاعات شبکه شاید پیش از ساخت پایگاه داده آماده نباشد و اطلاعات اتصال نیز پس از ایجاد منبع بیرونی به دست آید. توابع و کنترل‌گرها باید بتوانند وضعیت ناقص را در چرخه‌های متوالی ببینند و بدون ساختن منابع تکراری پیش بروند. نام‌های پایدار و رابطه مالکیت به تشخیص منبع موجود کمک می‌کنند. اگر نام بر اساس داده تصادفی هر بار تغییر کند، هر تطبیق می‌تواند منبع تازه‌ای پیشنهاد دهد. برای سرویس دارای هزینه یا داده ماندگار، این خطا فقط آشفتگی در Kubernetes ایجاد نمی‌کند، بلکه هزینه واقعی یا خطر از دست رفتن داده دارد.
اسرار اتصال چگونه در اختیار مصرف‌کننده قرار می‌گیرند؟
توسعه‌دهنده پس از ایجاد XR ممکن است به نام میزبان، نام پایگاه داده و راز اتصال نیاز داشته باشد. این سه داده سطح حساسیت یکسان ندارند. قرارداد خروجی باید روشن کند هر مقدار کجا قرار می‌گیرد، چه کسی می‌تواند آن را بخواند و با چرخش راز چه اتفاقی می‌افتد. قرار دادن گذرواژه در status قابل مشاهده برای گروه گسترده می‌تواند مرز دسترسی را از بین ببرد. همچنین یک منبع Secret با نام قابل پیش‌بینی برای همه تیم‌ها مناسب نیست، مگر اینکه محدوده، مالکیت و مجوزها درست تعریف شده باشند. مسیر تولید و مصرف راز باید از ابتدا تا برنامه آزموده شود.
برای آزمایش چرخش، فقط تغییر مقدار در منبع بیرونی کافی نیست. بررسی کنید کنترل‌گر مقدار تازه را دریافت می‌کند، خروجی در محل درست به‌روز می‌شود و برنامه آن را با روشی سازگار مصرف می‌کند. برنامه‌ای که راز را تنها هنگام آغاز پردازش می‌خواند ممکن است پس از تغییر همچنان از مقدار قدیمی استفاده کند. وضعیت آماده XR مسئله بارگیری مجدد برنامه را حل نمی‌کند. در رخداد احراز هویت، زمان چرخش، نسخه منبع خروجی و زمان راه‌اندازی برنامه را کنار هم بگذارید. این شواهد مشخص می‌کنند خطا در ایجاد راز، انتقال آن یا مصرف داخل برنامه رخ داده است.
نسخه Composition و تغییر برای مصرف‌کنندگان موجود
تغییر یک تابع یا قالب منابع می‌تواند روی درخواست‌های موجود نیز اثر بگذارد. CompositionRevision مکان ثبت نسخه‌ای از Composition را فراهم می‌کند و سیاست انتخاب یا به‌روزرسانی نسخه روی رفتار XRها اهمیت دارد. پیش از انتشار باید معلوم شود کدام مصرف‌کننده نسخه تازه را خودکار می‌گیرد و کدام محیط به انتخاب کنترل‌شده نیاز دارد. یک اصلاح نام فیلد کوچک ممکن است در نگاه توسعه‌دهنده ساده باشد ولی برای محیط‌های موجود به جای تغییر درجا، پیشنهاد ساخت منبع تازه ایجاد کند. مرور تفاوت منابع مطلوب قبلی و بعدی این خطر را قبل از رسیدن به ارائه‌دهنده آشکار می‌کند.
برای انتشار نسخه جدید، یک XR آزمایشی با داده‌ای شبیه تولید انتخاب کنید. منابع حاصل، شناسه‌های بیرونی، وضعیت آمادگی و خروجی اتصال را با نسخه قبلی مقایسه کنید. سپس اثر تغییر روی یک XR موجود را در محیط قابل بازیابی بسنجید. ایجاد موفق از صفر، ارتقای موفق منبع قدیمی را ثابت نمی‌کند. اگر تغییر نیازمند مهاجرت داده است، آن کار باید به عنوان مرحله‌ای مستقل با صاحب مشخص و معیار پایان تعریف شود. برنامه بازگشت نیز باید بداند منابع بیرونی در این فاصله چه تغییرهایی پذیرفته‌اند، زیرا بازگرداندن تعریف Composition لزوماً داده یا اندازه قبلی را برنمی‌گرداند.
حذف، مالکیت و پرونده عیب‌یابی
وقتی توسعه‌دهنده XR را حذف می‌کند، سرنوشت منابع زیرمجموعه و داده بیرونی باید از قبل معلوم باشد. رفتار به رابطه مالکیت، کنترل‌گرها و سیاست‌های منبع مدیریتی بستگی دارد. محیط آزمایش شاید به پاک‌سازی کامل نیاز داشته باشد، ولی پایگاه داده تولید ممکن است به نگه‌داری یا نسخه قابل بازیابی نیاز داشته باشد. نام محیط به تنهایی ضمانت کافی نیست. آزمون حذف باید روی محیط جدا اجرا شود و نتیجه در Kubernetes و سامانه بیرونی هر دو مشاهده شود. یک منبع که از فهرست خوشه ناپدید شده می‌تواند همچنان هزینه بیرونی ایجاد کند یا داده‌ای را طبق سیاست حذف کرده باشد.
فرض کنید XR مدت زیادی در وضعیت ناآماده مانده است. از شرط‌ها و رخدادهای همان XR شروع کنید، Composition و نسخه انتخاب‌شده را بیابید و سپس منابع مطلوب و مشاهده‌شده را مقایسه کنید. اگر منبعی تولید نشده، ورودی و خروجی تابع مربوط را بررسی کنید. اگر تولید شده ولی آماده نیست، وضعیت کنترل‌گر ارائه‌دهنده و پاسخ سامانه بیرونی را بخوانید. اگر همه منابع آماده‌اند ولی XR همچنان انتظار دارد، منطق اعلام آمادگی را بررسی کنید. این مسیر از گسترش بی‌هدف مجوزها یا حذف منابع سالم جلوگیری می‌کند و محل دقیق انتظار را برای مالک همان لایه روشن می‌سازد.
در تحویل API به تیم توسعه، یک درخواست نمونه همراه با رفتار مورد انتظار هنگام تغییر و حذف قرار دهید. برای مثال توضیح دهید افزایش اندازه پایگاه داده چه مدت ممکن است طول بکشد، کدام وضعیت آمادگی برای اتصال کافی است و چه کسی در زمان خطای ارائه‌دهنده باید پیگیری کند. تیم پلتفرم می‌تواند پشتیبانی هر فیلد را با نمونه واقعی نشان دهد و مصرف‌کننده اثر تصمیم خود را پیش از ارسال درخواست ببیند. همین قرارداد قابل آزمون است که ارزش API ترکیبی را در عملیات روزمره مشخص می‌کند.
