این مقاله به بررسی openshift api برای حفاظت از داده‌ها و ارائه قابلیت پشتیبان‌گیری سلف‌سرویس غیر سرپرست می‌پردازد تا توسعه‌دهندگان بتوانند به‌طور مستقل عمل کنند.


استفاده از openshift api برای حفاظت از داده‌ها در OpenShift


openshift api یکی از اجزای کلیدی این معماری است که با فراهم کردن دسترسی سلف‌سرویس به ابزارهای پشتیبان‌گیری به توسعه‌دهندگان این امکان را می‌دهد تا بدون نیاز به دسترسی مدیریتی عمل کنند.

به گزارش از وبسایت redhat 📣

در محیط‌های چند مستاجری Red Hat OpenShift، مدیریت پشتیبان‌گیری و بازیابی برنامه‌ها اغلب به یک چالش عملیاتی تبدیل می‌شود. سوال کلیدی این است که چگونه می‌توان به تیم‌های توسعه اجازه داد برنامه‌های خود را محافظت کنند، بدون اینکه امتیازات مدیریتی در سطح خوشه‌ای به آنها اعطا شود؟

الزامِ مراجعه همیشگی به سرپرستان پلتفرم برای هر درخواست پشتیبان یا بازیابی، به یک گلوگاه تبدیل شده و سرعت چرخه‌های توسعه و خطوط CI/CD را کاهش می‌دهد. اپراتور OpenShift APIs for Data Protection با ارائه قابلیت پشتیبان‌گیری و بازیابی سلف‌سرویس غیر سرپرست (در حال حاضر پیش‌نمایش فناوری)، راه‌حلی کاربردی برای این مشکل فراهم می‌آورد 🎯.

این قابلیت به‌گونه‌ای طراحی شده که اجازه می‌دهد مجوزهای پشتیبان‌گیری و بازیابی مستقیماً به توسعه‌دهندگان و صاحبان برنامه‌ها واگذار شود، تا آن‌ها بتوانند به‌صورت مستقل و در محدوده امن فضای نام خود عمل کنند؛ بدون نیاز به دسترسی مستقیم به منابع ممتاز.

در هسته این راهکار، مجموعه‌ای از منابع سفارشی با محدوده نام (namespace-scoped) معرفی می‌شود. این منابع شامل مواردی مانند NonAdminBackupStorageLocation (NABSL)، NonAdminBackup (NAB) و NonAdminRestore (NAR) هستند و گردش کار بر اساس تفکیک واضح وظایف ساخته شده است 🔐.

گردش کار به این صورت است که سرپرست خوشه ابتدا با پیکربندی منبع DataProtectionApplication قابلیت سلف‌سرویس را به‌صورت سراسری فعال می‌کند؛ این تنظیم اولیه محافظت‌ها و پارامترهایی مانند تعیین مکان‌های ذخیره‌سازی پشتیبان را برقرار می‌کند. سپس یک برنامه‌نویس با دسترسی محدود در فضای نام خود می‌تواند یک NonAdminBackupStorageLocation (NABSL) ایجاد کند و در صورت نیاز اشیاء NonAdminBackup (NAB) و NonAdminRestore (NAR) را در پروژه‌اش بسازد.

کنترل‌کننده غیر سرپرست اپراتور این درخواست‌ها را بررسی و تأیید کرده و آن‌ها را به عملیات استاندارد Velero ترجمه می‌کند؛ در نتیجه توسعه‌دهنده نیازی به دسترسی مستقیم به فضای نام openshift-adp یا سایر منابع ممتاز ندارد. این رویکرد همزمان استقلال تیم توسعه و اصل کمترین امتیاز را حفظ می‌کند و تضمین می‌کند که یک کاربر در فضای نام نتواند داده‌های دیگران را ببیند، تغییر دهد یا بازیابی کند 🛡️.

شروع به کار: این راهنما یک نمایش ساده را در یک آزمایشگاه خانگی با یک گره OpenShift نسخه 4.20 نشان می‌دهد که از Red Hat OpenShift Data Foundation متصل به یک خوشه Ceph خارجی استفاده می‌کند. این سناریو شامل Noobaa برای فراهم‌سازی ذخیره‌سازی سطل شی سازگار با S3 است و یک مورد پایه‌ای از APIهای OpenShift برای سرویس‌های حفاظت از داده را نمایش می‌دهد.

این راهنما یک جانشین برای مستندات رسمی نیست و نکاتی را پوشش نمی‌دهد از جمله: فضاهای نام پیچیده‌تر با انواع مختلف فضای ذخیره‌سازی، نحوه نصب OpenShift تک‌گره یا نصب OpenShift Data Foundation، و پیکربندی OpenShift برای استفاده مناسب از SSL/TLS. همچنین فرض شده که کاربر با Velero CLI آشنا است.

پیش‌نیازها: قبل از نصب OpenShift APIs for Data Protection مطمئن شوید که خوشه OpenShift (در این مثال OpenShift تک‌گره نسخه 4.20) پیکربندی شده است، یک محل ذخیره‌سازی S3 (ما در این نمونه از OpenShift Data Foundation متصل به Ceph با Noobaa استفاده می‌کنیم) و فضای ذخیره‌سازی سازگار با CSI فراهم باشد.

نصب اپراتور: برای عملکرد صحیح OpenShift APIها برای چارچوب حفاظت از داده، نصب آخرین نسخه پایدار اپراتور ضروری است. نسخه‌ای برابر یا جدیدتر از 1.5 را انتخاب کنید — در این نمایش نسخه 1.5 مورد استفاده قرار گرفته است ⚙️.

راه‌اندازی فروشگاه پشتیبان پیش‌فرض (مدیر): پیش از ایجاد فروشگاه پشتیبان پیش‌فرض، OpenShift APIs for Data Protection نیاز به یک مکان ذخیره‌سازی دارد. از آنجایی که در این راهنما ODF با Noobaa تنظیم شده است، ابتدا یک سطل شی سازگار با S3 ایجاد می‌کنیم. از دستور YAML زیر برای ساخت فایل سطل شی استفاده کنید:

cat > ./oadp_noobaa_objectbucket.yaml

😊