شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
Apigee Edge انواع مختلفی از منابع را ارائه میدهد و هر یک از آنها هدف متفاوتی را دنبال میکنند. منابع خاصی وجود دارند که فقط از طریق رابط کاربری Edge، APIهای مدیریتی یا ابزارهایی که از APIهای مدیریتی استفاده میکنند و توسط کاربرانی با نقشها و مجوزهای پیشنیاز، قابل پیکربندی (یعنی ایجاد، بهروزرسانی و/یا حذف) هستند. به عنوان مثال، فقط مدیران سازمانی متعلق به یک سازمان خاص میتوانند این منابع را پیکربندی کنند. این بدان معناست که این منابع را نمیتوان توسط کاربران نهایی از طریق پورتالهای توسعهدهندگان یا به هیچ وسیله دیگری پیکربندی کرد. این منابع عبارتند از:
- پروکسیهای API
- جریانهای مشترک
- محصولات API
- حافظههای نهان
- کیویامها
- فروشگاههای کلیدی و فروشگاههای امانی
- میزبانهای مجازی
- سرورهای هدف
- فایلهای منابع
اگرچه این منابع دسترسی محدودی دارند، اما اگر حتی توسط کاربران مجاز تغییری در آنها ایجاد شود، دادههای قدیمی به سادگی با دادههای جدید جایگزین میشوند. این به این دلیل است که این منابع فقط مطابق با وضعیت فعلی خود در Apigee Edge ذخیره میشوند. استثنائات اصلی این قانون، پروکسیهای API و جریانهای مشترک هستند.
پروکسیهای API و جریانهای مشترک تحت کنترل ویرایش
پروکسیهای API و جریانهای مشترک از طریق ویرایشها مدیریت میشوند -- به عبارت دیگر، ایجاد، بهروزرسانی و مستقر میشوند --. ویرایشها به صورت متوالی شمارهگذاری میشوند، که به شما امکان میدهد تغییرات جدیدی اضافه کنید و آن را به عنوان یک ویرایش جدید ذخیره کنید یا با استقرار یک ویرایش قبلی از پروکسی API/جریان مشترک، یک تغییر را برگردانید. در هر مقطع زمانی، فقط یک ویرایش از یک پروکسی API/جریان مشترک مستقر در یک محیط میتواند وجود داشته باشد، مگر اینکه ویرایشها مسیر پایه متفاوتی داشته باشند.
اگرچه پروکسیهای API و جریانهای مشترک از طریق ویرایشها مدیریت میشوند، اما اگر هرگونه تغییری در یک ویرایش موجود ایجاد شود، هیچ راهی برای بازگشت به حالت قبل وجود ندارد زیرا تغییرات قدیمی به سادگی رونویسی میشوند.
حسابرسیها و تاریخچه
Apigee Edge ویژگیهای Audits و API، Product و Organization History را ارائه میدهد که میتوانند در سناریوهای عیبیابی مفید باشند. این ویژگیها به شما امکان میدهند اطلاعاتی مانند اینکه چه کسی عملیات خاصی (ایجاد، خواندن، بهروزرسانی، حذف، استقرار و لغو استقرار) را انجام داده و چه زمانی این عملیات روی منابع Edge انجام شده است را مشاهده کنید. با این حال، اگر هرگونه عملیات بهروزرسانی یا حذف روی هر یک از منابع Edge انجام شود، Audits نمیتواند دادههای قدیمیتر را در اختیار شما قرار دهد.
ضدالگو
مدیریت منابع Edge (ذکر شده در بالا) مستقیماً از طریق رابط کاربری Edge یا APIهای مدیریتی بدون استفاده از سیستم کنترل منبع
یک تصور غلط وجود دارد که Apigee Edge قادر به بازیابی منابع به حالت قبلی خود پس از تغییرات یا حذفها خواهد بود. با این حال، Edge Cloud بازیابی منابع به حالت قبلی آنها را ارائه نمیدهد. بنابراین، مسئولیت کاربر این است که اطمینان حاصل کند که تمام دادههای مربوط به منابع Edge از طریق مدیریت کنترل منبع مدیریت میشوند، به طوری که در صورت حذف تصادفی یا شرایطی که هرگونه تغییر نیاز به بازگشت به حالت اولیه دارد، دادههای قدیمی بتوانند به سرعت بازیابی شوند. این امر به ویژه برای محیطهای تولیدی که این دادهها برای ترافیک زمان اجرا مورد نیاز هستند، بسیار مهم است.
بیایید این موضوع را با کمک چند مثال و نوع تأثیری که میتواند در صورت عدم مدیریت دادهها از طریق یک سیستم کنترل منبع و تغییر/حذف آگاهانه یا ناآگاهانه آنها ایجاد شود، توضیح دهیم:
مثال ۱: حذف یا تغییر پروکسی API
وقتی یک پروکسی API حذف میشود، یا تغییری روی یک نسخه موجود اعمال میشود، کد قبلی قابل بازیابی نخواهد بود. اگر پروکسی API شامل کد جاوا، جاوا اسکریپت، Node.js یا پایتون باشد که در یک سیستم مدیریت کنترل منبع (SCM) خارج از Apigee مدیریت نمیشود، ممکن است کار و تلاش زیادی برای توسعه از بین برود.
مثال ۲: تعیین پروکسیهای API با استفاده از میزبانهای مجازی خاص
گواهینامهای روی یک میزبان مجازی در حال انقضا است و آن میزبان مجازی نیاز به بهروزرسانی دارد. اگر تعداد زیادی پروکسی API وجود داشته باشد، شناسایی اینکه کدام پروکسیهای API از آن میزبان مجازی برای اهداف آزمایشی استفاده میکنند، ممکن است دشوار باشد. اگر پروکسیهای API در یک سیستم SCM خارج از Apigee مدیریت شوند، جستجو در مخزن آسان خواهد بود.
مثال ۳: حذف keystore/truststore
اگر یک keystore/truststore که توسط پیکربندی یک میزبان مجازی یا سرور هدف استفاده میشود حذف شود، بازیابی آن امکانپذیر نخواهد بود مگر اینکه جزئیات پیکربندی keystore/truststore، از جمله گواهینامهها و/یا کلیدهای خصوصی، در کنترل منبع ذخیره شده باشند.
تأثیر
- اگر هر یک از منابع Edge حذف شوند، بازیابی منبع و محتوای آن از Apigee Edge امکانپذیر نیست.
- درخواستهای API ممکن است با خطاهای غیرمنتظرهای مواجه شوند که منجر به قطع سرویس تا زمان بازیابی منبع به حالت قبلی خود میشود.
- جستجوی وابستگیهای متقابل بین پروکسیهای API و سایر منابع در Apigee Edge دشوار است.
بهترین روش
- از هر SCM استانداردی که با یک خط لوله یکپارچهسازی و استقرار مداوم (CICD) همراه شده است، برای مدیریت پروکسیهای API و جریانهای مشترک استفاده کنید.
- از هر SCM استانداردی برای مدیریت سایر منابع Edge، از جمله محصولات API، حافظههای پنهان، KVMها، سرورهای هدف، میزبانهای مجازی و keystoreها استفاده کنید.
- اگر منابع Edge موجود است، از APIهای مدیریتی برای دریافت جزئیات پیکربندی آنها به عنوان یک فایل JSON/XML استفاده کنید و آنها را در مدیریت کنترل منبع ذخیره کنید.
- هرگونه بهروزرسانی جدید برای این منابع را در مدیریت کنترل منبع مدیریت کنید.
- اگر نیاز به ایجاد منابع جدید Edge یا بهروزرسانی منابع موجود Edge باشد، از JSON/XML payload مناسب ذخیره شده در مدیریت کنترل منبع استفاده کنید و پیکربندی را در Edge با استفاده از APIهای مدیریتی بهروزرسانی کنید.
* KVM های رمزگذاری شده را نمیتوان به صورت متن ساده از API صادر کرد. این مسئولیت کاربر است که سابقهای از مقادیری که در KVM های رمزگذاری شده قرار داده میشود را نگهداری کند.