Antipattern: จัดการทรัพยากร Edge โดยไม่ใช้การจัดการการควบคุมแหล่งที่มา

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X
ข้อมูล

Apigee Edge มีทรัพยากรหลายประเภทและแต่ละประเภทก็มีจุดประสงค์แตกต่างกัน มีทรัพยากรบางอย่างที่กำหนดค่าได้ (เช่น สร้าง อัปเดต และ/หรือลบ) ผ่าน Edge UI, API การจัดการ หรือเครื่องมือที่ใช้ API การจัดการเท่านั้น และโดยผู้ใช้ที่มีบทบาทและสิทธิ์ที่จำเป็นก่อน ตัวอย่างเช่น เฉพาะผู้ดูแลระบบขององค์กรซึ่งเป็นขององค์กรหนึ่งๆ เท่านั้นที่จะกำหนดค่าทรัพยากรเหล่านี้ได้ ซึ่งหมายความว่าผู้ใช้ปลายทางจะกำหนดค่าทรัพยากรเหล่านี้ผ่านพอร์ทัลของนักพัฒนาซอฟต์แวร์หรือกำหนดค่าอื่นๆ ไม่ได้ แหล่งข้อมูลเหล่านี้จะมีข้อมูลต่อไปนี้

  • พร็อกซี API
  • ขั้นตอนที่แชร์
  • ผลิตภัณฑ์ API
  • แคช
  • KVM
  • คีย์สโตร์และ Truststore
  • โฮสต์เสมือน
  • เซิร์ฟเวอร์เป้าหมาย
  • ไฟล์ทรัพยากร

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

พร็อกซี API และโฟลว์ที่แชร์ภายใต้การควบคุมการแก้ไข

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

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

การตรวจสอบและประวัติ

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

ลายป้องกัน

การจัดการทรัพยากร Edge (ข้างต้น) โดยตรงผ่าน Edge UI หรือ API การจัดการโดยไม่ต้องใช้ระบบควบคุมแหล่งที่มา

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

ลองมาอธิบายเรื่องนี้กันโดยใช้ตัวอย่าง 2-3 ข้อและประเภทของผลกระทบที่อาจเกิดขึ้นหากข้อมูลไม่ได้มีการจัดการผ่านระบบควบคุมแหล่งที่มา และมีการแก้ไข/ลบโดยเจตนาหรือไม่ทราบ

ตัวอย่างที่ 1: การลบหรือแก้ไขพร็อกซี API

เมื่อลบพร็อกซี API หรือมีการนำการเปลี่ยนแปลงไปใช้กับการแก้ไขที่มีอยู่ คุณจะกู้คืนโค้ดก่อนหน้าไม่ได้ หากพร็อกซี API มีโค้ด Java, JavaScript, Node.js หรือ Python ที่ไม่ได้จัดการในระบบการจัดการการควบคุมแหล่งที่มา (SCM) ภายนอก Apigee อีกทั้งอาจสูญเสียงานและการพัฒนาจำนวนมาก

ตัวอย่างที่ 2: การกำหนดพร็อกซี API โดยใช้โฮสต์เสมือนที่ระบุ

ใบรับรองบนโฮสต์เสมือนกำลังจะหมดอายุและโฮสต์เสมือนดังกล่าวจะต้องอัปเดต การระบุว่าพร็อกซี API ใดใช้โฮสต์เสมือนสำหรับการทดสอบอาจเป็นเรื่องยากหากมีพร็อกซี API จำนวนมาก หากมีการจัดการพร็อกซี API ในระบบ SCM ภายนอก Apigee การค้นหาที่เก็บจะเป็นเรื่องง่าย

ตัวอย่างที่ 3: การลบ keystore/truststore

หากคีย์สโตร์/ทรัสต์สโตร์ที่ใช้โดยโฮสต์เสมือนหรือการกำหนดค่าเซิร์ฟเวอร์เป้าหมายถูกลบออก ระบบจะกู้คืนคีย์ดังกล่าวกลับมาไม่ได้ เว้นแต่รายละเอียดการกำหนดค่าของคีย์สโตร์/ทรัสต์สโตร์ รวมถึงใบรับรองและ/หรือคีย์ส่วนตัว จะจัดเก็บอยู่ในการควบคุมต้นทาง

มีอิทธิพล

  • หากทรัพยากร Edge ถูกลบ คุณจะกู้คืนทรัพยากรและเนื้อหาจาก Apigee Edge ไม่ได้
  • คำขอ API อาจล้มเหลวโดยมีข้อผิดพลาดที่ไม่คาดคิดซึ่งนำไปสู่การหยุดทำงานจนกว่าจะกู้คืนทรัพยากรกลับไปเป็นสถานะก่อนหน้า
  • การค้นหาความพึ่งพากันระหว่างพร็อกซี API และทรัพยากรอื่นๆ ใน Apigee Edge นั้นทำได้ยาก

แนวทางปฏิบัติแนะนำ

  • ใช้ SCM มาตรฐานที่ใช้ร่วมกับไปป์ไลน์การรวมอย่างต่อเนื่องและการทำให้ใช้งานได้อย่างต่อเนื่อง (CICD) เพื่อจัดการพร็อกซี API และโฟลว์ที่แชร์
  • ใช้ SCM มาตรฐานเพื่อจัดการทรัพยากร Edge อื่นๆ ซึ่งรวมถึงผลิตภัณฑ์ API, แคช, KVM, เซิร์ฟเวอร์เป้าหมาย, โฮสต์เสมือน และคีย์สโตร์
    • หากมีทรัพยากร Edge อยู่แล้ว ให้ใช้ API การจัดการเพื่อรับรายละเอียดการกำหนดค่าสำหรับทรัพยากรเหล่านั้นเป็นเพย์โหลด JSON/XML และจัดเก็บไว้ในการจัดการการควบคุมแหล่งที่มา
    • จัดการการอัปเดตใหม่ๆ ของทรัพยากรเหล่านี้ในการจัดการการควบคุมแหล่งที่มา
    • หากจำเป็นต้องสร้างทรัพยากร Edge ใหม่หรืออัปเดตทรัพยากร Edge ที่มีอยู่ ให้ใช้เพย์โหลด JSON/XML ที่เหมาะสมซึ่งจัดเก็บไว้ในการจัดการการควบคุมแหล่งที่มา และอัปเดตการกำหนดค่าใน Edge โดยใช้ API การจัดการ

* ไม่สามารถส่งออก KVM ที่เข้ารหัสเป็นข้อความธรรมดาจาก API ได้ ผู้ใช้มีหน้าที่รับผิดชอบในการเก็บบันทึกค่าที่ใส่ใน KVM ที่เข้ารหัส

อ่านเพิ่มเติม