Google Cloud در ۱۵ اکتبر ۲۰۲۶ نسخهٔ Apigee Edge for Private Cloud ۴.۵۴.۰۰ را منتشر کرد و آن را در مسیر پشتیبانی بلندمدت قرار داد. این نسخه برای سازمانهایی که API Gateway را روی زیرساخت خودشان اجرا میکنند مهم است، اما ارتقای آن یک بهروزرسانی ساده و بدون ریسک نیست؛ چون Java ۸، رابط Classic UI و مؤلفهٔ مستقل apigee-sso حذف شدهاند و چند تغییر ناسازگار باید پیش از اجرای production بررسی شود.
اسلاید اول:

پشتیبانی Apigee Edge ۴.۵۴ و LTS تا چه زمانی ادامه دارد؟
نسخهٔ Apigee Edge ۴.۵۴.۰۰.۰۰، ۱۸ ماه پشتیبانی کامل تا آوریل ۲۰۲۸ و سپس ۱۸ ماه نگهداری تا اکتبر ۲۰۲۹ دارد. بعد از پایان این دوره، برای دریافت اصلاحات نرمافزاری، رفع آسیبپذیریها و پشتیبانی فنی باید به نسخهٔ LTS بعدی مهاجرت کرد. بنابراین LTS بودن، جایگزین برنامهٔ lifecycle و تست ارتقا نیست؛ بلکه یک پنجرهٔ زمانی بهتر برای برنامهریزی تغییر فراهم میکند.
تغییر Java در Apigee Edge ۴.۵۴ و ریسک Proxyهای سفارشی
در نسخهٔ جدید Java ۸ کنار گذاشته شده و اجزای مختلف روی Java ۱۷ و Java ۲۱ اجرا میشوند. Cassandra و ZooKeeper از Java ۱۷ استفاده میکنند و Management Server، Message Processor، Router و Qpid Broker-J به Java ۲۱ نیاز دارند. این تفکیک باید در inventory سرورها، imageهای نصب و اسکریپتهای عملیاتی ثبت شود.
مهمترین ریسک برای تیمهای توسعه، API Proxyهایی است که JavaCallout سفارشی یا JARهای داخلی دارند. تغییر runtime به Java ۲۱ میتواند به ناسازگاری کتابخانهها، خطای class loading یا تفاوت در رفتار TLS منجر شود. قبل از ارتقا، همهٔ JARها را با JDK جدید build و در محیط staging اجرا کنید؛ سناریوهای خطا، timeout، احراز هویت و rollback را هم ثبت کنید.
مهاجرت Apigee Edge ۴.۵۴ از Classic UI به New Edge UI
رابط Classic UI با edge-management-ui جایگزین شده و New Edge UI تنها رابط مدیریتی موجود در نسخهٔ ۴.۵۴ است. پورت پیشفرض نیز از ۹۰۰۰ به ۳۰۰۱ تغییر میکند؛ بنابراین ruleهای فایروال، load balancer، health checkها و bookmarkهای تیم عملیات باید بازبینی شوند. تنظیمات سفارشی Classic UI نیز خودکار منتقل نمیشوند و باید پیش از تغییر، export و مستندسازی شوند.
اگر سازمان از Apigee SSO استفاده میکند، مؤلفهٔ مستقل apigee-sso حذف شده و broker هویت یکپارچه در apigee-openldap قرار گرفته است. پیکربندی SSO قدیمی خودکار migrate نمیشود؛ یک backup کامل و معتبر از LDAP بگیرید و مسیر بازگردانی را پیش از ارتقا آزمایش کنید. سازمانهایی که SSO ندارند، این بخش را باید بهعنوان کنترل عدمنیاز ثبت کنند.
TLS در Apigee Edge ۴.۵۴، رمزنگاری و وابستگیهای شبکه
Java ۲۱، TLS ۱.۳ را بهصورت پیشفرض فعال میکند و در صورت نیاز به TLS ۱.۲ با cipherهای forward-secret برمیگردد. cipherهای استاتیک TLS_RSA_* دیگر پشتیبانی نمیشوند. اگر در تنظیمات Message Processor یا backendها فقط cipherهای قدیمی ثبت شده باشد، handshake شکست میخورد و Router نمیتواند به Message Processor وصل شود.
پیش از ارتقا، فهرست cipherهای سفارشی، گواهیها، truststoreها، load balancerها و سرویسهای backend را استخراج کنید. با یک محیط آزمایشی، handshakeهای TLS ۱.۳ و TLS ۱.۲، اتصال به سرویسهای قدیمی و رفتار health check را بررسی کنید. تغییرات نسخهٔ Nginx Edge Router به ۱.۳۰.۰ نیز باید در تست مسیرهای proxy و headerها دیده شود.


چکلیست عملی ارتقای Apigee Edge ۴.۵۴
۱. از LDAP، پیکربندی runtime، certificateها، keystoreها و دادههای حیاتی backup بگیرید و restore واقعی را تست کنید. ۲. فهرست JavaCalloutها، JARهای سفارشی، policyها و وابستگیهای داخلی را بسازید و با Java ۲۱ آزمایش کنید. ۳. فایروال و load balancer را برای New Edge UI روی پورت ۳۰۰۱ آماده کنید و مسیرهای قدیمی پورت ۹۰۰۰ را مستند کنید. ۴. سناریوهای SSO، LDAP، Basic Authentication، کاربران مدیریتی و recovery account را در staging اجرا کنید. ۵. cipherهای TLS، گواهیها، اتصال backend و API Proxyهای حساس را با TLS ۱.۳ و TLS ۱.۲ بررسی کنید. ۶. پنجرهٔ تغییر، معیارهای موفقیت، روش rollback و health check بعد از restart را مشخص کنید.
Apigee Edge ۴.۵۴ برای سازمانهایی که به چرخهٔ پشتیبانی بلندتر و runtimeهای جدید نیاز دارند، انتشار مهمی است؛ اما تغییرات Java، UI، SSO و TLS همزمان شدهاند. ابتدا inventory و backup را قطعی کنید، سپس ارتقا را در staging انجام دهید و فقط بعد از تأیید proxyهای سفارشی، دسترسی مدیریتی و مسیر rollback به production بروید. برای مقایسهٔ رویکرد ارتقای زیرساخت با بهروزرسانی توزیع، راهنمای اخیر Ubuntu ۲۶.۱۰ و ارتقای امن نیز مفید است.
منبع رسمی: یادداشت انتشار Google Cloud برای Apigee Edge ۴.۵۴





