Edge for Private Cloud 4.54.00-এ পরিবর্তন

পরিবর্তনের ওভারভিউ

Edge for Private Cloud 4.54.00-এ একাধিক পরিবর্তন করা হয়েছে যা প্ল্যাটফর্মের নিরাপত্তা সংক্রান্ত পরিস্থিতি উন্নত করে এবং Java 21-এর সাথে চালানোর জন্য প্ল্যাটফর্মের কম্পোনেন্ট আপডেট করে। নিচের দুটি বিভাগে এই পরিবর্তনগুলি কভার করা হয়েছে:

এইসব পরিবর্তন ছাড়াও, নির্দিষ্ট পরিবর্তন শনাক্তকরণ টুল সংক্রান্ত গাইড পর্যালোচনা করুন। এই আপগ্রেডের ফলে আপনার ক্লাস্টারে প্রক্সি, শেয়ার করা ফ্লো বা অন্যান্য আর্টিফ্যাক্টে কোনও পরিবর্তন হয়েছে কিনা তা শনাক্ত করার জন্য এই ইউটিলিটি উপলভ্য করা হয়েছে।

4.53.01 ভার্সনে উপলভ্য তিনটি ক্ষমতা Edge for Private Cloud 4.54.00-এ কাজ করে না। আপগ্রেড করার পরিকল্পনা করার আগে, 4.54.00 ভার্সনে কাজ করে না এমন ফিচার পর্যালোচনা করুন।

4.54.00 ভার্সনে ফিচার কাজ করে না

Edge for Private Cloud 4.54.00-এ নিম্নলিখিত ক্ষমতাগুলি কাজ করে না, যা ভার্সন 4.53.01-এ উপলভ্য। আপনার ডিপ্লয়মেন্টে এগুলির মধ্যে কোনওটি ব্যবহার করা হলে, 4.54.00 ভার্সনে আপগ্রেড করবেন না। 4.53.01 ভার্সন ব্যবহার করা চালিয়ে যান এবং Apigee সহায়তা টিমের সাথে যোগাযোগ করুন।

  • Google Distributed Cloud (GDC) এয়ার-গ্যাপে ইনস্টলেশন। এয়ার-গ্যাপড GDC এনভায়রনমেন্টের জন্য Edge for Private Cloud 4.54.00 সার্টিফায়েড নয়। 4.53.01 ভার্সনের পদ্ধতির জন্য, Google Distributed Cloud air-gapped-এ Apigee ইনস্টল করুন দেখুন।
  • FIPS-চালু করা RHEL 8.X বা Rocky 8.X. FIPS-চালু থাকা RHEL 8.X বা Rocky 8.X হোস্টে Edge for Private Cloud 4.54.00 ইনস্টল করা যায় না। FIPS মোড চালু না থাকলে এইসব অপারেটিং সিস্টেম কাজ করে। এছাড়াও, ৪.৫৪.০০ ভার্সনের কনফিগারেশন সংক্রান্ত বিষয়ে FIPS-নির্দিষ্ট নির্দেশিকা বাদ দেওয়া হয়েছে যা ৪.৫৩.০১ ভার্সনে দেওয়া আছে। এর মধ্যে BCFKS কীস্টোর প্রস্তুতি, FIPS_OS সাইলেন্ট কনফিগারেশন প্রপার্টি ও PKCS12 কীস্টোর কনফিগারেশন অন্তর্ভুক্ত। ভার্সন 4.53.01 সংক্রান্ত নির্দেশিকার জন্য, FIPS-চালিত RHEL 8.X বা Rocky 8.X-এ প্রাইভেট ক্লাউডের জন্য Edge দেখুন।
  • সাউথবাউন্ড হার্ডওয়্যার নিরাপত্তা মডিউল (HSM) ইন্টিগ্রেশন। Edge for Private Cloud 4.54.00-এ মেসেজ প্রসেসর থেকে ব্যাকএন্ড টার্গেট পরিষেবাতে সাউথবাউন্ড TLS কানেকশন কাজ করে না যা Entrust nShield নেটওয়ার্ক HSM ব্যবহার করে। 4.53.01 ভার্সনের পদ্ধতির জন্য, প্রাইভেট ক্লাউডের জন্য Apigee Edge-এর সাউথবাউন্ড হার্ডওয়্যার নিরাপত্তা মডিউল ইন্টিগ্রেশন গাইড দেখুন।

Java Callout নীতিতে পরিবর্তন

Private Cloud 4.54.00-এর জন্য Edge-এ, মেসেজ প্রসেসর, ম্যানেজমেন্ট সার্ভার এবং রাউটার সহ মূল প্ল্যাটফর্ম কম্পোনেন্টগুলি Java 21 LTS-এ চালানোর জন্য আপডেট করা হয়েছে। Java 21, Java প্ল্যাটফর্মকে আধুনিক করে তোলে, যার মধ্যে রয়েছে লিগ্যাসি Java EE ও CORBA মডিউল (JEP 320) সরানো, লিগ্যাসি ইন্টার্নাল ইউটিলিটি ক্লাস সরানো এবং শক্তিশালী মডিউলার এনক্যাপসুলেশন (JEP 403) এনফোর্স করা।

এইসব পরিবর্তনের কারণে, কাস্টম JavaCallout নীতি বা কাস্টম রিসোর্স JAR (প্রক্সি, এনভায়রনমেন্ট বা প্রতিষ্ঠান লেভেলে স্টোর করা) সহ API প্রক্সি, 4.54.00 ভার্সনে আপগ্রেড করার সময় সমস্যার সম্মুখীন হতে পারে।

পরিবর্তনের বিভাগ যা Java Callout-এর উপর প্রভাব ফেলতে পারে

  1. Java EE এবং CORBA মডিউল স্থায়ীভাবে সরিয়ে দেওয়া হয়েছে (JEP 320): Java 8 রানটাইমে আগে তৈরি করা মডিউল (JAXB javax.xml.bind.*, JAF javax.activation.*, JAX-WS javax.xml.ws.* এবং CORBA org.omg.* সহ) Java SE থেকে সরিয়ে দেওয়া হয়েছে। স্ট্যান্ড-অ্যালোন রিপ্লেসমেন্ট বান্ডেল না করে এইসব প্যাকেজ রেফারেন্স করা কলআউট রানটাইমে NoClassDefFoundError-এর সাথে ব্যর্থ হয়।
  2. ইন্টার্নাল ইউটিলিটি ক্লাস সরানো হয়েছে: sun.misc.BASE64Encoder এবং sun.misc.BASE64Decoder-এর মতো পুরনো ইন্টার্নাল হেল্পার সরানো হয়েছে। এইসব ক্লাস কল করার কলআউট NoClassDefFoundError-এর সাথে ব্যর্থ হয়।
  3. Java ইন্টার্নালের শক্তিশালী এনক্যাপসুলেশন (JEP 403): java.base-এ ইন্টার্নাল প্যাকেজ (যেমন sun.security.*, sun.reflect.* এবং com.sun.*) কাস্টম কলআউট থেকে রিফ্লেক্টিভভাবে অ্যাক্সেস করা যাবে না। রানটাইমে InaccessibleObjectException-এর সাথে রিফ্লেক্টিভ কল ব্যর্থ হয়।
  4. সারভাইভিং Java ক্লাসে মেথড সিগনেচার পরিবর্তন ও সরিয়ে দেওয়া: নির্দিষ্ট কিছু Java মডিউলে, Java 21-এ ক্লাসটি থেকে যায়, কিন্তু নির্দিষ্ট কনস্ট্রাক্টর বা মেথড সিগনেচার সরিয়ে দেওয়া, বাতিল করা বা পরিবর্তন করা হয়েছে (যেমন org.w3c.dom.Document-এ নির্দিষ্ট DOM পার্সিং মেথড এবং সম্পর্কিত XML পার্সিং ক্লাস)।

    টুল শনাক্তকরণ: পরিবর্তন শনাক্তকরণ টুল METHOD_SIGNATURE_MODIFICATION বিভাগের অধীনে এইসব ক্লাসের রেফারেন্সকে MEDIUM প্রভাবের নিশ্চয়তা সহ ফ্ল্যাগ করে, যা ডেভেলপারদের পরিবর্তিত পদ্ধতি ইনভোকেশনের জন্য তাদের কলআউটের সোর্স কোড পরীক্ষা করতে প্রম্পট করে।

সমাধান সংক্রান্ত স্ট্র্যাটেজি

আপগ্রেড করার আগে, আপনার Java Callout নীতি এবং কাস্টম JAR রিসোর্স Java 21 রানটাইমের সাথে মানানসই কিনা তা নিশ্চিত করুন। পরিবর্তন শনাক্তকরণ টুল ব্যবহার করলে, আপনার ক্লাস্টার জুড়ে প্রভাবিত API প্রক্সি, শেয়ার করা ফ্লো এবং এনভায়রনমেন্ট বা সংস্থার JAR রিসোর্স শনাক্ত করতে পারবেন।

এই বিভাগে বর্ণিত প্রতিকারমূলক কৌশলগুলি সাধারণ নির্দেশিকা এবং এগুলি পারস্পরিকভাবে স্বতন্ত্র নয়। আপনার অপারেশনাল প্রয়োজনীয়তার উপর নির্ভর করে, আপনি কৌশলগুলি একত্রিত করতে পারেন—উদাহরণস্বরূপ, কৌশল ২ ব্যবহার করে কলআউট সোর্স কোড আধুনিকীকরণ করা এবং মেসেজ প্রসেসর আপগ্রেডের সময় জিরো ডাউনটাইম অর্জন করতে কৌশল ৩B ব্যবহার করে আপডেট করা প্রক্সি রিভিশনগুলি ডিপ্লয় করা।

কৌশল 3A, 3B এবং 3C হল একই অপারেশনাল পদ্ধতি চালানোর তিনটি উপায়: প্রক্সি বান্ডেল পরিবর্তন না করে, বিভিন্ন সময়ে নোড আপগ্রেড করা এবং প্রক্সি পুনরায় স্থাপন করা। আপনার API উপলভ্যতার প্রয়োজনীয়তার উপর ভিত্তি করে এর মধ্যে থেকে একটি বা একাধিক বেছে নিন।

আপনার ডেপ্লয়মেন্টের জন্য সবচেয়ে উপযুক্ত পদ্ধতি বেছে নিতে নিম্নলিখিত সিদ্ধান্ত সংক্রান্ত নির্দেশিকা পর্যালোচনা করুন:

Java কলআউট মিটিগেশনের জন্য সিদ্ধান্ত নেওয়ার নির্দেশিকা:

প্রক্সি বান্ডেল আপডেট ও রিডিপ্লয়মেন্ট প্রয়োজন? পরিস্থিতি বা প্রয়োজনীয়তা সাজেস্ট করা স্ট্র্যাটেজি এটি কী সমাধান করে মূল সীমাবদ্ধতা
হ্যাঁ (শুধু বান্ডেল আপডেট) ডুয়াল-কম্প্যাটিবল লাইব্রেরি আছে; ডাউনটাইম শূন্য হতে হবে স্ট্র্যাটেজি ১: বান্ডেল করা JAR-এর মাধ্যমে ডুয়াল-কম্প্যাটিবল প্রক্সি কোনও ডাউনটাইম ছাড়াই বিভিন্ন ভার্সন জুড়ে অনুপস্থিত লাইব্রেরি রিস্টোর করে 4.54.00-এ conf_system_java.21.enable.external.allowed.packages=true চালু করতে এবং উপলভ্য হতে ডুয়াল-কম্প্যাটিবল স্ট্যান্ডঅ্যালোন লাইব্রেরি প্রয়োজন
হ্যাঁ (সোর্স কোড পরিবর্তন) সোর্স কোড বজায় রাখা হয়েছে; দীর্ঘমেয়াদী সমাধান প্রয়োজন কৌশল ২: বিকল্প প্রয়োগ (কোড ও ডিপেন্ডেন্সি আধুনিকীকরণ) সরিয়ে দেওয়া ক্লাস ও ইন্টার্নাল API ডিপেন্ডেন্সি স্থায়ীভাবে সমাধান করে সোর্স কোড পরিবর্তন ও রিডিপ্লয়মেন্ট প্রয়োজন (রোল-আউটের জন্য স্ট্র্যাটেজি 3A বা 3B-এর সাথে পেয়ার করুন)
না (অপারেশনাল অ্যাপ্রোচ) শিডিউল করা রক্ষণাবেক্ষণের উইন্ডো অনুমোদিত কৌশল 3A: রক্ষণাবেক্ষণের জন্য পরিকল্পিত ডাউনটাইম (ইন-প্লেস রিডিপ্লয়মেন্ট) প্রথমে নোড আপগ্রেড করার, তারপর আপডেট করা প্রক্সি ডিপ্লয় করার অনুমতি দেয় API গ্রাহকদের জন্য শিডিউল করা ডাউনটাইম প্রয়োজন
না (অপারেশনাল অ্যাপ্রোচ) কোনও ডাউনটাইম প্রয়োজন নেই; ডুয়াল JAR বান্ডেল করা যাবে না কৌশল ৩B: নতুন এনভায়রনমেন্ট তৈরি করা (জিরো-ডাউনটাইম মাইগ্রেশন) মাইগ্রেশনের সময় ট্রাফিক বিঘ্নিত না করে 4.53 এবং 4.54 নোড আইসোলেট করে সাময়িক মেসেজ প্রসেসর নোড প্রোকিওর করতে হবে
না (অপারেশনাল অ্যাপ্রোচ) আপগ্রেড করার আগে প্রক্সি বান্ডেল পরিবর্তন করা যাবে না * স্ট্র্যাটেজি 3C: নোড-লেভেল এক্সটার্নাল-লাইব্রেরি প্লেসমেন্ট প্রক্সি বান্ডেল এডিট না করেই নোড-ওয়াইড লাইব্রেরি JAR প্রদান করে নোডের সব প্রক্সি জুড়ে শেয়ার করা হয়েছে; রিফ্লেকশন বা java.* প্যাকেজ সমাধান করে না
না (ক্লোজড-সোর্স থার্ড-পার্টি লাইব্রেরি) Java ইন্টার্নালে রিফ্লেকশন ব্যবহার করে থার্ড-পার্টি ভেন্ডর লাইব্রেরি * কৌশল ৪: JVM ফ্ল্যাগ (--add-opens / --add-exports) ইন্টার্নাল জাভা প্যাকেজের জন্য রিফ্লেকশন সংক্রান্ত বিধিনিষেধ শিথিল করে সরিয়ে দেওয়া ক্লাস বা পদ্ধতি ফিরিয়ে আনা যাবে না; নোড-ওয়াইড প্রযোজ্য

কৌশল ১: বান্ডেল করা JAR-এর মাধ্যমে ডুয়াল-কম্প্যাটিবেল প্রক্সি (ডাউনটাইম শূন্য করার জন্য আপগ্রেড করার আগে পরীক্ষা করুন)

কখন ব্যবহার করবেন: এই স্ট্র্যাটেজি তখন ব্যবহার করুন যখন:

  • ডুয়াল-কম্প্যাটিবল স্ট্যান্ডঅ্যালোন রিপ্লেসমেন্ট লাইব্রেরি উপলভ্য: একটি রিপ্লেসমেন্ট JAR আছে যা প্রয়োজনীয় কার্যকারিতা প্রয়োগ করে এবং সোর্স কোড পরিবর্তন না করেই আপনার API প্রক্সিতে সরাসরি বান্ডেল করা যেতে পারে।
  • আপনি চান যে আপনার বর্তমান API প্রক্সি এবং Java Callout আপনার বর্তমান ভার্সন (যেমন, Edge for Private Cloud 4.53.01) এবং আপগ্রেড করা ভার্সন (Edge for Private Cloud 4.54.00) দুটিতেই নির্বিঘ্নে কাজ করুক।
  • আপনি প্রাইভেট ক্লাউড ক্লাস্টারের জন্য আপনার Edge আপগ্রেড করার আগে আপনার স্টেজিং এবং প্রোডাকশন এনভায়রনমেন্টে সমস্ত পরিবর্তন পরীক্ষা এবং যাচাই করতে চান, যাতে লাইভ ট্রাফিকে কোনও অপ্রত্যাশিত সমস্যা এবং কোনও ডাউনটাইম না থাকে।
  • আপনি Java Callout বিজনেস লজিক আবার লেখা বা রিফ্যাক্টর করা এড়াতে চান।

এটি কীভাবে কাজ করে: Java 8-এ, কিছু লাইব্রেরি (যেমন JAXB javax.xml.bind.* বা অ্যাক্টিভেশন javax.activation.*) সরাসরি Java 8 রানটাইমে তৈরি করা হয়েছিল। এর ফলে, ডেভেলপারদের তাদের প্রক্সি বান্ডেলের মধ্যে অতিরিক্ত JAR ফাইল অন্তর্ভুক্ত করার প্রয়োজন হয়নি। Java 21-এ, Java রানটাইম থেকে এইসব লাইব্রেরি সরিয়ে দেওয়া হয়েছে।

Edge for Private Cloud 4.53.x এবং 4.54.00-এ আপনার প্রক্সি "ডুয়াল-কম্প্যাটিবেল" করতে:

  1. আপনার কলআউটের জন্য প্রয়োজনীয় লাইব্রেরি শনাক্ত করুন (যেমন, JAXB বা অ্যাক্টিভেশন)।
  2. স্ট্যান্ড-অ্যালোন ওপেন-সোর্স রিপ্লেসমেন্ট JAR (যেমন, jakarta.xml.bind-api-2.3.3.jar এবং jaxb-runtime-2.3.8.jar) সংগ্রহ করুন।
  3. আপনি হয় apiproxy/resources/java/-এর অধীনে প্রক্সি বান্ডেলে সরাসরি রিপ্লেসমেন্ট JAR রাখুন অথবা প্রক্সি-লেভেল রিসোর্স ফাইল API ব্যবহার করে প্রক্সি রিভিশনে এটি আপলোড করুন অথবা এনভায়রনমেন্ট লেভেল বা অর্গানাইজেশন লেভেলে রিসোর্স ফাইল হিসেবে এটি আপলোড করুন। রিসোর্স ফাইল ম্যানেজ করার ব্যাপারে আরও তথ্যের জন্য, Apigee রিসোর্স ফাইল ডকুমেন্টেশন দেখুন।
  4. আপগ্রেড করার আগে ডেপ্লয় ও টেস্ট করুন: Private Cloud 4.53.x এবং 4.54.00-এর জন্য Edge-এ মেসেজ প্রসেসর এই বান্ডেল করা JAR থেকে ক্লাস লোড করে। আপনি এই আপডেট করা প্রক্সি বান্ডেল ডেপ্লয় করতে পারবেন এবং আপনার বর্তমান Edge for Private Cloud 4.53.x ক্লাস্টারে সিন্থেটিক ট্রাফিকের মাধ্যমে এটি পরীক্ষা করতে পারবেন।
  5. মেসেজ প্রসেসরে এক্সটার্নাল অনুমোদিত প্যাকেজ লোডিং চালু করুন (4.54.00-এর জন্য প্রয়োজন): ডিফল্ট হিসেবে, Edge for Private Cloud 4.54.00-এ, এক্সটার্নাল বা বান্ডেল করা রিসোর্স JAR থেকে সরানো জাভা প্যাকেজ (যেমন javax.xml.bind.* এবং javax.activation.*) লোড করার সুবিধা বন্ধ করা থাকে (conf_system_java.21.enable.external.allowed.packages=false), তাই ডিফল্ট হিসেবে শুধু JAR বান্ডেল করলে কাজ হবে না। কোড উইথ কনফিগ (CwC) ব্যবহার করে আপনাকে /opt/apigee/customer/application/message-processor.properties-এ এই প্রপার্টি চালু করতে হবে (মেসেজ প্রসেসর নোড আপগ্রেড করার আগে আপনি এই প্রপার্টি কনফিগার করতে পারেন অথবা আপগ্রেড করার পরে এটি সেট করে মেসেজ প্রসেসর রিস্টার্ট করতে পারেন): 
    conf_system_java.21.enable.external.allowed.packages=true
  6. আপগ্রেড করার পরে লাইভ ট্রাফিক সংক্রান্ত কোনও সমস্যা নেই: আপনার ক্লাস্টার পরবর্তীতে conf_system_java.21.enable.external.allowed.packages=true চালু থাকা অবস্থায় Edge for Private Cloud 4.54.00-এ আপগ্রেড করা হলে, মেসেজ প্রসেসরে আগে থেকেই প্রয়োজনীয় JAR উপলভ্য থাকে এবং কোনও সমস্যা ছাড়াই (NoClassDefFoundError) বান্ডেল করা রিসোর্স ফাইল থেকে ক্লাস লোড করে, যার ফলে কোনও ডাউনটাইম ছাড়াই মসৃণভাবে আপগ্রেড করা যায়।

কোডের উদাহরণ: অর্ডার XML যাচাইকরণ ও পার্সিং কলআউট

একটি সাধারণ Apigee Java কলআউট বিবেচনা করুন যা JAXB (JAXBContext এবং Unmarshaller) ব্যবহার করে ইনকামিং XML অর্ডার এক্সট্র্যাক্ট এবং যাচাই করে।

  • সমস্যা সমাধানের আগে (Private Cloud 4.54.00-এর জন্য Edge-এ কাজ করে না): Private Cloud 4.53.x-এর জন্য Edge-এ, প্রক্সি বান্ডেলে শুধুমাত্র কলআউট JAR থাকে, যা JAXB-এর জন্য বিল্ট-ইন Java 8 রানটাইম লাইব্রেরির উপর নির্ভর করে: 
    apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar   <-- No JAXB JAR bundled

    Java কলআউট ইমপ্লিমেন্টেশন:

    package com.example.callout;

// other required imports
import java.io.StringReader;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;

public class OrderXmlParserCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        try {
            String requestXml = messageContext.getMessage().getContent();
            JAXBContext jaxbContext = JAXBContext.newInstance(Order.class);
            Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
            Order order = (Order) unmarshaller.unmarshal(new StringReader(requestXml));
            messageContext.setVariable("order_id", order.getId());
            return ExecutionResult.SUCCESS;
        } catch (Exception e) { }
    }
}

    ব্যর্থতা: Edge for Private Cloud 4.53.x-এ, এটি কোনও সমস্যা ছাড়াই কার্যকর হয়। নোডটি Edge for Private Cloud 4.54.00-এ আপগ্রেড করা হলে, অনুরোধ প্রসেস করার সময় এই প্রক্সি অবিলম্বে ব্যর্থ হয়:

    java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
        at com.example.callout.OrderXmlParserCallout.execute(OrderXmlParserCallout.java:20)
  • সমস্যার সমাধান হওয়ার পরে (Private Cloud 4.53.x এবং 4.54.00-এর জন্য Edge জুড়ে ডুয়াল-কম্প্যাটিবল): আপনাকে Java Callout কোড আবার লিখতে বা রিকম্পাইল করতে হবে না। আপনি সরাসরি স্ট্যান্ডঅ্যালোন JAR প্রদান করে আপনার প্রক্সি ডুয়াল-কম্প্যাটিবল করতে পারেন:
    1. সরাসরি বান্ডেল করুন বা স্ট্যান্ডঅ্যালোন JAR আপলোড করুন: স্ট্যান্ডঅ্যালোন JAXB লাইব্রেরি (jakarta.xml.bind-api-2.3.3.jar এবং jaxb-runtime-2.3.8.jar) পান এবং apiproxy/resources/java/-এর অধীনে আপনার প্রক্সি বান্ডেলের মধ্যে সেগুলি রাখুন: 
      apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar
      jakarta.xml.bind-api-2.3.3.jar
      jaxb-runtime-2.3.8.jar

      বিকল্প হিসেবে, প্রক্সি-লেভেল রিসোর্স ফাইল API ব্যবহার করে অথবা এনভায়রনমেন্ট লেভেল বা অর্গানাইজেশন লেভেলে রিসোর্স ফাইল হিসেবে jakarta.xml.bind-api-2.3.3.jar ও jaxb-runtime-2.3.8.jar আপলোড করুন যাতে একই স্কোপে থাকা সব প্রক্সি প্রতিটি স্বতন্ত্র প্রক্সি বান্ডেলে বান্ডেল না করেই সেগুলি শেয়ার করতে পারে।

      আপনি যদি Maven ব্যবহার করে সোর্স থেকে আপনার প্রক্সি বান্ডেল তৈরি করেন, তাহলে আপনার pom.xml-এ এই ডিপেন্ডেন্সিগুলি ঘোষণা করুন যাতে আপনার বিল্ডের সময় সেগুলি অটোমেটিক প্যাকেজ করা হয়।

    2. আপনার বর্তমান 4.53.x ক্লাস্টারে ডিপ্লয় ও টেস্ট করুন: আপনার বর্তমান Edge for Private Cloud 4.53.x এনভায়রনমেন্টে আপডেট করা প্রক্সি বান্ডেল ডিপ্লয় করুন এবং টেস্ট কল পাঠান। যেহেতু Edge for Private Cloud 4.53.x মেসেজ প্রসেসর এইসব বান্ডেল করা JAR থেকে ক্লাস লোড করে, তাই আপনি যাচাই করতে পারবেন যে কলআউট একইভাবে কাজ করছে কিনা।
    3. CwC-এর মাধ্যমে এক্সটার্নাল অনুমোদিত প্যাকেজ লোডিং চালু করুন: কারণ Private Cloud 4.54.00 (conf_system_java.21.enable.external.allowed.packages=false)-এর জন্য Edge-এ এক্সটার্নাল অনুমোদিত প্যাকেজ লোড করা ডিফল্ট হিসেবে বন্ধ করা থাকে, /opt/apigee/customer/application/message-processor.properties-এ প্রতিটি মেসেজ প্রসেসর নোডে কোড উইথ কনফিগারেশন (CwC) ব্যবহার করে এটি চালু করুন: 
      conf_system_java.21.enable.external.allowed.packages=true
    4. আপগ্রেড করার পরে লাইভ ট্রাফিক সংক্রান্ত কোনও সমস্যা নেই: আপনার 4.53.x এনভায়রনমেন্টে যাচাই করা এবং CwC প্রপার্টির সাথে কনফিগার করা হয়ে গেলে, আপনার প্রক্সি সম্পূর্ণভাবে প্রস্তুত হয়ে যাবে। আপনি যখন নিজের ক্লাস্টারকে Edge for Private Cloud 4.54.00-এ আপগ্রেড করেন, তখন মেসেজ প্রসেসর বান্ডেল করা JAXB ক্লাস লোড করে, যা কোনও ত্রুটি এবং লাইভ ট্রাফিক বিঘ্নিত না হওয়ার বিষয়টি নিশ্চিত করে।

কৌশল ২: বিকল্প প্রয়োগ (কোড ও ডিপেন্ডেন্সি আধুনিকীকরণ)

কখন ব্যবহার করবেন: অ্যাক্টিভ কোডবেসের জন্য সাজেস্ট করা হয় যেখানে প্রক্সি সোর্স কোড সহজেই ম্যানেজ করা যায়। Java 21-এর সাথে মানানসই হওয়ার জন্য এটিই সবচেয়ে পরিষ্কার দীর্ঘমেয়াদী পদ্ধতি। রোলআউট সংক্রান্ত নোট: আধুনিক প্রক্সি রিভিশন ডিপ্লয় করার জন্য মেসেজ প্রসেসর কোঅর্ডিনেশনের প্রয়োজন হয়, তাই এই স্ট্র্যাটেজিকে স্ট্র্যাটেজি 3A (পরিকল্পিত রক্ষণাবেক্ষণ উইন্ডো চলাকালীন) অথবা স্ট্র্যাটেজি 3B (সমান্তরাল মেসেজ প্রসেসরের মাধ্যমে জিরো ডাউনটাইম অর্জন করতে) স্ট্র্যাটেজির সাথে পেয়ার করুন।

এটি কীভাবে কাজ করে: সরিয়ে দেওয়া Java ইন্টার্নাল ক্লাসগুলি অফিসিয়াল স্ট্যান্ডার্ড Java SE API বা ওপেন-সোর্স স্ট্যান্ডঅ্যালোন সমতুল্য দিয়ে প্রতিস্থাপন করুন এবং আপনার প্রক্সি বান্ডেল রিসোর্স ফাইল বা POM-এর মধ্যে সরাসরি প্রয়োজনীয় থার্ড-পার্টি ডিপেন্ডেন্সি প্যাকেজ করুন।

কোডের উদাহরণ:

উদাহরণ ১: পদ্ধতি ও কোড আধুনিকীকরণ (সরিয়ে দেওয়া ইন্টার্নাল ইউটিলিটি পরিবর্তন করা)

Java 8-এ, কলআউটগুলি প্রায়শই ইন্টার্নাল ইউটিলিটি ক্লাস ব্যবহার করে যেমন sun.misc.BASE64Encoder। আধুনিক Java-তে, এইসব ক্লাস সরিয়ে দেওয়া হয়েছে, তবে স্ট্যান্ডার্ড java.util.Base64 API এক্সটার্নাল ডিপেন্ডেন্সি JAR-এর প্রয়োজন ছাড়াই সরাসরি রিপ্লেসমেন্ট প্রদান করে:

  • আগে (পুরনো Java 8 ইমপ্লিমেন্টেশন): 
    // Incompatible in Edge for Private Cloud 4.54.00: sun.misc package removed
import sun.misc.BASE64Encoder;
// other required imports

public class Base64EncodeCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        BASE64Encoder encoder = new BASE64Encoder();
        String encoded = encoder.encode("ApigeePayload".getBytes());
        messageContext.setVariable("encoded_data", encoded);
        return ExecutionResult.SUCCESS;
    }
}
  • পরে (Java 21-কমপ্লায়েন্ট ইমপ্লিমেন্টেশন): 
    // Fully compatible with Java 21: uses standard Java SE java.util.Base64 (no external JARs needed)
import java.util.Base64;
// other required imports

public class Base64EncodeCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        String encoded = Base64.getEncoder().encodeToString("ApigeePayload".getBytes());
        messageContext.setVariable("encoded_data", encoded);
        return ExecutionResult.SUCCESS;
    }
}
উদাহরণ ২: বান্ডেল করা লাইব্রেরি (JAXB নেমস্পেস প্রিফিক্স ম্যাপার) সহ ইমপোর্ট-লেভেল রিফ্যাক্টরিং

Java 8-এ, XML নেমস্পেস প্রিফিক্স কাস্টমাইজ করা API প্রক্সি সাধারণত Sun-এর ইন্টার্নাল JAXB ম্যাপার com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper এক্সটেন্ড করে। Java 21-এ, ইন্টার্নাল Sun প্যাকেজ সরিয়ে দেওয়া হয়েছে এবং অ্যাক্সেস করা যায় না।

স্ট্যান্ডঅ্যালোন ওপেন-সোর্স লাইব্রেরি (org.glassfish.jaxb:jaxb-runtime) com.sun.xml.bind.marshaller.NamespacePrefixMapper-এর অধীনে একই ক্লাস প্রদান করে। সব মেথড সিগনেচার, প্যারামিটার ও রিটার্ন টাইপ একই—কোড পরিবর্তন শুধুমাত্র ইমপোর্ট স্টেটমেন্টে করা হয়েছে:

  • আগে (পুরনো Java 8 ইমপ্লিমেন্টেশন): 
    // In Java 8: Relied on internal Sun class in Java 8 runtime
import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper;
public class CustomNamespaceMapper extends NamespacePrefixMapper {
    @Override
    public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
        if ("http://schemas.example.com/orders".equals(namespaceUri)) {
            return "ord";
        }
        return suggestion;
    }
}
  • পরে (Java 21-কমপ্লায়েন্ট ইমপ্লিমেন্টেশন): 
    // In Java 21: Identical methods and logic; ONLY the import statement changes (".internal." removed)
import com.sun.xml.bind.marshaller.NamespacePrefixMapper;
public class CustomNamespaceMapper extends NamespacePrefixMapper {
    @Override
    public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
        if ("http://schemas.example.com/orders".equals(namespaceUri)) {
            return "ord";
        }
        return suggestion;
    }
}
  • বান্ডেল করা ডিপেন্ডেন্সি কনফিগারেশন (pom.xml): রানটাইমে এই ক্লাস সাপ্লাই করতে, apiproxy/resources/java/-এর মধ্যে স্ট্যান্ডঅ্যালোন JAXB লাইব্রেরি বান্ডেল করুন অথবা আপনার pom.xml-এ সেগুলি ঘোষণা করুন: 
    <dependencies>
    <!-- Standalone JAXB API for Java 21 -->
    <dependency>
        <groupId>jakarta.xml.bind</groupId>
        <artifactId>jakarta.xml.bind-api</artifactId>
        <version>2.3.3</version>
    </dependency>
    <!-- Standalone JAXB Runtime providing com.sun.xml.bind.marshaller.NamespacePrefixMapper -->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.3.8</version>
    </dependency>
</dependencies>

কৌশল ৩A: রক্ষণাবেক্ষণের জন্য পরিকল্পিত ডাউনটাইম (ইন-প্লেস রিডিপ্লয়মেন্ট)

কখন ব্যবহার করবেন: শিডিউল করা অপারেশনাল রক্ষণাবেক্ষণ উইন্ডো সহ পরিবেশের জন্য সাজেস্ট করা হয় যেখানে সংক্ষিপ্ত পরিষেবা বিঘ্ন গ্রহণযোগ্য।

পদ্ধতি:

  1. API গ্রাহকদের সাথে শিডিউল করা রক্ষণাবেক্ষণ উইন্ডো সমন্বয় করুন।
  2. আপগ্রেড পাথ গাইড অনুসরণ করে আপনার Edge for Private Cloud কম্পোনেন্টগুলি 4.54.00 ভার্সনে আপগ্রেড করুন।
  3. New Edge UI বা Apigee Management API (Deployments) ব্যবহার করে আপনার API প্রক্সির প্রি-কম্পাইল করা, 4.54.00-কম্প্যাটিবল রিভিশন ডিপ্লয় করুন।
  4. মেসেজ প্রসেসরে সিন্থেটিক টেস্ট অনুরোধ পাঠিয়ে এবং ট্রেস টুল ব্যবহার করে লগ চেক করে কলআউট এক্সিকিউশন যাচাই করুন।
  5. রক্ষণাবেক্ষণ উইন্ডো বন্ধ করে পাবলিক ট্রাফিক আবার চালু করুন।

কৌশল ৩খ: নতুন এনভায়রনমেন্ট তৈরি করা (জিরো-ডাউনটাইম মাইগ্রেশন)

কখন ব্যবহার করবেন: মিশন-ক্রিটিক্যাল প্রোডাকশন এনভায়রনমেন্টের জন্য সাজেস্ট করা হয় যেখানে কোনও ডাউনটাইম প্রয়োজন হয় না। আপনার Java Callout আপডেট করে Java 8 এবং Java 21-এ একসাথে কাজ করার জন্য উপযুক্ত করে তুলতে না পারলে এটি ব্যবহার করুন।

এটি কীভাবে কাজ করে: এই স্ট্র্যাটেজিতে এক বা একাধিক নতুন এনভায়রনমেন্ট প্রোকিওর করা হয় যাতে আপনি বিভিন্ন ভার্সনের মেসেজ প্রসেসর নোড এতে ওয়্যার করতে পারেন। পরবর্তীকালে, 4.53.X মেসেজ প্রসেসরের সাথে যুক্ত এনভায়রনমেন্টে Java 8-এর সাথে মানানসই প্রক্সি এবং 4.54.00 মেসেজ প্রসেসরের সাথে যুক্ত এনভায়রনমেন্টে Java 21-এর সাথে মানানসই প্রক্সি ডিপ্লয় করুন। তারপর, শুধুমাত্র Java 21-এর সাথে মানানসই প্রক্সিতে ট্রাফিক রুট করার জন্য লোড ব্যালেন্সার বা অন্যান্য রাউটিং টেকনিক ব্যবহার করুন।

এই স্ট্র্যাটেজির জন্য, কীভাবে সংস্থা, এনভায়রনমেন্ট এবং মেসেজ প্রসেসর ইন্টার‍্যাক্ট করে তা বোঝা হল জিরো-ডাউনটাইম কাটওভারের মূল চাবিকাঠি (আরও তথ্যের জন্য, Apigee Edge সংস্থার স্ট্রাকচার দেখুন):

  • Apigee সংস্থা হল একটি টপ-লেভেল অ্যাডমিনিস্ট্রেটিভ বাউন্ডারি যার মধ্যে একাধিক এনভায়রনমেন্ট (যেমন, prod, test) থাকে।
  • একটি API প্রক্সি রিভিশন নির্দিষ্ট এনভায়রনমেন্টে ডেপ্লয় করা হয়েছে। শুধুমাত্র সেই এনভায়রনমেন্টের সাথে স্পষ্টভাবে যুক্ত মেসেজ প্রসেসর প্রক্সি রিভিশন লোড ও এক্সিকিউট করে।
+------------------------------------------------------------------------+
|                          Apigee Organization                           |
|                                                                        |
|  Existing Environment (prod)            Temporary Env (prod-migration) |
|  +--------------------------------+     +----------------------------+ |
|  | Current 4.53.01 MP Nodes       |     | New 4.54.00 MP Nodes       | |
|  |               |                |     |              |             | |
|  | Proxy Rev N (4.53.01)          |     | Proxy Rev N+1 (Modernized) | |
|  +--------------------------------+     +----------------------------+ |
+------------------------------------------------------------------------+
                   ^                                    ^
                   | Step 1: Normal Live                | Step 2: Canary
                   |         Traffic (prod)             | Step 3: Complete
          +------------------------------------------------------+
          |       Upstream Load Balancer / Ingress Router        |
          +------------------------------------------------------+

পদ্ধতি:

  1. সাময়িক এনভায়রনমেন্ট তৈরি করুন: আপনার প্রতিষ্ঠানের মধ্যে (ভার্চুয়াল হোস্ট ও এনভায়রনমেন্ট সেট-আপ করা অনুসরণ করে) ডেডিকেটেড ভার্চুয়াল হোস্ট ও পোর্ট সহ নতুন এনভায়রনমেন্ট (যেমন, prod-migration) তৈরি করুন।
  2. 4.54.00 মেসেজ প্রসেসর নোড প্রোভিশন করা: নতুন বা অস্থায়ী VM ইনস্ট্যান্সে Edge for Private Cloud 4.54.00 ইনস্টল করুন এবং এইসব নোড prod-migration-এর সাথে বাইন্ড করুন (মেসেজ প্রসেসর যোগ করা দেখুন)।
  3. প্রভাবিত প্রক্সি শনাক্ত করা এবং আপডেট করা রিভিশন তৈরি করা: Java Callouts ব্যবহার করে API প্রক্সি শনাক্ত করুন (পরিবর্তন শনাক্তকরণ টুল ব্যবহার করে) এবং Edge for Private Cloud 4.54.00-এর সাথে মানানসই Java Callouts (কৌশল ১ বা কৌশল ২ প্রয়োগ করে) সহ প্রতিটি প্রভাবিত প্রক্সির একটি নতুন রিভিশন তৈরি করুন।
  4. অস্থায়ী এনভায়রনমেন্টে আধুনিক প্রক্সি রিভিশন ডেপ্লয় করুন: আপডেট করা, মানানসই প্রক্সি রিভিশন শুধুমাত্র prod-migration-এ ডেপ্লয় করুন।
  5. যাচাই করুন এবং ট্রাফিক শিফট করুন: নতুন ভার্চুয়াল হোস্টের বিরুদ্ধে সিন্থেটিক যাচাইকরণ পরীক্ষা চালান। যাচাই করা হয়ে গেলে, prod থেকে prod-migration-এ ক্লায়েন্ট ট্রাফিক রিডাইরেক্ট করতে আপনার এক্সটার্নাল লোড ব্যালেন্সার (F5, NGINX) কনফিগার করুন।
  6. আসল নোড আপগ্রেড করে আবার ফিরে যান: prod থেকে লিগ্যাসি প্রক্সি আনডিপ্লয় করুন। আপগ্রেড পাথ গাইড অনুসরণ করে আসল মেসেজ প্রসেসর নোড 4.54.00-এ আপগ্রেড করুন। prod-এ আধুনিকীকৃত প্রক্সি রিভিশন ডিপ্লয় করুন, লোড ব্যালেন্সার ট্রাফিককে আবার prod-এ রিডাইরেক্ট করুন এবং অপারেশন যাচাই করুন।
  7. অস্থায়ী এনভায়রনমেন্ট ডিকমিশন করা: prod-migration থেকে প্রক্সি আনডিপ্লয় করুন, অস্থায়ী মেসেজ প্রসেসর নোড সরিয়ে দিন এবং অস্থায়ী এনভায়রনমেন্ট মুছে দিন।

কৌশল 3C: নোড-লেভেল এক্সটার্নাল-লাইব্রেরি প্লেসমেন্ট (শেয়ার করা ফলব্যাক লাইব্রেরি)

কখন ব্যবহার করবেন: আপনার কাছে একাধিক API প্রক্সি থাকলে এটি ব্যবহার করার সাজেশন দেওয়া হয়, যেগুলি Java 21-এ সরিয়ে দেওয়া Java ক্লাসের উপর নির্ভর করে এবং আপগ্রেড করার আগে প্রতিটি আলাদা প্রক্সি বান্ডেল রিকম্পাইল বা রি-প্যাকেজ করা অপারেশনালভাবে সম্ভব নয়।

এটি কীভাবে কাজ করে: Edge for Private Cloud 4.54.00-এ, মেসেজ প্রসেসর একটি নির্দিষ্ট নোড ডিরেক্টরি থেকে অনুপস্থিত জাভা ক্লাস লোড করার জন্য একটি মেকানিজম প্রদান করে: $APIGEE_ROOT/data/edge-message-processor/external-lib।

এই মেকানিজম চালু করা থাকলে, ডিফল্ট রেজোলিউশনে ফিরে যাওয়ার আগে, মেসেজ প্রসেসর এই ডিরেক্টরিতে মিসিং ক্লাস চেক করে। আপনি থার্ড-পার্টি লাইব্রেরি JAR থেকে সোর্স করে বা প্রয়োজনীয় ক্লাস JAR-এ বান্ডেল করে এবং external-lib-এ রেখে অনুপস্থিত ক্লাসগুলি প্রদান করতে পারেন।

পদ্ধতি:

  1. প্রতিটি মেসেজ প্রসেসর নোডে এক্সটার্নাল লাইব্রেরি ডিরেক্টরি তৈরি করুন: 
    mkdir -p /opt/apigee/data/edge-message-processor/external-lib
  2. প্রয়োজনীয় JAR ডিরেক্টরিতে রাখুন: প্রয়োজনীয় ক্লাস সহ JAR ফাইল /opt/apigee/data/edge-message-processor/external-lib-এ কপি করুন।
  3. উপযুক্ত ফাইল অ্যাক্সেস করার পারমিশন সেট করুন: apigee পরিষেবা ব্যবহারকারীর কাছে রিড পার্মিশন আছে কিনা তা নিশ্চিত করুন: 
    chown -R apigee:apigee /opt/apigee/data/edge-message-processor/external-lib
chmod 755 /opt/apigee/data/edge-message-processor/external-lib
chmod 644 /opt/apigee/data/edge-message-processor/external-lib/*.jar
  4. মেসেজ প্রসেসর কনফিগারেশনে এক্সটার্নাল প্যাকেজ লোডিং চালু করুন: Private Cloud 4.54.00-এর জন্য Edge-এ ডিফল্ট হিসেবে, এক্সটার্নাল অনুমোদিত প্যাকেজ লোড করা বন্ধ করা থাকে (conf_system_java.21.enable.external.allowed.packages=false)। /opt/apigee/data/edge-message-processor/external-lib থেকে ক্লাস সমাধান ও লোড করার জন্য মেসেজ প্রসেসর চালু করতে, আপনাকে কনফিগারেশন সহ কোড (CwC) ব্যবহার করে /opt/apigee/customer/application/message-processor.properties-এ এই প্রপার্টি চালু করতে হবে: 
    conf_system_java.21.enable.external.allowed.packages=true
  5. মেসেজ প্রসেসর রিস্টার্ট করুন: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

কৌশল ৪: JVM ফ্ল্যাগ (--add-opens / --add-exports — সতর্কতা এবং শেষ অবলম্বন)

কখন ব্যবহার করবেন: এই স্ট্র্যাটেজিটি ক্লোজড-সোর্স থার্ড-পার্টি ভেন্ডর লাইব্রেরির জন্য শেষ অবলম্বন হিসেবে ব্যবহার করুন যেখানে সোর্স কোড উপলভ্য নয়, ভেন্ডররা Java 21 আপডেট রিলিজ করেনি এবং JAR ইন্টার্নাল Java প্যাকেজে রিফ্লেক্টিভ অ্যাক্সেসের উপর কঠোরভাবে নির্ভর করে।

পদ্ধতি:

  1. রিফ্লেকশনের জন্য ব্যবহৃত অ্যাক্সেস করা যায় না এমন প্যাকেজ শনাক্ত করুন: আপনার থার্ড-পার্টি লাইব্রেরির মাধ্যমে রিফ্লেক্টিভভাবে অ্যাক্সেস করা ইন্টার্নাল Java মডিউল ও প্যাকেজ নির্ধারণ করুন। মনে রাখবেন: এই রিফ্লেকশন সংক্রান্ত সমস্যা শুধুমাত্র Java 21-এ Edge for Private Cloud 4.54.00-এর ক্ষেত্রে হয় এবং 4.53.x ভার্সনের লগে দেখা যাবে না। প্রয়োজনীয় মডিউল ও প্যাকেজ শনাক্ত করার জন্য InaccessibleObjectException-এর জন্য আপগ্রেড-পরবর্তী মেসেজ প্রসেসর লগ (/opt/apigee/var/log/edge-message-processor/system.log) চেক করুন: 
    java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module
  2. কনফিগারেশন সহ কোড (CwC) ব্যবহার করে /opt/apigee/customer/application/message-processor.properties এডিট করুন (ফাইলটি না থাকলে তৈরি করুন)।
  3. bin_setenv_ext_jvm_opts-এ টার্গেট করা --add-opens বা --add-exports ফ্ল্যাগ যোগ করুন। 
    # Configure targeted JVM module access for closed-source legacy callouts (enclosed in double quotes)
bin_setenv_ext_jvm_opts="-XX:+UseG1GC -XX:+AlwaysPreTouch --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.misc=ALL-UNNAMED --add-opens java.base/sun.security.util=ALL-UNNAMED --add-opens java.base/sun.security.x509=ALL-UNNAMED"
  4. ফাইলের সঠিক মালিকানা ও অনুমতি নিশ্চিত করুন: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
chmod 644 /opt/apigee/customer/application/message-processor.properties
  5. apigee-service ব্যবহার করে মেসেজ প্রসেসর রিস্টার্ট করুন: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

TLS এবং সাইফার স্যুট পরিবর্তন

Edge for Private Cloud 4.54.00-এ, মেসেজ প্রসেসর, ম্যানেজমেন্ট সার্ভার এবং রাউটার সহ কোর প্ল্যাটফর্ম কম্পোনেন্টগুলি Java 21 LTS-এ চালানোর জন্য আপডেট করা হয়েছে। এই আপডেট ডিফল্ট হিসেবে TLS 1.3 (JEP 332) চালু করার মাধ্যমে ক্রিপ্টোগ্রাফিক নিরাপত্তা আধুনিক করে তোলে। মেসেজ প্রসেসর এখন আউটবাউন্ড ব্যাকএন্ড কানেকশনের জন্য TLS 1.3-কে পছন্দের প্রোটোকল হিসেবে ব্যবহার করে, ব্যাকএন্ডে এটি কাজ না করলে TLS 1.2-এ ফিরে যায়।

পুরনো ব্যাকএন্ড সংক্রান্ত প্রয়োজনীয়তা ও প্রতিকার

Java 21 ক্রিপ্টোগ্রাফিক বেসলাইন, jdk.tls.disabledAlgorithms-এ ডিফল্ট হিসেবে বন্ধ করা প্রোটোকল ও সাইফার সুইটের তালিকা আপডেট করে (যেমন, লিগ্যাসি TLS প্রোটোকল ও নন-ফরওয়ার্ড-সিক্রেট স্ট্যাটিক RSA কী-এক্সচেঞ্জ সুইট: TLS_RSA_*)। আপনি নিজের Java 21 রানটাইম প্রদান করেন বলে, বন্ধ করা প্রোটোকল ও সাইফার সুইটের সঠিক তালিকা আপনার নির্দিষ্ট Java 21 ইমপ্লিমেন্টেশনের উপর নির্ভর করে।

আপনার আগে থেকে থাকা API প্রক্সি যদি পুরনো ব্যাকএন্ড ইনফ্রাস্ট্রাকচারের সাথে কানেক্ট করে, যার জন্য বন্ধ করা প্রোটোকল বা স্ট্যাটিক RSA সাইফার প্রয়োজন হয়, তাহলে নিম্নলিখিত অ্যাকশন পর্যালোচনা করুন:

  • ব্যাকএন্ড নিরাপত্তা আধুনিকীকরণ (প্রস্তাবিত): আধুনিক ECDHE সাইফার স্যুট সহ TLS 1.2 বা TLS 1.3-কে সাপোর্ট করার জন্য টার্গেট সার্ভার এবং লোড ব্যালেন্সার আপগ্রেড করুন। আপনার API প্রক্সিতে প্রোটোকল এবং সাইফার স্যুট কনফিগার করতে, Edge থেকে ব্যাকএন্ডে TLS কনফিগার করা এবং TLS/SSL TargetEndpoint কনফিগারেশন রেফারেন্স (অথবা TargetServers ব্যবহার করলে ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালেন্সিং) দেখুন।
  • CwC ব্যবহার করে লিগ্যাসি অ্যালগরিদম আবার চালু করা (আপগ্রেড করার সময় ট্রানজিশনাল পরিমাপ): প্ল্যাটফর্ম আপগ্রেড করার আগে ব্যাকএন্ড আপগ্রেড সম্পূর্ণ করা না গেলে, আপনি কোড উইথ কনফিগ (CwC) ব্যবহার করে সাময়িকভাবে প্রয়োজনীয় অ্যালগরিদম আবার চালু করতে পারবেন:
    1. আপনার Java 21 ইনস্টলেশনে ডিফল্ট jdk.tls.disabledAlgorithms ভ্যালু চেক করুন (যেমন, $JAVA_HOME/conf/security/java.security-এ)।
    2. /opt/apigee/customer/application/message-processor.properties-এ conf_jvmsecurity_jdk.tls.disabledAlgorithms ওভাররাইড করুন, বন্ধ করা অ্যালগরিদমের একই তালিকা ব্যবহার করে, শুধু TLS_RSA_* এন্ট্রি সরিয়ে দিন (বন্ধ করা অন্যান্য সব অ্যালগরিদম অক্ষত রাখুন যাতে বাকি সুরক্ষা চালু থাকে)।
    3. apigee-service ব্যবহার করে মেসেজ প্রসেসর রিস্টার্ট করুন। ব্যাকএন্ড ECDHE সাইফার স্যুট সাপোর্ট করলে এই ওভাররাইড সরিয়ে দিন।
  • কাস্টম সাইফার স্যুট সাদাতালিকা আপডেট করা: আপনি আগে conf_http_HTTPTransport.ssl.cipher.suites.whitelist ওভাররাইড করে থাকলে, আপগ্রেড করার আগে এটি পর্যালোচনা করুন। Java 21-এ স্ট্যাটিক RSA স্যুট (TLS_RSA_*) আর কাজ করে না, তাই শুধুমাত্র এইসব স্যুট আছে এমন সাদাতালিকা থাকলে, মেসেজ প্রসেসরে কোনও ব্যবহারযোগ্য সাইফার থাকে না এবং ব্যাকএন্ড কল no cipher suites in common-এর সাথে ব্যর্থ হয়। TLS_RSA_* এন্ট্রি সরিয়ে দিন এবং আপনার Java 21 ইমপ্লিমেন্টেশন দ্বারা সমর্থিত আধুনিক সাইফার স্যুট কনফিগার করুন। আপনি এই প্রপার্টি ওভাররাইড না করে থাকলে, 4.54.00 ডিফল্ট ভার্সনে আগে থেকেই কাজ করে এমন সুইট থাকে এবং কোনও পরিবর্তন করার প্রয়োজন হয় না।
  • ইন্টার্নাল রাউটার থেকে মেসেজ প্রসেসর সাইফার আপডেট করুন: আপনি যদি আগে স্ট্যাটিক RSA সুইট দিয়ে conf_message-processor-communication_local.http.ssl.ciphers ওভাররাইড করে থাকেন, তাহলে আপগ্রেড করার আগে আপনার Java 21 ইমপ্লিমেন্টেশন দ্বারা সমর্থিত আধুনিক সাইফার সুইট দিয়ে এটি আপডেট করুন, অন্যথায় রাউটার মেসেজ প্রসেসরের সাথে TLS হ্যান্ডশেক সম্পূর্ণ করতে পারবে না। তারপর মেসেজ প্রসেসর রিস্টার্ট করুন: 
    apigee-service edge-message-processor restart
     রাউটার ও মেসেজ প্রসেসরের মধ্যে TLS কনফিগার করা দেখুন।

Edge কম্পোনেন্টের মধ্যে TLS কনফিগার করার ব্যাপারে বিস্তারিত জানতে, Router ও Message Processor-এর মধ্যে TLS কনফিগার করা দেখুন।

পরিবর্তন শনাক্তকরণ টুল

Apigee একটি পরিবর্তন শনাক্তকরণ টুল প্রদান করে যা আপনার ক্লাস্টার স্ক্যান করে ডিপ্লয় করা API প্রক্সি, নীতি, শেয়ার করা ফ্লো এবং রিসোর্স JAR খুঁজে বের করে, যা Edge for Private Cloud 4.54.00-এ আপগ্রেড করার ফলে প্রভাবিত হতে পারে।

এই টুলটি সম্ভাব্য আপগ্রেড ব্লকার শনাক্ত করে—যার মধ্যে রয়েছে Java 21-এর সাথে মানানসই নয় এমন লাইব্রেরি, দৃঢ়ভাবে এনক্যাপসুলেট করা ইন্টার্নাল API, পুরনো নীতি বাতিল করা এবং OpenLDAP RDN সীমা—এবং আপনাকে উপযুক্ত প্রতিকার কৌশল বেছে নিতে সাহায্য করার জন্য অ্যাকশনেবল রিপোর্ট তৈরি করে।

সম্পূর্ণ পূর্বশর্ত, ডাউনলোড করার নির্দেশাবলী, কমান্ড-লাইন সিনট্যাক্স এবং স্যাম্পেল রিপোর্টের জন্য, নির্দিষ্ট পরিবর্তন শনাক্তকরণ টুল গাইড দেখুন।