Google Cloud เปิด Compute Engine API multi-versioning ตรึงเวอร์ชันได้ ไม่กระทบ /v1
Google Cloud ประกาศ 5 พฤศจิกายน 2026 ว่า Compute Engine API multi-versioning พร้อมใช้งานทั่วไป ตรึงเวอร์ชันตามวันที่ได้ และ /v1 เดิมยังทำงานตามปกติ
โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที
สรุปประเด็นสำคัญ
- Google Cloud ประกาศเมื่อ 5 พฤศจิกายน 2026 ว่า Compute Engine API multi-versioning พร้อมใช้งานทั่วไป (GA) ในทุกภูมิภาคของ Google Cloud
- เวอร์ชันเสถียรตามวันที่เริ่มที่ 2026-09-01 ออกทุกไตรมาส ไม่รับการเปลี่ยนที่ทำให้พัง และ Google ระบุว่ายัง ไม่มีวันสิ้นสุดซัพพอร์ต
- เวอร์ชัน preview เช่น 2026-10-01-preview มีอายุ 1 ปี สำหรับทดสอบฟีเจอร์ก่อนเข้าเวอร์ชันเสถียร
- API
/v1เดิม ไม่ถูกเปลี่ยน และยังเป็นค่าเริ่มต้นเมื่อไม่ระบุเวอร์ชัน สคริปต์และอินทิเกรชันเดิมไม่ต้องแก้ - เวอร์ชันวันที่เปิด
returnPartialSuccessเป็นค่าเริ่มต้นใน AggregatedList จึงไม่ล้มทั้งคำขอเมื่อโซนใดโซนหนึ่งมีปัญหาชั่วคราว
Google Cloud ประกาศเมื่อวันที่ 5 พฤศจิกายน 2026 ว่า Compute Engine API multi-versioning พร้อมใช้งานทั่วไป (GA) ในทุกภูมิภาค ผู้ใช้ตรึงการเรียก API ไว้ที่เวอร์ชันตามวันที่ เช่น 2026-09-01 ได้ ส่วนเส้นทาง /v1 เดิมยังทำงานตามปกติและเป็นค่าเริ่มต้นเมื่อไม่ระบุเวอร์ชัน
ข่าวนี้เกี่ยวกับทีมที่ใช้สคริปต์ Terraform หรือไลบรารีควบคุม VM บน Google Cloud ไม่ใช่ผู้ใช้คอนโซลทั่วไป ข้อมูลทั้งหมดมาจากบล็อกของ Google Cloud และมาตรฐาน AIP-185 ที่บล็อกอ้างถึง
Compute Engine API multi-versioning ทำงานอย่างไร
เดิม Compute Engine ใช้การแบ่งเวอร์ชันตามช่องทาง 3 ช่อง คือ /v1 (พร้อมใช้งานทั่วไป), /beta และ /alpha Google อธิบายว่าเพราะ /v1 เป็นพื้นผิวเดียวที่ทุกลูกค้าทั่วโลกใช้ร่วมกัน การปรับพฤติกรรมเพียงเล็กน้อย เช่น เปลี่ยนค่าเริ่มต้นหรือรูปแบบข้อผิดพลาด จึงเสี่ยงทำให้สคริปต์เดิมพัง หรือต้องใช้เวลาย้ายหลายปี
Compute Engine API multi-versioning แก้ด้วยการเพิ่มสแนปช็อตที่แก้ไม่ได้ตามวันที่ ตามแนวทาง interface-based versioning ของ AIP-185 โดยมี 3 ส่วน
| ส่วน | รายละเอียดที่ Google ระบุ |
|---|---|
| เวอร์ชันเสถียร (YYYY-MM-DD) | ออกทุกไตรมาส เริ่ม 2026-09-01 ไม่รับการเปลี่ยนที่ทำให้พังหลังเผยแพร่ ยังไม่มีวันสิ้นสุดซัพพอร์ต |
| เวอร์ชัน preview (YYYY-MM-DD-preview) | ออกถี่กว่า เช่น 2026-10-01-preview แตกจากเวอร์ชันเสถียร อายุ 1 ปี |
| /v1 เดิม | ยังรองรับเต็มที่ และเป็นค่าเริ่มต้นเมื่อไม่ระบุเวอร์ชัน |
การเรียกเวอร์ชันวันที่ใช้เส้นทาง /compute/v1/ เหมือนเดิม และเลือกเวอร์ชันผ่านเฮดเดอร์ X-Goog-Api-Version หรือพารามิเตอร์ $apiVersion ทำให้ selfLink ของทรัพยากรยังเหมือนกันทุกเครื่องมือ
Compute Engine API multi-versioning เปลี่ยนค่าเริ่มต้นอะไร
Google ยกตัวอย่างสิ่งที่เวอร์ชันวันที่ปรับได้โดยไม่แตะ /v1 ดังนี้
- คำขอรวมทุกโซนไม่ล้มทั้งชุด ใน /v1 การเรียก AggregatedList ข้ามโซนและภูมิภาคตั้ง returnPartialSuccess เป็น false หากโซนใดโซนหนึ่งมีปัญหา คำขอทั้งหมดอาจล้ม ในเวอร์ชันวันที่เปิดเป็นค่าเริ่มต้น
- ข้อผิดพลาดอ่านด้วยเครื่องได้ ใช้ google.rpc.ErrorInfo ที่มี reason, domain และ metadata เช่นรายการ supported_versions เมื่อระบุเวอร์ชันผิด ไม่ต้องแยกข้อความด้วย regex
- สิทธิ์ IAM เข้มขึ้น เปิดทางให้ปรับการตรวจสิทธิ์ที่กว้างเกินไปในเวอร์ชันใหม่ โดยไม่ทำให้ระบบอัตโนมัติเดิมบน /v1 พัง
- สคีมาทรัพยากรสะอาดขึ้น ค่อย ๆ ปรับสคีมาเก่ากว่าสิบปีให้เข้ากับ Google API Improvement Proposals
เครื่องมือเลือกเวอร์ชันให้อย่างไร
ตามตารางของ Google ผู้ใช้ไม่ต้องเขียนเวอร์ชันเองในกรณีส่วนใหญ่
- ไลบรารีไคลเอนต์ (Python, Go, Java, Node.js, C#, Ruby, PHP) แต่ละรุ่นผูกกับเวอร์ชันวันที่หนึ่งและคงชื่อแพ็กเกจ compute_v1 กับ apiv1 อัปเกรดไลบรารีตามปกติโดยไม่ต้องแก้ import
- gcloud คำสั่ง gcloud compute ใช้เวอร์ชันเสถียรที่มากับเครื่องมือ กลุ่มคำสั่ง gcloud preview compute ใช้เวอร์ชัน preview
- Terraform ผู้ให้บริการ google ใช้ API เวอร์ชันเสถียร ส่วน google-beta ใช้ API preview ไม่ต้องตั้งเวอร์ชันใน HCL
- REST ตรง ระบุเวอร์ชันด้วยเฮดเดอร์หรือพารามิเตอร์ เช่น 2026-09-01 หรือ 2026-10-01-preview
ทำไม Compute Engine API multi-versioning สำคัญต่อองค์กรไทย
ทีมที่ผูกระบบอัตโนมัติกับ Compute Engine ไม่ว่าจะเป็นพื้นที่ Bangkok ที่ Google Cloud เปิดแล้ว (ดูข่าว Datastream Bangkok region) หรือภูมิภาคอื่น ได้วิธีควบคุมจังหวะการรับพฤติกรรมใหม่ ข้อดีคือทดสอบใน staging โดยเปลี่ยนสตริงเวอร์ชันเดียว แล้วค่อยขึ้น production ข้อควรระวังคือประกาศของ Google พูดถึงเฉพาะ API ของ Compute Engine จึงอย่าสรุปว่าบริการอื่นของ Google Cloud เปลี่ยนตามไปด้วย
สิ่งที่ทีมไอทีควรทำหลังข่าว Compute Engine API multi-versioning
- ตรวจว่าสคริปต์ที่เรียก Compute Engine ใช้ /v1 โดยตรง ผ่านไลบรารี หรือผ่าน Terraform และเวอร์ชันไลบรารีหรือโปรไวเดอร์ที่ติดตั้งอยู่
- ทดสอบ 2026-09-01 ใน staging เพื่อดูผลของค่าเริ่มต้นใหม่ เช่น returnPartialSuccess ก่อนตัดสินใจย้าย
- ถ้ามีโค้ดแยกข้อความผิดพลาดด้วย regex ให้เตรียมเปลี่ยนไปอ่านฟิลด์ ErrorInfo
- อัปเดต gcloud ด้วย gcloud components update ถ้าต้องการลองชุดคำสั่ง preview
- ตามข่าวคลาวด์อื่นได้ที่หมวดคลาวด์
บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง
ทีมที่ดูแลระบบอัตโนมัติบนคลาวด์ต้องจัดการการเปลี่ยนเวอร์ชัน การทดสอบ และการเฝ้าระวังไปพร้อมงานประจำวัน Managed Cloud Services ของ THAI DATA CLOUD ดูแลตั้งแต่ติดตั้ง บริหาร ไปจนถึง Monitoring ระบบคลาวด์ขององค์กรตลอด 24 ชั่วโมง ให้ทีมไอทีภายในโฟกัสงานหลัก (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)
คำถามที่พบบ่อย
Compute Engine API multi-versioning คืออะไร?
Compute Engine API multi-versioning คือการที่ Google Cloud เพิ่มเวอร์ชัน API แบบกำหนดวันที่ (YYYY-MM-DD) ข้างเส้นทาง /v1 เดิม ผู้ใช้ตรึงสัญญา API ไว้ที่เวอร์ชันหนึ่งและอัปเกรดตามจังหวะของตนเอง ประกาศ GA เมื่อ 5 พฤศจิกายน 2026
Compute Engine API multi-versioning กระทบสคริปต์เดิมที่ใช้ /v1 หรือไม่?
ไม่กระทบ Google Cloud ระบุว่า /v1 ยังรองรับเต็มที่และเป็นค่าเริ่มต้นเมื่อไม่ระบุเวอร์ชัน แอปพลิเคชัน สคริปต์ และอินทิเกรชันเดิมทำงานต่อได้โดยไม่ต้องแก้ไข
เรียกใช้เวอร์ชันวันที่ของ Compute Engine API ได้อย่างไร?
ใส่เฮดเดอร์ X-Goog-Api-Version เช่น 2026-09-01 หรือใช้พารามิเตอร์ $apiVersion ใน URL เส้นทาง /compute/v1/ เดิม ส่วนไลบรารีไคลเอนต์ gcloud และ Terraform เลือกเวอร์ชันให้ตามรุ่นที่ติดตั้ง
Compute Engine API multi-versioning เปลี่ยนพฤติกรรมอะไรในเวอร์ชันวันที่?
ตัวอย่างที่ Google ระบุคือเปิด returnPartialSuccess เป็นค่าเริ่มต้นใน AggregatedList ใช้รูปแบบข้อผิดพลาด google.rpc.ErrorInfo ที่อ่านด้วยเครื่องได้ และเปิดทางปรับสิทธิ์ IAM ที่กว้างเกินให้เข้มขึ้นโดยไม่กระทบ /v1
แหล่งอ้างอิง
- Introducing Compute Engine API multi-versioning: Predictable evolution without breaking production — Google Cloud
- AIP-185: API Versioning — Google API Improvement Proposals
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Google Cloud94Google191
- ผลิตภัณฑ์และเทคโนโลยี
- Terraform12Python43Java19Node.js21PHP23
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ