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