Skip to content

การอัปเกรดระบบ

เวอร์ชันของผลิตภัณฑ์จะระบุเวอร์ชันของคอมโพเนนต์เมทริกซ์ (component matrix) ที่ผ่านการทดสอบร่วมกันเรียบร้อยแล้ว การอัปเกรดระบบจะหมายถึงการเปลี่ยนผ่านแพลตฟอร์มทั้งหมดไปยังเวอร์ชันที่เผยแพร่ใหม่พร้อมกันทั้งชุด โดยไม่มีการแยกอัปเกรดส่วนประกอบใดส่วนประกอบหนึ่งแยกต่างหาก ซึ่งอิมเมจจริงที่ได้รับการทดสอบในเวอร์ชันที่เผยแพร่นั้นจะเป็นชุดอิมเมจเดียวกับที่จะถูกส่งมอบให้คุณใช้งาน

เอกสารนี้เหมาะสำหรับใคร

วิศวกรแพลตฟอร์ม (platform engineer) ที่ทำหน้าที่อัปเกรดระบบติดตั้งเดิมที่มีอยู่แล้วให้เป็นเวอร์ชันที่ใหม่ขึ้น

หนึ่งเวอร์ชันต่อชุดทดสอบหนึ่งชุด

ในแต่ละเวอร์ชันผลิตภัณฑ์ เช่น v1.8.0 จะระบุเวอร์ชันของทุก ๆ ส่วนประกอบที่เกี่ยวข้องไว้ ได้แก่ Kubernetes baseline, gateway, control plane, console, ฐานข้อมูล, ระบบระบุตัวตน, ระบบตรวจสอบสถานะการทำงาน และปลั๊กอินในตัว ซึ่งทั้งหมดนี้ผ่านการทดสอบการทำงานร่วมกันเป็นชุดระบบเดียว การปรับเพิ่มเวอร์ชันผลิตภัณฑ์จะส่งผลเปลี่ยนผ่านเวอร์ชันของทั้งชุดพร้อมกัน โดยคุณไม่จำเป็นต้องอัปเกรดปลั๊กอินตัวใดตัวหนึ่งหรือฐานข้อมูลระบบตัวใดตัวหนึ่งแยกกันโดยเดี่ยว

คุณสามารถเลือกตั้งค่าเวอร์ชันที่ต้องการผ่าน Helm chart และแท็กอิมเมจของส่วนประกอบได้ โดยสามารถดูรายละเอียดโครงสร้างค่ากำหนดอิมเมจได้ที่ เอกสารอ้างอิงการกำหนดค่า และตรวจสอบฟีเจอร์ของแต่ละเวอร์ชันได้ที่ บันทึกการเผยแพร่ (Release notes)

รูปแบบ Build-once และ Promote-by-retag

ในขั้นตอนการเผยแพร่เวอร์ชัน ค่าอิมเมจไดเจสต์ (image digest) จริง ที่ผ่านการทดสอบแล้วจะเป็นตัวที่ถูกส่งมอบออกไป โดยอิมเมจจะได้รับการเปลี่ยนผ่านโดยการเปลี่ยนป้ายกำกับ (retagging) และไม่มีการบิลด์อิมเมจใหม่ระหว่างแต่ละสภาพแวดล้อม ดังนั้นอิมเมจจริงที่คุณเรียกใช้งานบนสภาพแวดล้อมจริงจึงมีความถูกต้องแบบบิตต่อบิตตรงกับตัวที่ผ่านการทดสอบความถูกต้องมาแล้ว โดยคุณไม่จำเป็นต้องทำกระบวนการบิลด์ระบบใหม่เอง เพียงแค่ดาวน์โหลดผ่านแท็กอิมเมจที่เผยแพร่อย่างเป็นทางการเท่านั้น

ขั้นตอนการอัปเกรดระบบ

  1. อ่าน บันทึกการเผยแพร่ (Release notes) สำหรับเวอร์ชันเป้าหมาย โดยตรวจสอบความต้องการค่ากำหนดใหม่หรือการเปลี่ยนแปลงพฤติกรรมการทำงานของระบบ

  2. สำรองข้อมูล PostgreSQL ของระบบ control plane ไว้ล่วงหน้า ดูรายละเอียดเพิ่มเติมได้ที่ การสำรองข้อมูลและการกู้คืน (Backup & DR)

  3. ปรับปรุงค่าแท็กอิมเมจหรือเวอร์ชันของ chart ในไฟล์ values ของคุณให้เป็นไปตามเวอร์ชันเป้าหมาย

  4. ปรับใช้การกำหนดค่า ด้วยคำสั่ง helm upgrade ดังนี้

    bash
    helm upgrade opsta-ai-gateway oci://ghcr.io/opsta/charts/opsta-ai-gateway \
      -n opsta-ai-gateway -f values.yaml -f secrets-values.yaml
  5. ตรวจสอบความพร้อมทำงาน control plane จะจัดการย้ายฐานข้อมูล (database migrations) และดำเนินการปรับประสานสถานะครั้งใหม่ก่อนที่จะเปลี่ยนสถานะเป็นพร้อมทำงาน ซึ่งช่วยให้มั่นใจได้ว่าเกตเวย์จะไม่มีวันให้บริการข้อมูลในสถานะที่การย้ายข้อมูลยังดำเนินการไม่เสร็จสิ้นเด็ดขาด

    bash
    kubectl -n opsta-ai-gateway rollout status deploy/control-plane
  6. ทดสอบระบบเบื้องต้น (Smoke-test) โดยการส่งคำร้องขอผ่านเกตเวย์และทดลองลงชื่อเข้าใช้งานหน้าจอ console

การทยอยอัปเกรดระบบในโหมด HA

ใน โหมดความพร้อมใช้งานสูง (High availability) ระบบจะเปิดใช้งาน PodDisruptionBudget และกฎ anti-affinity เพื่อคอยควบคุมให้มี replica ขั้นต่ำของแต่ละส่วนประกอบสแตนด์บายทำงานอยู่ในระหว่างขั้นตอนการทยอยติดตั้ง ส่งผลให้การอัปเกรดไม่ส่งผลกระทบหยุดชะงักต่อการรับส่งทราฟฟิกจริงในขณะนั้น สำหรับระบบสลับการทำงานอัตโนมัติของฐานข้อมูลจะจัดการโดย CloudNativePG

ค่ากำหนดที่คุณแก้ไขด้วยตนเองจะถูกปรับประสานใหม่

ข้อมูลผู้เช่า เช่น ผู้บริโภค งบประมาณ ผู้ให้บริการ และ guardrail จะถูกดูแลโดย control plane และไม่ได้รับผลกระทบจากการอัปเกรดระบบ ส่วนตัว Helm chart จะคอยดูแลค่ากำหนดในระดับผลิตภัณฑ์ ดังนั้นการแก้ไขใด ๆ ด้วยตนเองภายนอก chart อาจถูกลบและเขียนทับใหม่ในระหว่างการอัปเกรดระบบ โปรดปรับเปลี่ยนค่าต่าง ๆ ผ่านไฟล์ values เท่านั้น และหลีกเลี่ยงการเข้าไปแก้ไขทรัพยากรในคลัสเตอร์โดยตรง

การย้อนกลับเวอร์ชัน (Rolling back)

คำสั่ง helm rollback จะช่วยย้อนกลับการตั้งค่าใน chart ไปเป็นเวอร์ชันก่อนหน้า เนื่องจากฐานข้อมูล PostgreSQL ทำหน้าที่เป็นแหล่งข้อมูลความจริงของระบบ หากจำเป็นต้องยกเลิกผลการย้ายฐานข้อมูล คุณต้องกู้คืนข้อมูลจากไฟล์สำรองฐานข้อมูลที่ได้จัดทำไว้ล่วงหน้าก่อนการอัปเกรด และโปรดทดสอบการอัปเกรดระบบบนสภาพแวดล้อม staging ทุกครั้งก่อนเริ่มดำเนินการจริง

ขั้นตอนต่อไป

Enterprise AI governance, on infrastructure you own.