Terraform 1.17 ออกแล้ว Terraform Policy พ้นสถานะทดลอง พร้อมตัวเลือก -minimal-refresh
Terraform 1.17 ออก 21 ต.ค. 2026 ใช้ -policies กับ plan, apply และ query โดยไม่ต้องใช้บิลด์ทดลอง เพิ่ม -minimal-refresh ลดการเรียก API และใส่ตัวแปรใน provider
โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที
สรุปประเด็นสำคัญ
- HashiCorp ออก Terraform 1.17.0 ลงวันที่ 21 ตุลาคม 2026 มีฟีเจอร์ใหม่ 3 อย่าง คือ Terraform Policy, ตัวเลือก
-minimal-refreshและตัวแปรใน provider requirements - แฟล็ก
-policiesของplan,applyและqueryไม่ต้องใช้บิลด์ทดลองหรือแฟล็ก-allow-experimental-featuresอีกต่อไป แต่หน้าเอกสาร Terraform Policy (v0.5.x) ยังติดป้ายเบต้า ณ 23 ต.ค. -minimal-refreshrefresh เฉพาะ resource ที่มีแผนจะเปลี่ยน ตอบคำขอที่เปิดไว้ตั้งแต่ 4 มิถุนายน 2024 (issue #35290) แต่เอกสารเตือนว่าอาจได้แผนที่ไม่ครบหรือไม่ถูกต้อง- ตัวแปรแบบ
constและ locals ใช้ในsourceและversionของrequired_providersได้แล้ว ต่อยอดจาก Terraform 1.15.0 (29 เมษายน 2026) ที่เปิดให้ใช้ตัวแปรใน module source - Terraform 1.17 บิลด์ด้วย Go 1.26.10 ซึ่งเลิกเชื่อถือใบรับรองจาก intermediate CA ของ eMudhra ที่ถูกเจาะ และ
terraform version -jsonมีฟิลด์format_versionใหม่
HashiCorp ออก Terraform 1.17 ลงวันที่ 21 ตุลาคม 2026 (หน้า GitHub Release ขึ้นเวลา 00:32 น. ของวันที่ 22 ตุลาคมตามเวลาไทย) รุ่นนี้ถอดสถานะทดลองของแฟล็ก -policies ให้ตรวจ policy ระหว่าง plan, apply และ query ได้ในบิลด์ปกติ เพิ่มตัวเลือก -minimal-refresh ที่ลดการเรียก API ของ cloud provider และให้ใส่ตัวแปรใน required_providers ได้เป็นครั้งแรก
Terraform 1.17 มาหลัง Terraform 1.16.0 (26 สิงหาคม 2026) 8 สัปดาห์ และวันถัดมา (22 ตุลาคม) HashiCorp ออก 1.16.7 ให้ผู้ที่ยังอยู่บนสาขาเดิม
Terraform 1.17 มีอะไรใหม่บ้าง
| ฟีเจอร์ | สิ่งที่เปลี่ยน | ผลต่อทีม |
|---|---|---|
| Terraform Policy | -policies ใช้กับ plan, apply, query ได้โดยไม่ต้องใช้บิลด์ทดลองหรือ -allow-experimental-features |
ตรวจกติกาองค์กรใน pipeline ด้วย HCL |
-minimal-refresh |
refresh เฉพาะ resource ที่มีแผนจะเปลี่ยน | plan เร็วขึ้นบน state ขนาดใหญ่ เรียก API น้อยลง |
| ตัวแปรใน provider requirements | ใช้ตัวแปร const และ locals ใน source และ version ได้ |
เปลี่ยน registry หรือรุ่น provider ตามสภาพแวดล้อมได้ |
terraform version -json |
เพิ่มฟิลด์ format_version |
สคริปต์ที่อ่าน JSON ควรเช็กฟิลด์นี้ |
ส่วนงานย่อยอื่นใน changelog มีทั้ง terraform init ที่บันทึกเวอร์ชัน provider ลง log, mock_provider ใน terraform test ที่รองรับ ephemeral resource และ terraform login ที่แจ้งเตือนเมื่อองค์กรตั้งนโยบายอายุโทเคน (TTL) ไว้
Terraform Policy ใน Terraform 1.17: ตรวจ policy ด้วย HCL
Terraform Policy คือกรอบงาน policy-as-code ของ HashiCorp ที่เขียนด้วย HCL ภาษาเดียวกับไฟล์ Terraform ใช้บล็อก policy, locals และ enforce และอ้างถึง resource ใดก็ได้ที่ provider นิยามไว้ ตามเอกสาร policy ตรวจได้ 3 จังหวะ
- ตอน
terraform initตรวจ source และเวอร์ชันของ provider และ module ก่อนดาวน์โหลด ซึ่ง Sentinel และ OPA ทำไม่ได้เพราะทำงานหลัง init เสร็จแล้ว - ตอน plan ตรวจกับแผนที่ Terraform สร้าง
- หลัง apply ตรวจค่าที่รู้ได้หลังสร้างจริง เช่น ARN หรือ ID แต่ถ้าผิดกติกา โครงสร้างพื้นฐานได้เปลี่ยนไปแล้ว ทีมต้องแก้แล้ว deploy ใหม่
ระดับการบังคับใช้มี 3 ระดับ คือ advisory, mandatory-overridable และ mandatory ส่วนคำสั่ง query ใช้ policy ประเมิน resource ที่ค้นพบผ่านบล็อก list แล้วรายงานผลเป็นข้อความหรือ JSON
จุดที่ต้องอ่านให้ละเอียดคือ changelog ของ Terraform 1.17 เขียนว่า Terraform Policy "generally available" ในความหมายว่าแฟล็กไม่ต้องเปิดฟีเจอร์ทดลองแล้ว แต่หน้าเอกสาร Terraform Policy เวอร์ชัน v0.5.x ที่เราเปิดดูเมื่อ 23 ตุลาคม 2026 ยังมีกล่องเตือนว่าเป็นเบต้าและไม่ควรใช้ใน production
องค์กรที่ใช้ HCP Terraform อยู่แล้วยังใช้ Sentinel และ Open Policy Agent (OPA) ต่อได้ หน้าเปรียบเทียบระบุว่า HCP Terraform ยังรองรับทั้งสองตัว แต่ถ้าจะย้ายมาใช้ Terraform Policy ต้องแปลง policy เดิมเป็นไวยากรณ์ HCL ก่อน
-minimal-refresh: ตอบคำขอที่ค้างมากว่า 2 ปี
ทุกครั้งที่สั่ง terraform plan ตามค่าเริ่มต้น Terraform จะ refresh ทุก resource ใน state เพื่อเทียบกับของจริงบนคลาวด์ ถ้า state มี resource หลายพันรายการ ขั้นนี้กินเวลานาน และ provider อาจจำกัดอัตราการเรียก API ผู้ใช้รายหนึ่งเปิด issue #35290 เมื่อ 4 มิถุนายน 2024 (ตอนนั้นใช้ Terraform 1.8.4) ขอให้มีโหมดที่วางแผนเฉพาะสิ่งที่เปลี่ยน issue นี้มีผู้กดสนับสนุน (+1) กว่า 180 ครั้ง และหน้า issue ชี้ไปยัง pull request ที่เพิ่ม -minimal-refresh ใน v1.17.0
เอกสารคำสั่ง plan อธิบายว่า -minimal-refresh จะเทียบ configuration กับ state เดิมก่อน resource ใดไม่มีแผนจะเปลี่ยนก็ข้ามการ refresh resource ใดมีการเปลี่ยนจึง refresh แล้ววางแผนใหม่ แต่มีข้อจำกัดสำคัญ
- เหมือน
-refresh=falseตรงที่ไม่เห็นการแก้ไขจากภายนอก (drift) บน resource ที่ข้ามไป แผนจึงอาจไม่ครบหรือไม่ถูกต้อง - ใช้คู่กับ
-refresh=falseหรือโหมด refresh-only ไม่ได้ - ถ้า schema version ของ resource เปลี่ยน Terraform จะ refresh เสมอ และเอกสารแนะนำไม่ให้ใช้ตอนอัปเกรด provider
ตัวแปรใน provider requirements
Terraform 1.15.0 (29 เมษายน 2026) เปิดให้ใช้ตัวแปรและ locals ใน source และ version ของ module แล้ว Terraform 1.17 ขยายแนวคิดเดียวกันไปที่บล็อก required_providers ตามตัวอย่างใน pull request #39153 ผู้ใช้กำหนด source เป็น app.terraform.io/${var.organization}/random และใช้ local กำหนดเวอร์ชันได้ โดยตัวแปรต้องประกาศ const = true
ตัวแปรแบบ const ต้องเป็นค่าคงที่ที่รู้ได้ตอนโหลด configuration และพึ่งผลจากขั้น plan ไม่ได้ ส่งค่าเข้ามาได้ทุกทางที่ plan รองรับ เช่น -var, -var-file หรือตัวแปรสภาพแวดล้อม ทีมที่ใช้ private registry แยกตามองค์กร หรือต้องล็อกรุ่น provider ต่างกันระหว่างสภาพแวดล้อม จึงไม่ต้องคัดลอกโค้ดเป็นหลายชุดอีก
ทำไม Terraform 1.17 สำคัญ
Policy-as-code เดิมใน ecosystem ของ HashiCorp ผูกกับ Sentinel ซึ่งมีภาษาของตัวเอง หรือ OPA ที่ใช้ Rego ทีม DevOps จึงต้องเรียนอีกภาษาหนึ่งเพื่อเขียนกติกา Terraform 1.17 ทำให้กติกาเขียนด้วย HCL และรันจาก CLI ได้ตรง ๆ ช่วยให้ทีมแพลตฟอร์มตรวจได้ตั้งแต่ขั้น init ว่าโปรเจกต์ดึง provider หรือ module จากแหล่งที่อนุญาตเท่านั้น
ส่วน -minimal-refresh แก้ปัญหาที่ผู้ดูแล state ขนาดใหญ่เจอทุกวัน คือ plan ช้าและชนเพดาน API ทั้งที่แก้ resource ไม่กี่ตัว ขณะที่ changelog ยังระบุว่า Terraform 1.17 บิลด์ด้วย Go 1.26.10 ซึ่งเลิกเชื่อถือใบรับรองที่ออกผ่าน intermediate CA ของ eMudhra ที่ถูกเจาะ
ผลต่อองค์กรไทยและทีมพัฒนา
- ทดสอบ Terraform 1.17 ในสภาพแวดล้อมทดสอบก่อน แล้วค่อยเลื่อนเวอร์ชันใน
required_versionและ image ของ CI สคริปต์ที่อ่านผลจากterraform version -jsonควรรองรับฟิลด์format_version - เริ่ม Terraform Policy ในโหมด advisory เพราะเอกสารยังติดป้ายเบต้า เลือกกติกาที่ชัดเจนก่อน เช่น ห้ามใช้ provider นอกรายการ หรือบังคับแท็กเจ้าของ resource แล้วค่อยเลื่อนเป็น mandatory
- ใช้
-minimal-refreshกับ plan ระหว่างวัน ไม่ใช่ทุกงาน ยังควรมีงานตามรอบที่ refresh เต็มเพื่อจับ drift และหลีกเลี่ยงตอนอัปเกรด provider ตามคำแนะนำของเอกสาร - ทีมที่ใช้ HCP Terraform กับ Sentinel หรือ OPA ไม่ต้องรีบย้าย วางแผนแปลงเฉพาะกติกาที่ได้ประโยชน์จากการตรวจตอน init หรือหลัง apply และติดตามข่าวเครื่องมือ DevOps อื่นได้ที่หมวดการพัฒนาซอฟต์แวร์
คำถามที่พบบ่อย
Terraform 1.17 มีอะไรใหม่?
Terraform 1.17 ที่ลงวันที่ 21 ตุลาคม 2026 มีฟีเจอร์ใหม่ 3 อย่าง คือ ใช้แฟล็ก -policies กับ plan, apply และ query ได้โดยไม่ต้องเปิดฟีเจอร์ทดลอง เพิ่มตัวเลือก -minimal-refresh ที่ refresh เฉพาะ resource ที่จะเปลี่ยน และใส่ตัวแปรแบบ const หรือ locals ใน source และ version ของ provider ได้
-minimal-refresh ใน Terraform 1.17 ต่างจาก -refresh=false อย่างไร?
-refresh=false ข้ามการ refresh ทั้งหมด ส่วน -minimal-refresh ยัง refresh resource ที่มีแผนจะเปลี่ยน แต่ข้าม resource ที่ไม่มีการเปลี่ยน จึงเรียก API น้อยลง ทั้งสองแบบมองไม่เห็นการแก้ไขจากภายนอกบน resource ที่ข้ามไป เอกสารจึงเตือนว่าแผนอาจไม่ครบ และไม่ควรใช้ตอนอัปเกรด provider
Terraform Policy ใช้งานจริงได้หรือยัง?
ฝั่ง Terraform CLI ตั้งแต่ Terraform 1.17 แฟล็ก -policies ไม่ต้องใช้บิลด์ทดลองแล้ว และ changelog เรียกว่า generally available แต่หน้าเอกสาร Terraform Policy เวอร์ชัน v0.5.x ยังมีป้ายว่าเป็นเบต้าและไม่ควรใช้ใน production ณ วันที่ 23 ตุลาคม 2026 องค์กรจึงควรเริ่มจากโหมด advisory ก่อน
ต้องเขียน policy Sentinel หรือ OPA ใหม่ไหม?
ไม่บังคับ HCP Terraform ยังรองรับ Sentinel และ Open Policy Agent (OPA) อยู่ แต่ถ้าจะใช้ Terraform Policy ซึ่งเขียนด้วย HCL เอกสารระบุว่าต้องแปลง policy เดิมเป็นไวยากรณ์ HCL ก่อน โดยยังไม่มีประกาศเลิกใช้ Sentinel หรือ OPA
แหล่งอ้างอิง
- Release v1.17.0 · hashicorp/terraform — GitHub (HashiCorp)
- Implement dynamic provider sources · Pull Request #39153 — GitHub (HashiCorp)
- terraform plan -light · Issue #35290 — GitHub (HashiCorp)
- terraform plan command reference — HashiCorp Developer
- Terraform policy — HashiCorp Developer
- Compare policy frameworks — HashiCorp Developer
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- ผลิตภัณฑ์และเทคโนโลยี
- Terraform7
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ