الگوی بد: مدیریت منابع Edge بدون استفاده از مدیریت کنترل منبع

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

‫Apigee Edge انواع مختلفی از منابع را ارائه می‌دهد و هریک از آن‌ها هدف متفاوتی دارند. منابع خاصی وجود دارد که فقط ازطریق «واسط کاربر Edge»، میاناهای برنامه‌سازی کاربردی مدیریت، یا ابزارهایی که از میاناهای برنامه‌سازی کاربردی مدیریت استفاده می‌کنند، و توسط کاربران دارای نقش‌ها و اجازه‌های پیش‌نیاز قابل پیکربندی (یعنی ایجاد، به‌روزرسانی، و/یا حذف) هستند. برای مثال، فقط سرپرستان سازمانی که به سازمان خاصی تعلق دارند می‌توانند این منابع را پیکربندی کنند. یعنی کاربران نهایی نمی‌توانند این منابع را ازطریق درگاه‌های توسعه‌دهندگان یا از هرطریق دیگری پیکربندی کنند. این منابع شامل موارد زیر می‌شود:

  • پراکسی‌های میانای برنامه‌سازی کاربردی
  • جریان‌های هم‌رسانی‌شده
  • محصولات میانای برنامه‌سازی کاربردی
  • حافظه‌های پنهان
  • KVMs
  • فروشگاه‌های کلید و فروشگاه‌های اعتماد
  • میزبانان مجازی
  • سرورهای هدف
  • فایل‌های منبع

اگرچه این منابع دسترسی محدود دارند، اما اگر حتی کاربران مجاز هم تغییری در آن‌ها ایجاد کنند، داده‌های قدیمی به‌سادگی با داده‌های جدید رونویسی می‌شوند. این امر به این دلیل است که این منابع فقط در Apigee Edge براساس وضعیت فعلی‌شان ذخیره می‌شوند. استثناهای اصلی این قانون عبارت‌اند از پراکسی‌های API و جریان‌های مشترک.

پراکسی‌های API و جریان‌های مشترک تحت کنترل بازبینی

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

اگرچه کارگزاران API و جریان‌های مشترک ازطریق بازبینی‌ها مدیریت می‌شوند، اما اگر تغییری در یک بازبینی موجود ایجاد شود، راهی برای برگرداندن آن وجود ندارد زیرا تغییرات قدیمی به‌سادگی بازنویسی می‌شوند.

ممیزی‌ها و سابقه

‫Apigee Edge ویژگی‌های ممیزی‌ها و سابقه API، محصول، و سازمان را ارائه می‌دهد که می‌تواند در سناریوهای عیب‌یابی مفید باشد. این ویژگی‌ها به شما امکان می‌دهند اطلاعاتی مثل اینکه چه کسی عملیات خاصی را انجام داده است (ایجاد، خواندن، به‌روزرسانی، حذف، استقرار، و لغو استقرار) و چه زمانی عملیات روی منابع Edge انجام شده است را مشاهده کنید. بااین‌حال، اگر هرگونه عملیات به‌روزرسانی یا حذف روی هریک از منابع Edge انجام شود، ممیزی‌ها نمی‌توانند داده‌های قدیمی‌تر را به شما ارائه دهند.

الگوی بد

مدیریت منابع Edge (فهرست‌شده در بالا) مستقیماً ازطریق Edge UI یا مدیریت API بدون استفاده از سیستم کنترل منبع

این تصور اشتباه وجود دارد که Apigee Edge می‌تواند منابع را پس‌از اصلاح یا حذف به حالت قبلی خود برگرداند. بااین‌حال، Edge Cloud منابع را به وضعیت قبلی‌شان بازنمی‌گرداند. بنابراین، کاربر مسئول است مطمئن شود که همه داده‌های مربوط به منابع Edge ازطریق مدیریت کنترل منبع مدیریت می‌شود تا درصورت حذف تصادفی یا شرایطی که نیاز به برگرداندن تغییرات باشد، داده‌های قدیمی به‌سرعت بازیابی شود. این موضوع به‌ویژه برای محیط‌های تولید که این داده‌ها برای ترافیک زمان اجرا لازم است اهمیت دارد.

بیایید این موضوع را با کمک چند مثال و نوع تأثیری که می‌تواند ایجاد شود توضیح دهیم اگر داده‌ها ازطریق سیستم کنترل منبع مدیریت نشوند و آگاهانه یا ناآگاهانه اصلاح/حذف شوند:

مثال ۱: حذف یا اصلاح کارگزار API

وقتی یک پراکسی API حذف می‌شود، یا تغییری در یک بازبینی موجود مستقر می‌شود، کد قبلی قابل بازیابی نخواهد بود. اگر کارگزار میانای برنامه‌سازی کاربردی حاوی کد Java،‏ JavaScript،‏ Node.js، یا Python باشد که در سیستم مدیریت کنترل منبع (SCM) خارج از Apigee مدیریت نمی‌شود، ممکن است تلاش و کار توسعه زیادی ازدست برود.

مثال ۲: تعیین پراکسی‌های API بااستفاده از میزبان‌های مجازی خاص

گواهینامه‌ای در میزبان مجازی درحال انقضا است و آن میزبان مجازی باید به‌روزرسانی شود. اگر تعداد پراکسی‌های API زیاد باشد، شناسایی اینکه کدام پراکسی‌های API از آن میزبان مجازی برای اهداف آزمایشی استفاده می‌کنند ممکن است دشوار باشد. اگر کارگزاران نیابتی API در سیستم SCM خارج از Apigee مدیریت شوند، جستجوی مخزن آسان خواهد بود.

مثال ۳: حذف keystore/truststore

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

تأثیر

  • اگر هریک از منابع Edge حذف شود، دیگر نمی‌توان منبع و محتوای آن را از Apigee Edge بازیابی کرد.
  • درخواست‌های API ممکن است با خطاهای غیرمنتظره‌ای مواجه شوند که منجر به قطعی تا زمان بازگرداندن منبع به حالت قبلی خود می‌شود.
  • جستجوی وابستگی‌های متقابل بین پراکسی‌های API و منابع دیگر در Apigee Edge دشوار است.

روال مطلوب

  • از هر SCM استاندارد همراه با خط لوله یکپارچه‌سازی مداوم و استقرار مداوم (CICD) برای مدیریت پراکسی‌های API و جریان‌های مشترک استفاده کنید.
  • از هر SCM استاندارد برای مدیریت منابع دیگر Edge، ازجمله محصولات API، حافظه‌های نهان، KVM، سرورهای هدف، میزبان‌های مجازی، و فروشگاه‌های کلید استفاده کنید.
    • اگر منابع Edge موجودی وجود دارد، از «میاناهای برنامه‌سازی کاربردی» مدیریت برای دریافت جزئیات پیکربندی آن‌ها به‌عنوان بار JSON/XML استفاده کنید و آن‌ها را در مدیریت کنترل منبع ذخیره کنید.
    • به‌روزرسانی‌های جدید این منابع را در مدیریت کنترل منبع مدیریت کنید.
    • اگر نیاز به ایجاد منابع جدید Edge یا به‌روزرسانی منابع موجود Edge وجود دارد، از بار JSON/XML مناسب ذخیره‌شده در مدیریت کنترل منبع استفاده کنید و پیکربندی را در Edge بااستفاده از «میاناهای برنامه کاربردی مدیریت» به‌روز کنید.

* KVMهای رمزگذاری‌شده را نمی‌توان از API به‌صورت نوشتار ساده صادر کرد. این مسئولیت کاربر است که از مقادیر واردشده در KVM رمزگذاری‌شده سابقه نگه دارد.

مطالعه بیشتر