การเปลี่ยนแปลงใน Edge for Private Cloud 4.54.00

ภาพรวมของการเปลี่ยนแปลง

Edge for Private Cloud 4.54.00 มีการเปลี่ยนแปลงหลายอย่างที่ช่วยเพิ่มระดับการรักษาความปลอดภัยของแพลตฟอร์ม และอัปเดตคอมโพเนนต์ของแพลตฟอร์มให้ทำงานร่วมกับ Java 21 การเปลี่ยนแปลงเหล่านี้จะอธิบายไว้ใน 2 ส่วนด้านล่างนี้

นอกจากการเปลี่ยนแปลงเหล่านี้แล้ว โปรดอ่านคู่มือเครื่องมือตรวจจับการเปลี่ยนแปลงโดยเฉพาะ ยูทิลิตีนี้มีไว้เพื่อระบุการเปลี่ยนแปลงพร็อกซี, โฟลว์ที่ใช้ร่วมกัน หรืออาร์ติแฟกต์อื่นๆ ในคลัสเตอร์ที่อาจทำให้เกิดการหยุดชะงักอันเป็นผลมาจากการอัปเกรดนี้

Edge for Private Cloud 4.54.00 ไม่รองรับความสามารถ 3 อย่างที่มีในเวอร์ชัน 4.53.01 ก่อนวางแผนการอัปเกรด โปรดดูฟีเจอร์ที่ไม่รองรับใน 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) แบบแยกจากระบบหลัก Edge for Private Cloud 4.54.00 ไม่ได้รับการรับรองสำหรับสภาพแวดล้อม GDC ที่ไม่มีการเชื่อมต่ออินเทอร์เน็ต สำหรับขั้นตอนของเวอร์ชัน 4.53.01 โปรดดูหัวข้อติดตั้ง Apigee ใน Google Distributed Cloud แบบ Air-Gapped
  • RHEL 8.X หรือ Rocky 8.X ที่เปิดใช้ FIPS Edge for Private Cloud 4.54.00 ไม่รองรับการติดตั้งบนโฮสต์ RHEL 8.X หรือ Rocky 8.X ที่เปิดใช้ FIPS ระบบปฏิบัติการเหล่านี้จะได้รับการรองรับเมื่อไม่ได้เปิดใช้โหมด FIPS หัวข้อการกำหนดค่าเวอร์ชัน 4.54.00 ยังละเว้นคำแนะนำเฉพาะ FIPS ที่เวอร์ชัน 4.53.01 มีให้ ซึ่งรวมถึงการเตรียมคีย์สโตร์ BCFKS, พร็อพเพอร์ตี้การกำหนดค่าแบบไม่โต้ตอบ FIPS_OS และการกำหนดค่าคีย์สโตร์ PKCS12 ดูคำแนะนำสำหรับเวอร์ชัน 4.53.01 ได้ที่ Edge for Private Cloud ใน RHEL 8.X หรือ Rocky 8.X ที่เปิดใช้ FIPS
  • การผสานรวมโมดูลความปลอดภัยฮาร์ดแวร์ (HSM) ขาออก Edge for Private Cloud 4.54.00 ไม่รองรับการเชื่อมต่อ TLS ขาออกจาก Message Processor ไปยังบริการเป้าหมายแบ็กเอนด์ที่ใช้ HSM เครือข่าย Entrust nShield ดูขั้นตอนสำหรับเวอร์ชัน 4.53.01 ได้ที่คู่มือการผสานรวมโมดูลความปลอดภัยของฮาร์ดแวร์ Southbound สำหรับ Apigee Edge สำหรับ Private Cloud

การเปลี่ยนแปลงนโยบายไฮไลต์ของ Java

ใน Edge for Private Cloud 4.54.00 คอมโพเนนต์แพลตฟอร์มหลัก ซึ่งรวมถึง Message Processor, Management Server และเราเตอร์ ได้รับการอัปเดตให้ทำงานบน Java 21 LTS Java 21 ปรับปรุงแพลตฟอร์ม Java ให้ทันสมัย ซึ่งรวมถึงการนำโมดูล Java EE และ CORBA เดิมออก (JEP 320) การนำคลาสยูทิลิตีภายในเดิมออก และการบังคับใช้การแคปซูลแบบโมดูลที่เข้มงวด (JEP 403)

การเปลี่ยนแปลงเหล่านี้อาจทำให้พร็อกซี API ที่มีนโยบาย JavaCallout ที่กำหนดเองหรือ JAR ของทรัพยากรที่กำหนดเอง (จัดเก็บไว้ที่ระดับพร็อกซี สภาพแวดล้อม หรือองค์กร) อาจหยุดชะงักเมื่ออัปเกรดเป็นเวอร์ชัน 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 แต่มีการนำคอนสตรักเตอร์หรือซิกเนเจอร์ของเมธอดบางรายการออก เลิกใช้งาน หรือเปลี่ยนแปลง (เช่น เมธอดการแยกวิเคราะห์ DOM บางรายการใน org.w3c.dom.Document และคลาสการแยกวิเคราะห์ XML ที่เกี่ยวข้อง)

    การตรวจจับเครื่องมือ: เครื่องมือตรวจจับการเปลี่ยนแปลงจะแจ้งว่ามีการอ้างอิงถึงคลาสเหล่านี้ในหมวดหมู่ METHOD_SIGNATURE_MODIFICATION โดยมีMEDIUMความแน่นอนของผลกระทบ ซึ่งจะแจ้งให้นักพัฒนาซอฟต์แวร์ตรวจสอบซอร์สโค้ดของข้อความไฮไลต์เพื่อดูการเรียกใช้เมธอดที่แก้ไขแล้ว

กลยุทธ์การแก้ไข

ก่อนอัปเกรด โปรดตรวจสอบว่านโยบาย Java Callout และทรัพยากร JAR ที่กำหนดเองเข้ากันได้กับรันไทม์ Java 21 การใช้เครื่องมือตรวจจับการเปลี่ยนแปลงจะช่วยให้คุณระบุพร็อกซี API, โฟลว์ที่แชร์ และทรัพยากร JAR ของสภาพแวดล้อมหรือองค์กรที่ได้รับผลกระทบทั่วทั้งคลัสเตอร์ได้

กลยุทธ์การแก้ไขที่อธิบายไว้ในส่วนนี้เป็นคำแนะนำทั่วไปและสามารถใช้ร่วมกันได้ คุณสามารถรวมกลยุทธ์ต่างๆ เข้าด้วยกันได้ตามข้อกำหนดในการดำเนินงาน เช่น การปรับปรุงซอร์สโค้ดของคำขอไฮไลต์ให้ทันสมัยโดยใช้กลยุทธ์ที่ 2 และการติดตั้งใช้งานการแก้ไขพร็อกซีที่อัปเดตแล้วโดยใช้กลยุทธ์ที่ 3B เพื่อให้ระบบทำงานได้ตลอดเวลาในระหว่างการอัปเกรด Message Processor

กลยุทธ์ 3A, 3B และ 3C เป็น 3 วิธีในการดำเนินการตามแนวทางการดำเนินงานเดียวกัน นั่นคือการอัปเกรดโหนดและทำให้พร็อกซีใช้งานได้อีกครั้งในเวลาที่ต่างกัน โดยไม่ต้องเปลี่ยนแพ็กเกจพร็อกซี เลือกอย่างใดอย่างหนึ่งหรือหลายอย่างรวมกันตามข้อกำหนดด้านความพร้อมใช้งานของ API

ดูคู่มือการตัดสินใจต่อไปนี้เพื่อเลือกแนวทางที่เหมาะสมที่สุดสำหรับการติดตั้งใช้งาน

คู่มือการตัดสินใจสำหรับการลดความเสี่ยงของไฮไลต์ Java

ต้องอัปเดตแพ็กเกจพร็อกซีและทำให้ใช้งานได้อีกครั้งไหม สถานการณ์หรือข้อกำหนด กลยุทธ์ที่แนะนํา ปัญหาที่แก้ไข ข้อจำกัดที่สำคัญ
ใช่ (อัปเดตแพ็กเกจเท่านั้น) มีไลบรารีที่เข้ากันได้ทั้ง 2 แบบ และต้องการให้ระบบทำงานได้ตลอดเวลา กลยุทธ์ที่ 1: พร็อกซีที่เข้ากันได้แบบคู่ผ่าน JAR ที่รวมกลุ่ม กู้คืนไลบรารีที่หายไปในเวอร์ชันต่างๆ โดยไม่มีช่วงเวลาที่ระบบหยุดทำงาน ต้องมีคลังสแตนด์อโลนที่เข้ากันได้ทั้ง 2 แบบและเปิดใช้ conf_system_java.21.enable.external.allowed.packages=true ในเวอร์ชัน 4.54.00
ใช่ (การแก้ไขซอร์สโค้ด) ซอร์สโค้ดได้รับการดูแลรักษา ต้องการการแก้ไขระยะยาวที่สมบูรณ์ กลยุทธ์ที่ 2: การติดตั้งใช้งานทางเลือก (การปรับโค้ดและการขึ้นต่อกันให้ทันสมัย) แก้ไขคลาสที่ถูกนำออกและการขึ้นต่อกันของ API ภายในอย่างถาวร ต้องมีการเปลี่ยนแปลงซอร์สโค้ดและการทำให้ใช้งานได้อีกครั้ง (จับคู่กับกลยุทธ์ 3A หรือ 3B สำหรับการเปิดตัว)
ไม่ (แนวทางด้านการดำเนินงาน) ช่วงเวลาบำรุงรักษาตามกำหนดการที่อนุญาต กลยุทธ์ 3A: ช่วงเวลาที่ระบบหยุดทำงานเพื่อการบำรุงรักษาตามแผน (การติดตั้งใช้งานซ้ำในตำแหน่งเดิม) อนุญาตให้อัปเกรดโหนดก่อน แล้วจึงติดตั้งใช้งานพร็อกซีที่อัปเดตแล้ว ต้องมีการหยุดทำงานตามกำหนดเวลาสำหรับผู้ใช้ API
ไม่ (แนวทางด้านการดำเนินงาน) ต้องไม่มีช่วงพัก ไม่สามารถรวม JAR แบบคู่ได้ กลยุทธ์ 3B: สร้างสภาพแวดล้อมใหม่ (การย้ายข้อมูลโดยไม่มีช่วงเวลาที่ระบบหยุดทำงาน) แยกโหนด 4.53 และ 4.54 ระหว่างการย้ายข้อมูลโดยไม่รบกวนการเข้าชม ต้องจัดหาโหนด Message Processor ชั่วคราว
ไม่ (แนวทางด้านการดำเนินงาน) แก้ไขแพ็กเกจพร็อกซีก่อนอัปเกรดไม่ได้ * กลยุทธ์ 3C: การวางตำแหน่งไลบรารีภายนอกระดับโหนด จัดหา JAR ของไลบรารีที่ขาดหายไปทั่วทั้งโหนดโดยไม่ต้องแก้ไขแพ็กเกจพร็อกซี แชร์ในพร็อกซีทั้งหมดบนโหนด ไม่แก้ปัญหาแพ็กเกจการสะท้อนหรือ java.*
ไม่ (ไลบรารีของบุคคลที่สามแบบโคลสซอร์ส) ไลบรารีของผู้ให้บริการบุคคลที่สามที่ใช้การสะท้อนภายใน Java * กลยุทธ์ที่ 4: แฟล็ก JVM (--add-opens / --add-exports) ผ่อนคลายข้อจำกัดการสะท้อนสำหรับแพ็กเกจ Java ภายใน กู้คืนคลาสหรือเมธอดที่นำออกไม่ได้ มีผลทั่วทั้งโหนด

กลยุทธ์ที่ 1: พร็อกซีที่เข้ากันได้แบบคู่ผ่าน JAR ที่รวมมา (ทดสอบก่อนอัปเกรดเพื่อไม่ให้เกิดช่วงพักการทำงาน)

กรณีที่ควรใช้: ใช้กลยุทธ์นี้ในกรณีต่อไปนี้

  • มีไลบรารีทดแทนแบบสแตนด์อโลนที่เข้ากันได้ทั้ง 2 แบบ: มี JAR ทดแทนที่ใช้ฟังก์ชันการทำงานที่จำเป็นและสามารถรวมเข้ากับพร็อกซี API ของคุณได้โดยตรงโดยไม่ต้องแก้ไขซอร์สโค้ด
  • คุณต้องการให้พร็อกซี API และ Java Callout ที่มีอยู่ทำงานได้อย่างราบรื่นทั้งในเวอร์ชันปัจจุบัน (เช่น Edge for Private Cloud 4.53.01) และเวอร์ชันที่อัปเกรด (Edge for Private Cloud 4.54.00)
  • คุณควรทดสอบและยืนยันการเปลี่ยนแปลงทั้งหมดในสภาพแวดล้อมการทดลองใช้และสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ก่อนอัปเกรดคลัสเตอร์ Edge for Private Cloud เพื่อให้มั่นใจว่าจะไม่มีปัญหาที่ไม่คาดคิดและไม่มีช่วงเวลาที่ระบบหยุดทำงานในการเข้าชมแบบเรียลไทม์
  • คุณต้องการหลีกเลี่ยงการเขียนใหม่หรือเปลี่ยนโครงสร้างภายในโค้ดของตรรกะทางธุรกิจของ Java Callout

วิธีการทำงาน: ใน Java 8 ไลบรารีบางรายการ (เช่น JAXB javax.xml.bind.* หรือ Activation javax.activation.*) จะสร้างขึ้นในรันไทม์ของ Java 8 โดยตรง ด้วยเหตุนี้ นักพัฒนาแอปจึงไม่จำเป็นต้องรวมไฟล์ JAR เพิ่มเติมไว้ในแพ็กเกจพร็อกซี ใน Java 21 ระบบได้นำไลบรารีเหล่านี้ออกจากรันไทม์ของ Java

วิธีทำให้พร็อกซี "เข้ากันได้แบบคู่" ใน Edge สำหรับ 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. วาง JAR ที่จะใช้แทนลงในแพ็กเกจพร็อกซีโดยตรงในส่วน apiproxy/resources/java/ หรืออัปโหลดไปยังการแก้ไขพร็อกซีโดยใช้ Resource Files API ระดับพร็อกซี หรืออัปโหลดเป็นไฟล์ทรัพยากรที่ระดับสภาพแวดล้อมหรือระดับองค์กร ดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดการไฟล์ทรัพยากรได้ที่เอกสารประกอบเกี่ยวกับไฟล์ทรัพยากรของ Apigee
  4. ติดตั้งใช้งานและทดสอบก่อนอัปเกรด: Message Processor ทั้งใน Edge for Private Cloud 4.53.x และ 4.54.00 จะโหลดคลาสจาก JAR ที่รวมมาเหล่านี้ คุณสามารถติดตั้งใช้งานแพ็กเกจพร็อกซีที่อัปเดตนี้และทดสอบกับการเข้าชมสังเคราะห์ในคลัสเตอร์ Edge for Private Cloud 4.53.x ปัจจุบันได้แล้วตอนนี้
  5. เปิดใช้การโหลดแพ็กเกจที่อนุญาตภายนอกใน Message Processor (จำเป็นสำหรับ 4.54.00): โดยค่าเริ่มต้นใน Edge สำหรับ Private Cloud 4.54.00 ระบบจะปิดใช้การโหลดแพ็กเกจ Java ที่นำออก (เช่น javax.xml.bind.* และ javax.activation.*) จาก JAR ของทรัพยากรภายนอกหรือที่รวมมา (conf_system_java.21.enable.external.allowed.packages=false) ดังนั้นการรวม JAR เพียงอย่างเดียวจะไม่ทำงานโดยค่าเริ่มต้น คุณต้องเปิดใช้พร็อพเพอร์ตี้นี้ใน /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) (คุณสามารถกำหนดค่าพร็อพเพอร์ตี้นี้ก่อนอัปเกรดโหนด Message Processor หรือตั้งค่าหลังจากอัปเกรดและรีสตาร์ท Message Processor) ดังนี้ 
    conf_system_java.21.enable.external.allowed.packages=true
  6. ไม่มีปัญหาเกี่ยวกับการเข้าชมแบบเรียลไทม์หลังการอัปเกรด: เมื่ออัปเกรดคลัสเตอร์เป็น Edge for Private Cloud 4.54.00 โดยเปิดใช้ conf_system_java.21.enable.external.allowed.packages=true แล้ว Message Processor จะมี JAR ที่จำเป็นอยู่แล้วและโหลดคลาสจากไฟล์ทรัพยากรที่รวมมาโดยไม่มีข้อผิดพลาด (NoClassDefFoundError) ซึ่งจะช่วยให้การอัปเกรดเป็นไปอย่างราบรื่นและไม่มีช่วงพักการทำงาน

ตัวอย่างโค้ด: คำสั่งตรวจสอบ XML และคำอธิบายประกอบการแยกวิเคราะห์

พิจารณา Java Callout ของ Apigee ทั่วไปที่แยกและตรวจสอบคำสั่งซื้อ XML ขาเข้าโดยใช้ JAXB (JAXBContext และ Unmarshaller)

  • ก่อนการแก้ไข (ไม่สำเร็จใน Edge for Private Cloud 4.54.00): ใน Edge for Private Cloud 4.53.x แพ็กเกจพร็อกซีจะมีเฉพาะ JAR ของไฮไลต์ โดยอาศัยไลบรารีรันไทม์ Java 8 ในตัวสำหรับ JAXB ดังนี้ 
    apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar   <-- No JAXB JAR bundled

    การใช้งาน Java Callout:

    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 สำหรับ Private Cloud 4.53.x การดำเนินการนี้จะทำงานโดยไม่มีปัญหา เมื่ออัปเกรดโหนดเป็น Edge สำหรับ Private Cloud 4.54.00 พร็อกซีนี้จะล้มเหลวทันทีในระหว่างการประมวลผลคำขอ

    java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
        at com.example.callout.OrderXmlParserCallout.execute(OrderXmlParserCallout.java:20)
  • หลังจากการแก้ไข (เข้ากันได้ทั้ง Edge สำหรับ Private Cloud 4.53.x และ 4.54.00): คุณไม่จำเป็นต้องเขียนใหม่หรือคอมไพล์โค้ด Java Callout ใหม่ คุณสามารถทำให้พร็อกซีเข้ากันได้ทั้ง 2 แบบโดยตรงโดยระบุ 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 ให้ประกาศทรัพยากร Dependency เหล่านี้ใน pom.xml เพื่อให้ระบบจัดแพ็กเกจโดยอัตโนมัติในระหว่างการสร้าง

    2. ติดตั้งใช้งานและทดสอบในคลัสเตอร์ 4.53.x ปัจจุบัน: ติดตั้งใช้งานแพ็กเกจพร็อกซีที่อัปเดตแล้วในสภาพแวดล้อม Edge for Private Cloud 4.53.x ที่มีอยู่ แล้วส่งการโทรทดสอบ เนื่องจาก Message Processor ของ Edge for Private Cloud 4.53.x โหลดคลาสจาก JAR ที่รวมมาเหล่านี้ คุณจึงสามารถยืนยันได้ว่าคำขอเสริมจะยังคงทำงานเหมือนเดิม
    3. เปิดใช้การโหลดแพ็กเกจที่อนุญาตภายนอกผ่าน CwC: เนื่องจากการโหลดแพ็กเกจที่อนุญาตภายนอกปิดใช้อยู่โดยค่าเริ่มต้นใน Edge สำหรับ Private Cloud 4.54.00 (conf_system_java.21.enable.external.allowed.packages=false) ให้เปิดใช้ในโหนด Message Processor แต่ละโหนดใน /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) ดังนี้ 
      conf_system_java.21.enable.external.allowed.packages=true
    4. ไม่มีปัญหาเกี่ยวกับการเข้าชมแบบเรียลไทม์หลังการอัปเกรด: เมื่อตรวจสอบในสภาพแวดล้อม 4.53.x และกำหนดค่าด้วยพร็อพเพอร์ตี้ CwC แล้ว พร็อกซีของคุณจะพร้อมใช้งานอย่างเต็มรูปแบบ เมื่ออัปเกรดคลัสเตอร์เป็น Edge สำหรับ Private Cloud 4.54.00 แล้ว Message Processor จะโหลดคลาส JAXB ที่รวมมาด้วย เพื่อให้มั่นใจว่าไม่มีข้อผิดพลาดและไม่มีการหยุดชะงักของการเข้าชมแบบเรียลไทม์

กลยุทธ์ที่ 2: การติดตั้งใช้งานทางเลือก (การปรับโค้ดและการขึ้นต่อกันให้ทันสมัย)

กรณีที่ควรใช้: แนะนำสำหรับฐานของโค้ดที่ใช้งานอยู่ซึ่งมีการดูแลรักษาซอร์สโค้ดพร็อกซีอย่างสม่ำเสมอ ซึ่งเป็นแนวทางระยะยาวที่ชัดเจนที่สุดสำหรับการปฏิบัติตามข้อกำหนดของ Java 21 หมายเหตุเกี่ยวกับการเปิดตัว: เนื่องจากการติดตั้งใช้งานการแก้ไขพร็อกซีที่ปรับปรุงใหม่ต้องมีการประสานงานกับ Message Processor ให้จับคู่กลยุทธ์นี้กับกลยุทธ์ 3A (ในช่วงเวลาบำรุงรักษาที่วางแผนไว้) หรือกลยุทธ์ 3B (เพื่อให้ไม่มีช่วงเวลาที่ระบบหยุดทำงานด้วย Message Processor แบบคู่ขนาน)

วิธีการทำงาน: แทนที่คลาสภายใน Java ที่ถูกนำออกด้วย Java SE API มาตรฐานอย่างเป็นทางการหรือรายการเทียบเท่าแบบสแตนด์อโลนโอเพนซอร์ส และแพ็กเกจทรัพยากร Dependency ของบุคคลที่สามที่จำเป็นโดยตรงภายในไฟล์ทรัพยากรแพ็กเกจพร็อกซีหรือ POM

ตัวอย่างโค้ด

ตัวอย่างที่ 1: การปรับปรุงวิธีการและโค้ดให้ทันสมัย (การแทนที่ยูทิลิตีภายในที่ถูกนำออก)

ใน Java 8 คำบรรยายภาพมักใช้คลาสยูทิลิตีภายใน เช่น sun.misc.BASE64Encoder ใน Java สมัยใหม่ คลาสเหล่านี้ถูกนำออกไปแล้ว แต่ API 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;
    }
}
ตัวอย่างที่ 2: การเปลี่ยนโครงสร้างภายในโค้ดระดับการนำเข้าด้วยไลบรารีที่รวมมา (JAXB Namespace Prefix Mapper)

ใน Java 8 พร็อกซี API ที่ปรับแต่งคำนำหน้าเนมสเปซ XML มักจะขยาย JAXB Mapper ภายในของ Sun 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;
    }
}
  • การกำหนดค่าทรัพยากร Dependency ที่รวมมา (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>

กลยุทธ์ที่ 3ก: ช่วงเวลาหยุดทำงานเพื่อบำรุงรักษาตามกำหนดการ (การติดตั้งใช้งานซ้ำในตำแหน่งเดิม)

กรณีที่ควรใช้: แนะนำสำหรับสภาพแวดล้อมที่มีช่วงเวลาบำรุงรักษาตามกำหนดเวลา ซึ่งยอมรับการหยุดชะงักของบริการเป็นระยะเวลาสั้นๆ ได้

ขั้นตอน

  1. ประสานงานช่วงเวลาบำรุงรักษาตามกำหนดการกับผู้ใช้ API
  2. อัปเกรดคอมโพเนนต์ Edge สำหรับ Private Cloud เป็นเวอร์ชัน 4.54.00 โดยทำตามคู่มือเส้นทางการอัปเกรด
  3. ติดตั้งใช้งานการแก้ไขพร็อกซี API ที่คอมไพล์ล่วงหน้าและเข้ากันได้กับ 4.54.00 โดยใช้ New Edge UI หรือ Apigee Management API (Deployments)
  4. ยืนยันการดำเนินการคำขอไฮบริดโดยส่งคำขอทดสอบสังเคราะห์ไปยัง Message Processor และตรวจสอบบันทึกโดยใช้เครื่องมือติดตาม
  5. ปิดช่วงเวลาบำรุงรักษาและเปิดให้มีการเข้าชมแบบสาธารณะอีกครั้ง

กลยุทธ์ 3B: สร้างสภาพแวดล้อมใหม่ (การย้ายข้อมูลแบบไม่มีช่วงเวลาที่ระบบหยุดทำงาน)

กรณีที่ควรใช้: แนะนำสำหรับสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ที่สำคัญต่อภารกิจซึ่งต้องไม่มีช่วงเวลาที่ระบบหยุดทำงาน ใช้ตัวเลือกนี้เมื่อไม่สามารถอัปเดต Java Callout ให้ทำงานใน Java 8 และ Java 21 พร้อมกันได้

วิธีการทำงาน: กลยุทธ์นี้เกี่ยวข้องกับการจัดหาสภาพแวดล้อมใหม่ 1 รายการขึ้นไปเพื่อให้คุณเชื่อมต่อโหนด Message Processor เวอร์ชันต่างๆ เข้ากับสภาพแวดล้อมดังกล่าวได้ จากนั้นให้ติดตั้งใช้งานพร็อกซีที่เข้ากันได้กับ Java 8 ในสภาพแวดล้อมที่เชื่อมต่อกับ Message Processor 4.53.X และพร็อกซีที่เข้ากันได้กับ Java 21 ในสภาพแวดล้อมที่เชื่อมต่อกับ Message Processor 4.54.00 จากนั้นใช้ตัวจัดสรรภาระงานหรือเทคนิคการกำหนดเส้นทางอื่นๆ เพื่อกำหนดเส้นทางการรับส่งข้อมูลไปยังพร็อกซีที่เข้ากันได้กับ Java 21 เท่านั้น

สำหรับกลยุทธ์นี้ การทำความเข้าใจวิธีที่องค์กร สภาพแวดล้อม และ Message Processor โต้ตอบกันเป็นกุญแจสำคัญในการทำ Cutover แบบไม่มีช่วงพักการทำงาน (ดูข้อมูลเพิ่มเติมได้ที่โครงสร้างองค์กรของ Apigee Edge)

  • องค์กร Apigee คือขอบเขตการดูแลระบบระดับบนสุดที่มีสภาพแวดล้อมหลายรายการ (เช่น prod, test)
  • ระบบจะทำให้การแก้ไขพร็อกซี API ใช้งานได้ในสภาพแวดล้อมที่เฉพาะเจาะจง เฉพาะ Message Processor ที่เชื่อมโยงกับสภาพแวดล้อมนั้นอย่างชัดเจนเท่านั้นที่จะโหลดและเรียกใช้การแก้ไขพร็อกซี
+------------------------------------------------------------------------+
|                          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. จัดสรรโหนด Message Processor เวอร์ชัน 4.54.00: ติดตั้ง Edge สำหรับ Private Cloud เวอร์ชัน 4.54.00 ในอินสแตนซ์ VM ใหม่หรือชั่วคราว แล้วเชื่อมโยงโหนดเหล่านี้กับ prod-migration (ดูหัวข้อการเพิ่ม Message Processor)
  3. ระบุพร็อกซีที่ได้รับผลกระทบและสร้างการแก้ไขที่อัปเดต: ระบุพร็อกซี API โดยใช้ Java Callout (โดยใช้เครื่องมือตรวจจับการเปลี่ยนแปลง) และสร้างการแก้ไขใหม่ของพร็อกซีที่ได้รับผลกระทบแต่ละรายการด้วย Java Callout ที่เข้ากันได้กับ Edge for Private Cloud 4.54.00 (ใช้กลยุทธ์ที่ 1 หรือกลยุทธ์ที่ 2)
  4. ติดตั้งใช้งานการแก้ไขพร็อกซีที่ปรับปรุงใหม่ในสภาพแวดล้อมชั่วคราว: ติดตั้งใช้งานการแก้ไขพร็อกซีที่อัปเดตและเข้ากันได้ใน prod-migration เท่านั้น
  5. ตรวจสอบและเปลี่ยนเส้นทางการเข้าชม: ดำเนินการทดสอบการตรวจสอบสังเคราะห์กับโฮสต์เสมือนใหม่ เมื่อยืนยันแล้ว ให้กำหนดค่าตัวจัดสรรภาระงานภายนอก (F5, NGINX) เพื่อเปลี่ยนเส้นทางการเข้าชมของไคลเอ็นต์จาก prod ไปยัง prod-migration
  6. อัปเกรดโหนดเดิมและเปลี่ยนกลับ: ยกเลิกการติดตั้งใช้งานพร็อกซีเดิมจาก prod อัปเกรดโหนด Message Processor เดิมเป็น 4.54.00 โดยทำตามคำแนะนำเกี่ยวกับเส้นทางการอัปเกรด ทำให้การแก้ไขพร็อกซีที่ปรับปรุงใหม่ใช้งานได้ใน prod เปลี่ยนเส้นทางการรับส่งข้อมูลของตัวจัดสรรภาระงานกลับไปยัง prod และยืนยันการดำเนินการ
  7. เลิกใช้สภาพแวดล้อมชั่วคราว: ยกเลิกการติดตั้งใช้งานพร็อกซีจาก prod-migration นำโหนด Message Processor ชั่วคราวออก และลบสภาพแวดล้อมชั่วคราว

กลยุทธ์ 3C: การวางตำแหน่งไลบรารีภายนอกระดับโหนด (ไลบรารีสำรองที่ใช้ร่วมกัน)

กรณีที่ควรใช้: แนะนำเมื่อคุณมีพร็อกซี API หลายรายการที่ใช้คลาส Java ซึ่งถูกนำออกใน Java 21 และการคอมไพล์ใหม่หรือการแพ็กเกจใหม่ของแพ็กเกจพร็อกซีแต่ละรายการก่อนการอัปเกรดไม่สามารถดำเนินการได้

วิธีการทำงาน: ใน Edge สำหรับ Private Cloud 4.54.00 Message Processor จะมีกลไกในการโหลดคลาส Java ที่ขาดหายไปจากไดเรกทอรีโหนดเฉพาะ: $APIGEE_ROOT/data/edge-message-processor/external-lib

เมื่อเปิดใช้กลไกนี้ Message Processor จะตรวจสอบไดเรกทอรีนี้เพื่อหาคลาสที่ขาดหายไปก่อนที่จะกลับไปใช้การแก้ไขเริ่มต้น คุณสามารถระบุคลาสที่ขาดหายไปได้โดยการจัดหาคลาสจาก JAR ของไลบรารีของบุคคลที่สาม หรือโดยการรวมคลาสที่จำเป็นไว้ใน JAR แล้ววางไว้ใน external-lib

ขั้นตอน

  1. สร้างไดเรกทอรีไลบรารีภายนอกในโหนด Message Processor แต่ละโหนด 
    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. เปิดใช้การโหลดแพ็กเกจภายนอกในการกำหนดค่า Message Processor: โดยค่าเริ่มต้นใน Edge สำหรับ Private Cloud 4.54.00 ระบบจะปิดใช้การโหลดแพ็กเกจที่อนุญาตภายนอก (conf_system_java.21.enable.external.allowed.packages=false) หากต้องการเปิดใช้ Message Processor เพื่อแก้ไขและโหลดคลาสจาก /opt/apigee/data/edge-message-processor/external-lib คุณต้องเปิดใช้พร็อพเพอร์ตี้นี้ใน /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) 
    conf_system_java.21.enable.external.allowed.packages=true
  5. รีสตาร์ท Message Processor: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

กลยุทธ์ที่ 4: แฟล็ก JVM (--add-opens / --add-exports — ข้อควรระวังและทางเลือกสุดท้าย)

กรณีที่ควรใช้: ใช้กลยุทธ์นี้เป็นทางเลือกสุดท้ายสำหรับไลบรารีของผู้ให้บริการบุคคลที่สามแบบโคลสซอร์สที่ไม่มีซอร์สโค้ด ผู้ให้บริการยังไม่ได้เผยแพร่การอัปเดต Java 21 และ JAR ขึ้นอยู่กับการเข้าถึงแบบสะท้อนแสงไปยังแพ็กเกจ Java ภายในอย่างเคร่งครัด

ขั้นตอน

  1. ระบุแพ็กเกจที่เข้าถึงไม่ได้ซึ่งใช้สำหรับการสะท้อน: ระบุโมดูลและแพ็กเกจ Java ภายในที่ไลบรารีของบุคคลที่สามเข้าถึงแบบสะท้อน หมายเหตุ: ข้อผิดพลาดในการสะท้อนเหล่านี้เกิดขึ้นภายใต้ Java 21 ใน Edge for Private Cloud 4.54.00 เท่านั้น และจะไม่ปรากฏในบันทึกเวอร์ชัน 4.53.x ตรวจสอบบันทึก Message Processor (/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. แก้ไข /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) (สร้างไฟล์หากไม่มี)
  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. รีสตาร์ท Message Processor โดยใช้ apigee-service ดังนี้ 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

การเปลี่ยนแปลง TLS และชุดการเข้ารหัส

ใน Edge for Private Cloud 4.54.00 คอมโพเนนต์แพลตฟอร์มหลัก ซึ่งรวมถึง Message Processor, Management Server และเราเตอร์ ได้รับการอัปเดตให้ทำงานบน Java 21 LTS การอัปเดตนี้จะปรับปรุงความปลอดภัยด้านการเข้ารหัสให้ทันสมัยโดยเปิดใช้ TLS 1.3 โดยค่าเริ่มต้น (JEP 332) ตอนนี้ Message Processor จะเจรจาต่อรอง TLS 1.3 เป็นโปรโตคอลที่ต้องการสำหรับการเชื่อมต่อแบ็กเอนด์ขาออก โดยจะเปลี่ยนกลับไปใช้ TLS 1.2 หากแบ็กเอนด์ไม่รองรับ

ข้อกำหนดและการแก้ไขแบ็กเอนด์เดิม

เกณฑ์พื้นฐานด้านวิทยาการเข้ารหัสของ Java 21 จะอัปเดตรายการโปรโตคอลและชุดการเข้ารหัสที่ปิดใช้โดยค่าเริ่มต้นใน jdk.tls.disabledAlgorithms (เช่น โปรโตคอล TLS เดิมและชุดการแลกเปลี่ยนคีย์ RSA แบบคงที่ที่ไม่ใช่ Forward Secret: TLS_RSA_*) เนื่องจากคุณจัดหารันไทม์ Java 21 ของคุณเอง รายการโปรโตคอลและชุดการเข้ารหัสที่ปิดใช้จึงขึ้นอยู่กับการใช้งาน Java 21 ของคุณโดยเฉพาะ

หากพร็อกซี API ที่มีอยู่เชื่อมต่อกับโครงสร้างพื้นฐานแบ็กเอนด์เดิมที่ต้องใช้โปรโตคอลที่ปิดใช้หรือการเข้ารหัส RSA แบบคงที่ โปรดตรวจสอบการดำเนินการต่อไปนี้

  • ปรับปรุงความปลอดภัยของแบ็กเอนด์ให้ทันสมัย (แนะนำ): อัปเกรดเซิร์ฟเวอร์เป้าหมายและตัวจัดสรรภาระงานให้รองรับ TLS 1.2 หรือ TLS 1.3 ด้วยชุดการเข้ารหัส ECDHE ที่ทันสมัย หากต้องการกำหนดค่าโปรโตคอลและชุดการเข้ารหัสในพร็อกซี API โปรดดูการกำหนดค่า TLS จาก Edge ไปยังแบ็กเอนด์และข้อมูลอ้างอิงการกำหนดค่า TLS/SSL TargetEndpoint (หรือการจัดสรรภาระงานในเซิร์ฟเวอร์แบ็กเอนด์หากใช้ TargetServers)
  • เปิดใช้อัลกอริทึมเดิมอีกครั้งโดยใช้ CwC (มาตรการเปลี่ยนผ่านระหว่างการอัปเกรด): หากการอัปเกรดแบ็กเอนด์ไม่เสร็จสมบูรณ์ก่อนการอัปเกรดแพลตฟอร์ม คุณสามารถเปิดใช้อัลกอริทึมที่จำเป็นอีกครั้งชั่วคราวโดยใช้โค้ดที่มีการกำหนดค่า (CwC) ดังนี้
    1. ตรวจสอบค่า jdk.tls.disabledAlgorithms เริ่มต้นในการติดตั้ง Java 21 (เช่น ใน $JAVA_HOME/conf/security/java.security)
    2. ลบล้าง conf_jvmsecurity_jdk.tls.disabledAlgorithms ใน /opt/apigee/customer/application/message-processor.properties ด้วยรายการอัลกอริทึมที่ปิดใช้รายการเดียวกัน โดยนำเฉพาะรายการ TLS_RSA_* ออก (เก็บอัลกอริทึมที่ปิดใช้รายการอื่นๆ ทั้งหมดไว้เหมือนเดิมเพื่อให้การป้องกันที่เหลือยังคงเปิดใช้อยู่)
    3. รีสตาร์ท Message Processor โดยใช้ apigee-service นำการลบล้างนี้ออกเมื่อแบ็กเอนด์รองรับชุดการเข้ารหัส ECDHE
  • อัปเดตรายการที่อนุญาตของชุดการเข้ารหัสที่กำหนดเอง: หากก่อนหน้านี้คุณลบล้าง conf_http_HTTPTransport.ssl.cipher.suites.whitelist ไว้ ให้ตรวจสอบก่อนอัปเกรด Java 21 ไม่รองรับชุด RSA แบบคงที่ (TLS_RSA_*) อีกต่อไป ดังนั้นรายการที่อนุญาตซึ่งมีเฉพาะชุดเหล่านั้นจะทำให้ Message Processor ไม่มีรหัสที่ใช้งานได้ และการเรียกใช้แบ็กเอนด์จะล้มเหลวพร้อมข้อความ no cipher suites in common นำรายการ TLS_RSA_* ออกและกำหนดค่าชุดการเข้ารหัสที่ทันสมัยซึ่งรองรับโดยการติดตั้งใช้งาน Java 21 หากคุณไม่ได้ลบล้างพร็อพเพอร์ตี้นี้ ค่าเริ่มต้น 4.54.00 จะมีชุดที่รองรับอยู่แล้วและไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ
  • อัปเดตเราเตอร์ภายในเป็นชุดการเข้ารหัส Message Processor: หากก่อนหน้านี้คุณลบล้าง conf_message-processor-communication_local.http.ssl.ciphers ด้วยชุด RSA แบบคงที่ ให้อัปเดตด้วยชุดการเข้ารหัสสมัยใหม่ที่รองรับโดยการติดตั้งใช้งาน Java 21 ก่อนอัปเกรด ไม่เช่นนั้นเราเตอร์จะไม่สามารถทำแฮนด์เชค TLS กับ Message Processor ได้ จากนั้นรีสตาร์ท Message Processor โดยทำดังนี้ 
    apigee-service edge-message-processor restart
     ดูหัวข้อการกำหนดค่า TLS ระหว่างเราเตอร์กับ Message Processor

ดูรายละเอียดเกี่ยวกับการกำหนดค่า TLS ระหว่างคอมโพเนนต์ Edge ได้ที่หัวข้อการกำหนดค่า TLS ระหว่างเราเตอร์กับ Message Processor

เครื่องมือตรวจหาการเปลี่ยนแปลง

Apigee มีเครื่องมือตรวจหาการเปลี่ยนแปลงเพื่อสแกนคลัสเตอร์เพื่อหาพร็อกซี API, นโยบาย, โฟลว์ที่แชร์ และ JAR ของทรัพยากรที่ติดตั้งใช้งานซึ่งอาจได้รับผลกระทบจากการอัปเกรดเป็น Edge for Private Cloud 4.54.00

เครื่องมือนี้จะระบุตัวบล็อกการอัปเกรดที่อาจเกิดขึ้น ซึ่งรวมถึงไลบรารีที่เข้ากันไม่ได้กับ Java 21, API ภายในที่แคปซูลอย่างเข้มงวด, การเลิกใช้งานนโยบายเดิม และขีดจำกัด RDN ของ OpenLDAP และสร้างรายงานที่นำไปใช้ได้จริงเพื่อช่วยคุณเลือกกลยุทธ์การแก้ไขที่เหมาะสม

ดูข้อกำหนดเบื้องต้นทั้งหมด วิธีการดาวน์โหลด ไวยากรณ์บรรทัดคำสั่ง และรายงานตัวอย่างได้ที่คู่มือเครื่องมือตรวจจับการเปลี่ยนแปลงโดยเฉพาะ