Edge for Private Cloud 4.54.00 में हुए बदलाव

बदलावों की खास जानकारी

Edge for Private Cloud 4.54.00 में कई बदलाव किए गए हैं. इनसे प्लैटफ़ॉर्म की सुरक्षा को बेहतर बनाया गया है. साथ ही, प्लैटफ़ॉर्म के कॉम्पोनेंट को अपडेट किया गया है, ताकि वे Java 21 के साथ काम कर सकें. यहां दिए गए दो सेक्शन में इन बदलावों के बारे में बताया गया है:

• Java Callout की नीति में हुए बदलाव
• टीएलएस और साइफ़र सुइट में हुए बदलाव

इन बदलावों के अलावा, बदलाव की पहचान करने वाले टूल की गाइड देखें. इस सुविधा को आपके क्लस्टर में प्रॉक्सी, शेयर किए गए फ़्लो या अन्य आर्टफ़ैक्ट में हुए बदलावों की पहचान करने के लिए उपलब्ध कराया गया है. इन बदलावों की वजह से, अपग्रेड के दौरान रुकावट आ सकती है.

Java कॉलआउट की नीति में बदलाव

Edge for Private Cloud 4.54.00 में, मुख्य प्लैटफ़ॉर्म कॉम्पोनेंट को Java 21 LTS पर चलाने के लिए अपडेट किया गया है. इनमें मैसेज प्रोसेसर, मैनेजमेंट सर्वर, और राऊटर शामिल हैं. Java 21, Java प्लैटफ़ॉर्म को आधुनिक बनाता है. इसमें लेगसी Java EE और CORBA मॉड्यूल (जेईपी 320) को हटाना, लेगसी इंटरनल यूटिलिटी क्लास को हटाना, और मज़बूत मॉड्यूलर एनकैप्सुलेशन (जेईपी 403) को लागू करना शामिल है.

इन बदलावों की वजह से, कस्टम JavaCallout नीतियों या कस्टम रिसोर्स JAR (प्रॉक्सी, एनवायरमेंट या संगठन के लेवल पर सेव किए गए) वाले एपीआई प्रॉक्सी को 4.54.00 वर्शन पर अपग्रेड करने पर, रुकावट आ सकती है.

बदलाव की ऐसी कैटगरी जिनसे Java कॉलआउट पर असर पड़ सकता है

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 में डीओएम को पार्स करने के कुछ खास तरीके और एक्सएमएल को पार्स करने वाली क्लास.

   टूल का पता लगाना: बदलाव का पता लगाने वाला टूल, METHOD_SIGNATURE_MODIFICATION कैटगरी में इन क्लास के रेफ़रंस को MEDIUM असर की संभावना के साथ फ़्लैग करता है. इससे डेवलपर को, कॉलआउट के सोर्स कोड की जांच करने के लिए कहा जाता है, ताकि वे बदले गए तरीके के इनवोकेशन का पता लगा सकें.

समस्या को हल करने की रणनीतियां

अपग्रेड करने से पहले, पक्का करें कि आपकी Java कॉलआउट नीतियां और कस्टम JAR संसाधन, Java 21 रनटाइम के साथ काम करते हों. बदलाव का पता लगाने वाले टूल का इस्तेमाल करके, अपने क्लस्टर में मौजूद उन एपीआई प्रॉक्सी, शेयर किए गए फ़्लो, और एनवायरमेंट या संगठन के JAR संसाधनों की पहचान की जा सकती है जिन पर असर पड़ा है.

इस सेक्शन में बताई गई रणनीतियां, सामान्य दिशा-निर्देश हैं और ये म्युचुअली एक्सक्लूसिव नहीं हैं. अपने काम की ज़रूरतों के हिसाब से, रणनीतियों को जोड़ा जा सकता है. उदाहरण के लिए, मैसेज प्रोसेसर के अपग्रेड के दौरान डाउनटाइम को शून्य करने के लिए, रणनीति 2 का इस्तेमाल करके कॉलआउट सोर्स कोड को आधुनिक बनाना और रणनीति 3B का इस्तेमाल करके अपडेट किए गए प्रॉक्सी रिविज़न को डिप्लॉय करना.

रणनीति 3A, 3B, और 3C, एक ही ऑपरेशनल तरीके को लागू करने के तीन तरीके हैं: प्रॉक्सी बंडल में बदलाव किए बिना, नोड को अपग्रेड करना और प्रॉक्सी को अलग-अलग समय पर फिर से डिप्लॉय करना. एपीआई की उपलब्धता से जुड़ी अपनी ज़रूरतों के हिसाब से, इनमें से कोई एक या एक से ज़्यादा विकल्प चुनें.

डिप्लॉयमेंट के लिए सबसे सही तरीका चुनने के लिए, यहां दी गई गाइड देखें:

Java कॉलआउट से जुड़ी समस्याओं को कम करने के लिए गाइड:

पहली रणनीति: बंडल किए गए JAR के ज़रिए, दो वर्शन के साथ काम करने वाली प्रॉक्सी (अपग्रेड से पहले टेस्ट करें, ताकि कोई रुकावट न आए)

इसका इस्तेमाल कब करें: इस रणनीति का इस्तेमाल तब करें, जब:

• दोनों के साथ काम करने वाली स्टैंडअलोन रिप्लेसमेंट लाइब्रेरी उपलब्ध है: एक रिप्लेसमेंट JAR मौजूद है, जो ज़रूरी फ़ंक्शन लागू करता है. इसे सोर्स कोड में बदलाव किए बिना, सीधे तौर पर अपनी एपीआई प्रॉक्सी में बंडल किया जा सकता है.
• आपको अपने मौजूदा एपीआई प्रॉक्सी और Java कॉलआउट को अपने मौजूदा वर्शन (उदाहरण के लिए, Edge for Private Cloud 4.53.01) और अपग्रेड किए गए वर्शन (Edge for Private Cloud 4.54.00), दोनों पर आसानी से इस्तेमाल करना है.
• आपको Edge for Private Cloud क्लस्टर को अपग्रेड करने से पहले, अपने स्टेजिंग और प्रोडक्शन एनवायरमेंट में सभी बदलावों की जांच करनी है और उनकी पुष्टि करनी है. इससे यह पक्का किया जा सकेगा कि लाइव ट्रैफ़िक में कोई अनचाही समस्या न हो और कोई डाउनटाइम न हो.
• आपको Java कॉलआउट के कारोबारी नियम को फिर से लिखने या रीफ़ैक्टर करने से बचना है.

यह कैसे काम करता है: Java 8 में, कुछ लाइब्रेरी (जैसे कि JAXB javax.xml.bind.* या Activation javax.activation.*) को सीधे तौर पर Java 8 रनटाइम में बनाया गया था. इस वजह से, डेवलपर को अपने प्रॉक्सी बंडलों में अतिरिक्त JAR फ़ाइलें शामिल करने की ज़रूरत नहीं पड़ी. Java 21 में, इन लाइब्रेरी को Java रनटाइम से हटा दिया गया था.

Edge for Private Cloud 4.53.x और 4.54.00, दोनों के साथ काम करने वाली प्रॉक्सी बनाने के लिए:

1. अपने कॉलआउट के लिए ज़रूरी लाइब्रेरी की पहचान करें. उदाहरण के लिए, JAXB या Activation.
2. अलग से उपलब्ध ओपन-सोर्स रिप्लेसमेंट JAR (उदाहरण के लिए, jakarta.xml.bind-api-2.3.3.jar और jaxb-runtime-2.3.8.jar) पाएं.
3. रिप्लेसमेंट JAR को सीधे apiproxy/resources/java/ में मौजूद प्रॉक्सी बंडल में डालें या प्रॉक्सी-लेवल की रिसॉर्स फ़ाइलें एपीआई का इस्तेमाल करके, इसे प्रॉक्सी रिविज़न में अपलोड करें. इसके अलावा, इसे एनवायरमेंट लेवल या संगठन लेवल पर रिसॉर्स फ़ाइल के तौर पर अपलोड करें. संसाधन फ़ाइलों को मैनेज करने के बारे में ज़्यादा जानने के लिए, Apigee संसाधन फ़ाइलों का दस्तावेज़ देखें.
4. अपग्रेड करने से पहले डिप्लॉय और टेस्ट करना: Edge for Private Cloud 4.53.x और 4.54.00, दोनों में मौजूद मैसेज प्रोसेसर, इन बंडल किए गए JAR से क्लास लोड करते हैं. इस अपडेट किए गए प्रॉक्सी बंडल को डिप्लॉय किया जा सकता है. साथ ही, इसे अपने मौजूदा Edge for Private Cloud 4.53.x क्लस्टर में सिंथेटिक ट्रैफ़िक के साथ टेस्ट किया जा सकता है.
5. मैसेज प्रोसेसर पर, बाहरी पैकेज लोड करने की अनुमति दें (4.54.00 के लिए ज़रूरी है): Edge for Private Cloud 4.54.00 में, बाहरी या बंडल किए गए संसाधन JAR से हटाए गए Java पैकेज (जैसे, javax.xml.bind.* और javax.activation.*) लोड करने की सुविधा डिफ़ॉल्ट रूप से बंद (conf_system_java.21.enable.external.allowed.packages=false) होती है. इसलिए, सिर्फ़ JAR को बंडल करने से डिफ़ॉल्ट रूप से काम नहीं चलेगा. आपको कॉन्फ़िगरेशन के साथ कोड (सीडब्ल्यूसी) का इस्तेमाल करके, /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) के बंडल की गई रिसॉर्स फ़ाइल से क्लास लोड करता है. इससे, बिना किसी डाउनटाइम के आसानी से अपग्रेड किया जा सकता है.

कोड का उदाहरण: ऑर्डर के एक्सएमएल की पुष्टि और पार्सिंग कॉलआउट

Apigee Java Callout का एक सामान्य उदाहरण देखें. यह JAXB (JAXBContext और Unmarshaller) का इस्तेमाल करके, आने वाले एक्सएमएल ऑर्डर को निकालता है और उनकी पुष्टि करता है.

• समस्या ठीक होने से पहले (Edge for Private Cloud 4.54.00 में काम नहीं करता): Edge for Private Cloud 4.53.x में, प्रॉक्सी बंडल में सिर्फ़ कॉलआउट 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)

• समस्या ठीक होने के बाद (Edge for Private Cloud 4.53.x और 4.54.00, दोनों के साथ काम करता है): आपको Java कॉलआउट कोड को फिर से लिखने या फिर से कंपाइल करने की ज़रूरत नहीं है. स्टैंडअलोन 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

     इसके अलावा, jakarta.xml.bind-api-2.3.3.jar और jaxb-runtime-2.3.8.jar को प्रॉक्सी-लेवल के Resource Files API का इस्तेमाल करके, रिसॉर्स फ़ाइलों के तौर पर अपलोड करें. इसके अलावा, इन्हें एनवायरमेंट लेवल या संगठन के लेवल पर भी अपलोड किया जा सकता है. इससे एक ही स्कोप में मौजूद सभी प्रॉक्सी, इन फ़ाइलों को शेयर कर सकती हैं. इसके लिए, उन्हें हर प्रॉक्सी बंडल में शामिल करने की ज़रूरत नहीं होगी.

     अगर Maven का इस्तेमाल करके, सोर्स से प्रॉक्सी बंडल बनाया जाता है, तो इन डिपेंडेंसी को अपने pom.xml में शामिल करें. इससे, बिल्ड के दौरान ये अपने-आप पैकेज हो जाएंगी.

  2. अपने मौजूदा 4.53.x क्लस्टर पर डिप्लॉय और टेस्ट करें: अपडेट किए गए प्रॉक्सी बंडल को अपने मौजूदा Edge for Private Cloud 4.53.x एनवायरमेंट में डिप्लॉय करें और टेस्ट कॉल भेजें. Edge for Private Cloud 4.53.x के मैसेज प्रोसेसर, इन बंडल किए गए JAR से क्लास लोड करते हैं. इसलिए, यह पुष्टि की जा सकती है कि कॉलआउट पहले की तरह काम कर रहा है.
  3. CwC के ज़रिए, अनुमति वाले बाहरी पैकेज लोड करने की सुविधा चालू करें: Edge for Private Cloud 4.54.00 (conf_system_java.21.enable.external.allowed.packages=false) में, अनुमति वाले बाहरी पैकेज लोड करने की सुविधा डिफ़ॉल्ट रूप से बंद होती है. इसलिए, /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 एपीआई या ओपन-सोर्स स्टैंडअलोन क्लास से बदलें. साथ ही, तीसरे पक्ष की ज़रूरी डिपेंडेंसी को सीधे अपने प्रॉक्सी बंडल की रिसॉर्स फ़ाइलों या POM में पैकेज करें.

कोड के उदाहरण:

पहला उदाहरण: तरीके और कोड को आधुनिक बनाना (हटाए गए इंटरनल यूटिलिटी को बदलना)

Java 8 में, कॉलआउट अक्सर sun.misc.BASE64Encoder जैसी इंटरनल यूटिलिटी क्लास का इस्तेमाल करते थे. मॉडर्न Java में, इन क्लास को हटा दिया गया था. हालांकि, स्टैंडर्ड java.util.Base64 एपीआई, बाहरी डिपेंडेंसी 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 में, एक्सएमएल नेमस्पेस प्रीफ़िक्स को पसंद के मुताबिक बनाने वाली एपीआई प्रॉक्सी, आम तौर पर 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): रनटाइम के दौरान इस क्लास को उपलब्ध कराने के लिए, स्टैंडअलोन JAXB लाइब्रेरी को apiproxy/resources/java/ में बंडल करें या उन्हें अपने 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>

रणनीति 3A: तय समय पर रखरखाव के लिए बंद होने की अवधि (मौजूदा जगह पर फिर से डिप्लॉय करना)

कब इस्तेमाल करें: इसका इस्तेमाल ऐसे एनवायरमेंट के लिए करें जहां रखरखाव के लिए शेड्यूल की गई विंडो मौजूद हों और सेवा में कुछ समय के लिए रुकावट आने से कोई समस्या न हो.

तरीका:

1. एपीआई का इस्तेमाल करने वाले लोगों के साथ मिलकर, शेड्यूल किए गए रखरखाव की विंडो तय करें.
2. अपग्रेड पाथ गाइड में दिए गए निर्देशों का पालन करके, Edge for Private Cloud के कॉम्पोनेंट को 4.54.00 वर्शन पर अपग्रेड करें.
3. New Edge यूज़र इंटरफ़ेस (यूआई) या Apigee Management API (डिप्लॉयमेंट) का इस्तेमाल करके, अपने एपीआई प्रॉक्सी के पहले से कंपाइल किए गए और 4.54.00 के साथ काम करने वाले वर्शन को डिप्लॉय करें.
4. मैसेज प्रोसेसर को सिंथेटिक टेस्ट के अनुरोध भेजकर, कॉलआउट के काम करने की पुष्टि करें. साथ ही, ट्रेस टूल का इस्तेमाल करके लॉग की जांच करें.
5. मेंटेनेंस विंडो को बंद करें और सार्वजनिक ट्रैफ़िक को फिर से चालू करें.

रणनीति 3B: नया एनवायरमेंट बनाना (बिना किसी रुकावट के माइग्रेट करना)

इसका इस्तेमाल कब करना चाहिए: यह उन प्रोडक्शन एनवायरमेंट के लिए सुझाव दिया जाता है जहां मिशन-क्रिटिकल ऐप्लिकेशन को बिना किसी रुकावट के चलाना ज़रूरी होता है. इसका इस्तेमाल तब करें, जब Java Callout को Java 8 और Java 21, दोनों पर एक साथ काम करने के लिए अपडेट न किया जा सके.

यह कैसे काम करता है: इस रणनीति में, एक या उससे ज़्यादा नए एनवायरमेंट को हासिल किया जाता है, ताकि आप अलग-अलग वर्शन के मैसेज प्रोसेसर नोड को इससे कनेक्ट कर सकें. इसके बाद, Java 8 के साथ काम करने वाले प्रॉक्सी को 4.53.X मैसेज प्रोसेसर से जुड़े एनवायरमेंट में डिप्लॉय करें. साथ ही, Java 21 के साथ काम करने वाले प्रॉक्सी को 4.54.00 मैसेज प्रोसेसर से जुड़े एनवायरमेंट में डिप्लॉय करें. इसके बाद, लोड बैलेंसर या रूटिंग की अन्य तकनीकों का इस्तेमाल करके, ट्रैफ़िक को सिर्फ़ Java 21 के साथ काम करने वाले प्रॉक्सी पर रूट करें.

इस रणनीति के लिए, यह समझना ज़रूरी है कि संगठन, एनवायरमेंट, और मैसेज प्रोसेसर कैसे इंटरैक्ट करते हैं. इससे ज़ीरो-डाउनटाइम कट-ओवर किया जा सकता है. ज़्यादा जानकारी के लिए, Apigee Edge के संगठन का स्ट्रक्चर देखें:

• Apigee संगठन, टॉप-लेवल एडमिनिस्ट्रेटिव बाउंड्री है. इसमें कई एनवायरमेंट होते हैं. उदाहरण के लिए, prod, test.
• एपीआई प्रॉक्सी के किसी बदलाव को किसी खास एनवायरमेंट में डिप्लॉय किया जाता है. सिर्फ़ उस एनवायरमेंट से साफ़ तौर पर जुड़े मैसेज प्रोसेसर, प्रॉक्सी में किए गए बदलाव को लोड और लागू करते हैं.

+------------------------------------------------------------------------+
|                          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 मैसेज प्रोसेसर नोड को प्रोविज़न करना: नए या कुछ समय के लिए बनाए गए वीएम इंस्टेंस पर, Edge for Private Cloud 4.54.00 इंस्टॉल करें. साथ ही, इन नोड को prod-migration से बाइंड करें (मैसेज प्रोसेसर जोड़ना देखें).
3. जिन प्रॉक्सी पर असर पड़ा है उनकी पहचान करें और अपडेट किए गए वर्शन बनाएं: Java कॉलआउट का इस्तेमाल करने वाले एपीआई प्रॉक्सी की पहचान करें. इसके लिए, बदलाव का पता लगाने वाले टूल का इस्तेमाल करें. इसके बाद, जिन प्रॉक्सी पर असर पड़ा है उनके लिए, Edge for Private Cloud 4.54.00 के साथ काम करने वाले Java कॉलआउट का इस्तेमाल करके, एक नया वर्शन बनाएं. इसके लिए, रणनीति 1 या रणनीति 2 लागू करें.
4. अस्थायी एनवायरमेंट में, प्रॉक्सी के अपडेट किए गए वर्शन डिप्लॉय करना: अपडेट किए गए और काम करने वाले प्रॉक्सी के वर्शन सिर्फ़ prod-migration में डिप्लॉय करें.
5. पुष्टि करना और ट्रैफ़िक को ट्रांसफ़र करना: नए वर्चुअल होस्ट के ख़िलाफ़ सिंथेटिक पुष्टि करने वाले टेस्ट चलाएं. पुष्टि होने के बाद, अपने बाहरी लोड बैलेंसर (F5, NGINX) को कॉन्फ़िगर करें, ताकि क्लाइंट ट्रैफ़िक को prod से prod-migration पर रीडायरेक्ट किया जा सके.
6. ओरिजनल नोड अपग्रेड करना और वापस स्विच करना: prod से लेगसी प्रॉक्सी को अनडिप्लॉय करें. अपग्रेड पाथ गाइड में दिए गए निर्देशों का पालन करके, ओरिजनल मैसेज प्रोसेसर नोड को 4.54.00 पर अपग्रेड करें. मॉडर्नाइज़ किए गए प्रॉक्सी वर्शन को prod पर डिप्लॉय करें, लोड बैलेंसर के ट्रैफ़िक को वापस prod पर रीडायरेक्ट करें, और ऑपरेशन की पुष्टि करें.
7. कुछ समय के लिए बनाए गए एनवायरमेंट को बंद करना: prod-migration से प्रॉक्सी को अनडिप्लॉय करें, कुछ समय के लिए बनाए गए मैसेज प्रोसेसर नोड हटाएं, और कुछ समय के लिए बनाए गए एनवायरमेंट को मिटाएं.

रणनीति 3C: नोड-लेवल पर बाहरी लाइब्रेरी को प्लेस करना (फ़ॉलबैक के तौर पर इस्तेमाल की जाने वाली शेयर की गई लाइब्रेरी)

इसका इस्तेमाल कब करें: इसका सुझाव तब दिया जाता है, जब आपके पास Java क्लास पर निर्भर कई एपीआई प्रॉक्सी हों. ये क्लास, Java 21 में हटा दी गई थीं. साथ ही, अपग्रेड करने से पहले हर प्रॉक्सी बंडल को फिर से कंपाइल या फिर से पैकेज करना, ऑपरेशन के हिसाब से मुमकिन नहीं है.

यह कैसे काम करता है: Edge for Private Cloud 4.54.00 में, मैसेज प्रोसेसर एक ऐसा तरीका उपलब्ध कराते हैं जिससे मौजूद नहीं होने वाली Java क्लास को, खास तौर पर बनाई गई नोड डायरेक्ट्री: $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. मैसेज प्रोसेसर के कॉन्फ़िगरेशन में, बाहरी पैकेज लोड करने की सुविधा चालू करना: Edge for Private Cloud 4.54.00 में, अनुमति वाले बाहरी पैकेज लोड करने की सुविधा डिफ़ॉल्ट रूप से बंद (conf_system_java.21.enable.external.allowed.packages=false) होती है. मैसेज प्रोसेसर को /opt/apigee/data/edge-message-processor/external-lib से क्लास रिज़ॉल्व और लोड करने की अनुमति देने के लिए, आपको कोड विद कॉन्फ़िगरेशन (सीडब्ल्यूसी) का इस्तेमाल करके, /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

चौथी रणनीति: जेवीएम फ़्लैग (--add-opens / --add-exports — सावधानी और आखिरी विकल्प)

इसका इस्तेमाल कब करें: इस रणनीति का इस्तेमाल, तीसरे पक्ष की क्लोज़्ड सोर्स वेंडर लाइब्रेरी के लिए आखिरी विकल्प के तौर पर करें. ऐसा तब करें, जब सोर्स कोड उपलब्ध न हो, वेंडर ने Java 21 के अपडेट रिलीज़ न किए हों, और JAR पूरी तरह से Java के इंटरनल पैकेज के रिफ़्लेक्टिव ऐक्सेस पर निर्भर हो.

तरीका:

1. रिफ़्लेक्शन के लिए इस्तेमाल किए गए ऐसे पैकेज की पहचान करें जिसे ऐक्सेस नहीं किया जा सकता: यह पता लगाएं कि तीसरे पक्ष की लाइब्रेरी ने किस इंटरनल Java मॉड्यूल और पैकेज को रिफ़्लेक्टिव तरीके से ऐक्सेस किया है. ध्यान दें: रिफ़्लेक्शन से जुड़ी ये गड़बड़ियां, Edge for Private Cloud 4.54.00 में Java 21 के तहत ही होती हैं. ये गड़बड़ियां, 4.53.x वर्शन के लॉग में नहीं दिखेंगी. अपग्रेड करने के बाद, मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/system.log) में InaccessibleObjectException देखें, ताकि ज़रूरी मॉड्यूल और पैकेज की पहचान की जा सके:

   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. टारगेट किए गए --add-opens या --add-exports फ़्लैग को bin_setenv_ext_jvm_opts में जोड़ें.

   # 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 का इस्तेमाल करके, Message Processor को रीस्टार्ट करें:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

टीएलएस और साइफ़र सुइट में बदलाव

Edge for Private Cloud 4.54.00 में, प्लैटफ़ॉर्म के मुख्य कॉम्पोनेंट को अपडेट किया गया है. इनमें मैसेज प्रोसेसर, मैनेजमेंट सर्वर, और राउटर शामिल हैं. ये अब Java 21 LTS पर काम करेंगे. इस अपडेट से, क्रिप्टोग्राफ़िक सुरक्षा को आधुनिक बनाया गया है. इसके लिए, TLS 1.3 को डिफ़ॉल्ट रूप से (जेईपी 332) चालू किया गया है. मैसेज प्रोसेसर अब आउटबाउंड बैकएंड कनेक्शन के लिए, टीएलएस 1.3 को पसंदीदा प्रोटोकॉल के तौर पर इस्तेमाल करते हैं. अगर बैकएंड इसे सपोर्ट नहीं करता है, तो टीएलएस 1.2 का इस्तेमाल किया जाता है.

लेगसी बैकएंड से जुड़ी ज़रूरी शर्तें और समस्या हल करने का तरीका

Java 21 क्रिप्टोग्राफ़िक बेसलाइन, jdk.tls.disabledAlgorithms में डिफ़ॉल्ट रूप से बंद किए गए प्रोटोकॉल और साइफ़र सुइट की सूची को अपडेट करती है. जैसे, लेगसी टीएलएस प्रोटोकॉल और नॉन-फ़ॉरवर्ड-सीक्रेट स्टैटिक आरएसए की-एक्सचेंज सुइट: TLS_RSA_*. Java 21 रनटाइम की सुविधा खुद उपलब्ध कराने की वजह से, बंद किए गए प्रोटोकॉल और साइफ़र सुइट की सटीक सूची, Java 21 के आपके खास तरीके के इस्तेमाल पर निर्भर करती है.

अगर आपकी मौजूदा एपीआई प्रॉक्सी, लेगसी बैकएंड इन्फ़्रास्ट्रक्चर से कनेक्ट होती हैं और इसके लिए बंद किए गए प्रोटोकॉल या स्टैटिक आरएसए सिफ़र की ज़रूरत होती है, तो ये कार्रवाइयां करें:

• बैकएंड सुरक्षा को आधुनिक बनाएं (सुझाया गया): टारगेट सर्वर और लोड बैलेंसर को अपग्रेड करें, ताकि वे आधुनिक ईसीडीएचई साइफ़र सुइट के साथ टीएलएस 1.2 या टीएलएस 1.3 का इस्तेमाल कर सकें. अपने एपीआई प्रॉक्सी में प्रोटोकॉल और साइफ़र सुइट कॉन्फ़िगर करने के लिए, Edge से बैकएंड तक टीएलएस कॉन्फ़िगर करना और टीएलएस/एसएसएल 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 का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. बैकएंड में ईसीडीएचई साइफ़र सुइट की सुविधा चालू होने के बाद, इस बदलाव को हटाएं.
• कस्टम सिफ़र सुइट की अनुमति वाली सूची अपडेट करना: अगर आपने पहले conf_http_HTTPTransport.ssl.cipher.suites.whitelist को बदल दिया था, तो अपग्रेड करने से पहले इसकी समीक्षा करें. Java 21 में अब स्टैटिक आरएसए सुइट (TLS_RSA_*) काम नहीं करते. इसलिए, अनुमति वाली ऐसी सूची जिसमें सिर्फ़ ये सुइट शामिल हैं, मैसेज प्रोसेसर को इस्तेमाल करने लायक साइफ़र नहीं देती. साथ ही, बैकएंड कॉल no cipher suites in common के साथ काम नहीं करते. TLS_RSA_* एंट्री हटाएं और Java 21 के साथ काम करने वाली आधुनिक सिफ़र सुइट कॉन्फ़िगर करें. अगर आपने इस प्रॉपर्टी को बदला नहीं है, तो 4.54.00 के डिफ़ॉल्ट वर्शन में, काम करने वाले सुइट पहले से मौजूद होते हैं. इसलिए, आपको कोई बदलाव करने की ज़रूरत नहीं है.
• मैसेज प्रोसेसर के साइफ़र के लिए, इंटरनल राऊटर को अपडेट करें: अगर आपने पहले स्टैटिक आरएसए सुइट की मदद से conf_message-processor-communication_local.http.ssl.ciphers को बदला था, तो अपग्रेड करने से पहले इसे Java 21 के साथ काम करने वाले आधुनिक साइफ़र सुइट से अपडेट करें. ऐसा न करने पर, राऊटर, मैसेज प्रोसेसर के साथ टीएलएस हैंडशेक पूरा नहीं कर पाएगा. इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें:

  apigee-service edge-message-processor restart

  राऊटर और मैसेज प्रोसेसर के बीच टीएलएस कॉन्फ़िगर करना देखें.

Edge के कॉम्पोनेंट के बीच टीएलएस कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए, राऊटर और मैसेज प्रोसेसर के बीच टीएलएस कॉन्फ़िगर करना लेख पढ़ें.

बदलाव का पता लगाने वाला टूल

Apigee, बदलाव का पता लगाने वाला एक टूल उपलब्ध कराता है. इससे आपके क्लस्टर को स्कैन करके, डिप्लॉय किए गए एपीआई प्रॉक्सी, नीतियों, शेयर किए गए फ़्लो, और रिसोर्स JAR का पता लगाया जाता है. इन पर Edge for Private Cloud 4.54.00 पर अपग्रेड करने का असर पड़ सकता है.

यह टूल, अपग्रेड करने में आने वाली संभावित समस्याओं की पहचान करता है. इनमें Java 21 के साथ काम न करने वाली लाइब्रेरी, पूरी तरह से इनकैप्सुलेट किए गए इंटरनल एपीआई, लेगसी नीति के बंद होने की सूचनाएं, और OpenLDAP RDN की सीमाएं शामिल हैं. साथ ही, यह कार्रवाई की जा सकने वाली रिपोर्ट जनरेट करता है, ताकि आपको समस्याओं को ठीक करने के लिए सही रणनीतियां चुनने में मदद मिल सके.

ज़रूरी शर्तों, डाउनलोड करने के निर्देशों, कमांड-लाइन सिंटैक्स, और सैंपल रिपोर्ट की पूरी जानकारी के लिए, बदलाव की पहचान करने वाले टूल की गाइड देखें.