อธิบาย OpenTofu: การแยกโค้ดจาก Terraform การย้ายระบบ และควรเปลี่ยนหรือไม่

เปิดโมดูล Terraform วันนี้แล้วคุณจะเจอคำถามที่ไม่เคยมีอยู่เมื่อสามปีก่อน นั่นคือไบนารีที่รันโค้ดนี้คือ terraform หรือเป็น tofuหรือไม่? IBM การเข้าซื้อกิจการ HashiCorp เมื่อวันที่ 27 กุมภาพันธ์ 2025 มูลค่า 6.4 พันล้านดอลลาร์เสร็จสมบูรณ์ และ OpenTofu ได้กลายเป็น โครงการ CNCF Sandbox เมื่อวันที่ 23 เมษายน 2025 และเส้นทางการย้ายระหว่างสองเครื่องมือนี้ได้รับการบันทึกอย่างเป็นทางการแล้ว การตัดสินใจนี้ไม่ใช่เรื่องสมมติอีกต่อไป

บทความนี้เขียนจากมุมมองของฝ่ายปฏิบัติการโครงสร้างพื้นฐาน ไม่ใช่จากมุมมองของแพลตฟอร์ม Terraform แบบมีผู้ดูแล เป้าหมายคือการแยกต้นทุนการย้ายระบบที่แท้จริงออกจากเสียงรบกวนเรื่องใบอนุญาตและการกำกับดูแล นั่นหมายความว่าผมสามารถพูดตรงๆ ได้ว่าอะไรพังระหว่างการย้ายระบบ คำถามด้านการกำกับดูแลที่ชอบธรรม และกรณีที่การอยู่กับ Terraform ต่อไปคือทางเลือกที่ถูกต้อง

บทความนี้ครอบคลุมสี่เรื่อง ได้แก่ OpenTofu ในปี 2026 คืออะไร ฟีเจอร์ที่ Terraform ไม่มี การย้ายระบบในทางปฏิบัติเป็นอย่างไร และคำแนะนำที่ชัดเจนสำหรับรูปแบบการตัดสินใจทั่วไป

เวอร์ชันสั้น

• OpenTofu เป็นซอฟต์แวร์โอเพนซอร์สที่แยกออกมาจาก Terraform ภายใต้ใบอนุญาต MPL 2.0 โฮสต์โดย Linux Foundation และเป็นโครงการ CNCF Sandbox ตั้งแต่วันที่ 23 เมษายน 2025 โดยแยกออกมาจาก Terraform 1.5.x หลังจากที่ HashiCorp เปลี่ยน Terraform ไปใช้ Business Source License ในเดือนสิงหาคม 2023
• ณ วันที่ 26 กรกฎาคม 2025 รุ่นบำรุงรักษาปัจจุบันคือ v1.12.5; ที่เก็บ GitHub มีดาวมากกว่า 29,000 ดวง และ เว็บไซต์โครงการ OpenTofu แสดงรายชื่อ provider มากกว่า 3,900 รายการและโมดูลมากกว่า 23,600 รายการ
• มันมาพร้อมความสามารถที่มีเฉพาะใน OpenTofu หรือที่ OpenTofu นำหน้า ซึ่ง Terraform ยังไม่มีในแบบเดียวกัน ได้แก่ การเข้ารหัส state และ plan ฝั่งไคลเอนต์ provider for_each การประเมินตัวแปรล่วงหน้า enabled meta-argument และ dynamic prevent_destroy ทั้งนี้ ephemeral resources ไม่ได้มีเฉพาะใน OpenTofu เท่านั้น เพราะ Terraform รองรับมาตั้งแต่เวอร์ชัน 1.10
• สำหรับโปรเจกต์ Terraform 1.5.x ขนาดเล็กที่ใช้ state แบบโลคอลหรือ S3 เส้นทางง่ายๆ อาจเป็นการย้ายระบบที่สั้นและย้อนกลับได้ ส่วนที่งานจะขยายตัวคือการอ้างอิงใน CI/CD เวิร์กโฟลว์เฉพาะของ HCP และการเปลี่ยนแปลง dependency lock
• สำหรับโปรเจกต์ IaC ใหม่ในปี 2026 ให้เริ่มด้วย OpenTofu สำหรับการใช้งาน Terraform ที่มีอยู่แล้ว ให้เปลี่ยนเมื่อ BSL เริ่มเป็นอุปสรรค เมื่อคุณต้องการฟีเจอร์ที่ OpenTofu มีแต่ Terraform ไม่มี หรือเมื่อแผนงานที่ IBM ควบคุมเป็นความกังวลจริงๆ นอกเหนือจากนั้นความคุ้มค่าถือว่าน้อย

OpenTofu ในปี 2026 คืออะไร

OpenTofu เป็นซอฟต์แวร์โอเพนซอร์สที่แยกออกมาจาก Terraform โฮสต์โดย Linux Foundation ได้รับการยอมรับเข้าสู่ CNCF ในฐานะโครงการ Sandbox เมื่อวันที่ 23 เมษายน 2025 และอยู่ภายใต้ใบอนุญาต Mozilla Public License 2.0 ไบนารีของมันคือ tofu ภาษาที่ใช้ตั้งค่าคือ HCL ซึ่งเป็น HCL แบบเดียวกับที่ Terraform ใช้ สำหรับโปรเจกต์ขนาดเล็กถึงกลางส่วนใหญ่ โค้ดเบส Terraform ที่มีอยู่แล้วจะรันบน OpenTofu ได้โดยไม่ต้องแก้ไข

การแยกโค้ดเริ่มขึ้นในเดือนสิงหาคม 2023 หลังจาก HashiCorp ย้าย Terraform จาก MPL 2.0 ไปยัง Business Source License 1.1 เมื่อวันที่ 10 สิงหาคม 2023 ใบอนุญาต BSL เป็นแบบ "source-available" ไม่ใช่ที่ได้รับการรับรองจาก OSI และจำกัดการใช้งานเชิงการผลิตที่ "แข่งขันกับผลิตภัณฑ์เชิงพาณิชย์ของ HashiCorp" ภายในห้าวัน OpenTF Manifesto ได้รับการเผยแพร่และมีการประกาศแยกโค้ด การประกาศของ Linux Foundation ได้แนะนำ OpenTofu อย่างเป็นทางการเมื่อวันที่ 20 กันยายน 2023

ประกาศของ Linux Foundation ระบุชื่อ Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver และ Terramate เป็นผู้สนับสนุนผู้ก่อตั้ง โดยมีวิศวกรอย่างน้อย 18 คนที่ให้คำมั่นทำงานเต็มเวลาอย่างน้อยห้าปี OpenTofu แยกออกมาจาก Terraform 1.5.x ซึ่งเป็นเวอร์ชันสุดท้ายภายใต้ MPL 2.0

โครงการนี้อยู่ตรงไหนในวันนี้ v1.12.5 คือรุ่นบำรุงรักษาปัจจุบัน และเว็บไซต์ทางการแสดงรายชื่อ provider มากกว่า 3,900 รายการและโมดูลมากกว่า 23,600 รายการ สัญญาณการนำไปใช้งานไม่ได้จำกัดอยู่แค่แรงส่งของการแยกโค้ดเพื่อประท้วงอีกต่อไป กรณีศึกษาการย้ายระบบของ Fidelity อธิบายโปรแกรมที่ครอบคลุมไฟล์ state มากกว่า 50,000 ไฟล์และทรัพยากรสี่ล้านรายการ

บริบททางธุรกิจที่เกี่ยวข้อง IBM เสร็จสิ้นการเข้าซื้อกิจการ HashiCorp เมื่อวันที่ 27 กุมภาพันธ์ 2025 มูลค่า 6.4 พันล้านดอลลาร์ แผนงานของ Terraform ตอนนี้ถูกกำหนดอยู่ภายในผู้ให้บริการองค์กรที่ใหญ่กว่ามาก นั่นไม่ได้แปลว่าดีหรือแย่สำหรับผู้ใช้โดยอัตโนมัติ แต่เป็นส่วนหนึ่งของการคำนวณที่ทีมต่างๆ กำลังทำในปี 2026

OpenTofu แตกต่างจาก Terraform ตรงไหนบ้าง

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

ฝั่งไคลเอนต์ การเข้ารหัส state (v1.7.0, 30 เมษายน 2024) OpenTofu สามารถเข้ารหัสไฟล์ state และ plan ภายในตัวเครื่องมือเองด้วย PBKDF2, AWS KMS, GCP KMS หรือ OpenBao โดยทั่วไป Terraform จะมอบหมายการเข้ารหัสขณะพักข้อมูลให้กับ backend ที่เลือกไว้ ในขณะที่ state แบบโลคอลยังคงเป็นข้อความธรรมดา การเข้ารหัสฝั่งไคลเอนต์ของ OpenTofu สามารถปกป้องอ็อบเจ็กต์ state ที่ถูกขโมยหรือ plan ที่แคชไว้ได้ ตราบใดที่คีย์ถอดรหัสไม่ได้ถูกเปิดเผยไปพร้อมกัน มันไม่ได้แทนที่ TLS การควบคุมการเข้าถึง backend หรือวินัยการจัดการความลับ

การตั้งค่ามีลักษณะคร่าวๆ ดังนี้:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

ผู้ให้บริการ for_each (v1.9). คุณสามารถวนซ้ำการตั้งค่า provider ได้แบบเดียวกับที่วนซ้ำ resource ได้ สำหรับการตั้งค่าแบบหลายภูมิภาคหรือหลายบัญชี สิ่งนี้ช่วยขจัดวิธีแก้ปัญหาแบบเลี่ยงๆ ที่ใช้กันมานาน คุณไม่จำเป็นต้องสร้าง provider แบบ alias ทีละภูมิภาคด้วยมืออีกต่อไป แต่สามารถขับเคลื่อนบล็อกเดียวจาก map ได้เลย

การประเมินตัวแปรล่วงหน้า (v1.8) ตัวแปรสามารถถูกอ้างอิงในตำแหน่งที่เคยถูกจำกัดไว้ก่อนหน้านี้ รวมถึงอาร์กิวเมนต์ backend และ module source สิ่งนี้มีประโยชน์เมื่อโมดูลรากเดียวขับเคลื่อนหลายสภาพแวดล้อมที่แตกต่างกันเพียงชุดตัวแปรเล็กๆ

Ephemeral resources และ enabled meta-argument (v1.11.0, 9 ธันวาคม 2025) OpenTofu 1.11 เพิ่ม ephemeral resources และ enabled meta-argument เพิ่มเข้ามา ephemeral resources มีอยู่แค่ภายในรอบ plan/apply เดียวเท่านั้นและไม่คงอยู่ใน state ซึ่งมีประโยชน์สำหรับข้อมูลรับรองที่มีอายุสั้น มันไม่ได้มีเฉพาะใน OpenTofu เท่านั้น เพราะ Terraform นำมาใช้ตั้งแต่เวอร์ชัน 1.10 และเพิ่มอาร์กิวเมนต์แบบ write-only ใน 1.11 ความสามารถเฉพาะของ OpenTofu ตรงนี้คือ enabled ซึ่งสลับเปิด/ปิดบล็อก resource จากนิพจน์โดยไม่ต้องใช้ count count

Dynamic prevent_destroy (v1.12). การตั้งค่า prevent_destroy ของ Terraform รับได้แค่ค่าตายตัวเท่านั้น OpenTofu 1.12 ให้คุณคำนวณมันได้ ดังนั้นโมดูลเดียวสามารถให้ staging ลบได้ในขณะที่ปกป้อง production

แถวใบอนุญาตคือความแตกต่างเชิงโครงสร้างที่ไม่ปรากฏเป็นฟีเจอร์ MPL 2.0 ได้รับการรับรองจาก OSI และเป็น copyleft ระดับไฟล์ ใบอนุญาต BSL 1.1 ของ Terraform เป็นแบบ source-available มีข้อจำกัดการใช้งานเพิ่มเติม และเปลี่ยนเป็น MPL 2.0 สี่ปีหลังจากแต่ละงานที่ได้รับอนุญาตถูกเผยแพร่ สำหรับทีมส่วนใหญ่ผลกระทบในทางปฏิบัตินั้นน้อย แต่สำหรับผู้ให้บริการที่สร้างสิ่งที่ใกล้เคียงกับผลิตภัณฑ์เชิงพาณิชย์ของ HashiCorp นี่คือเหตุผลที่การแยกโค้ดนี้มีอยู่

การย้ายระบบ: อะไรพังจริงๆ

คู่มือการย้ายระบบอย่างเป็นทางการ จงใจให้สั้นและย้อนกลับได้ นั่นคือสำรอง state และโค้ด ติดตั้ง OpenTofu รัน tofu initแล้วเปรียบเทียบผลลัพธ์ของ tofu plan แล้วทดสอบการเปลี่ยนแปลงเล็กๆ ส่วนที่ยากไม่ใช่คำสั่ง แต่เป็นการอ้างอิงใน CI/CD ที่เกี่ยวข้อง เวิร์กโฟลว์เฉพาะของ HCP การเปลี่ยนแปลง dependency lock และการตรวจสอบระดับองค์กรที่มาพร้อมกับการนำการแยกโค้ดมาใช้

เส้นทางง่ายๆ

สำหรับโปรเจกต์ที่ไม่ได้ใช้ HCP Terraform และไม่มีการอ้างอิงในไปป์ไลน์นับพันไปยัง terraform ไม่มากมายนัก การย้ายระบบก็ทำได้ตรงไปตรงมา

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan ควรตรงกับ plan ที่ Terraform สร้างไว้ หากมีความแตกต่างที่ไม่คาดคิด ให้ตรวจสอบเวอร์ชัน provider การตั้งค่า backend และฟีเจอร์ Terraform หลัง 1.5.x ก่อนที่จะ apply

มีความละเอียดอ่อนสองอย่างที่สำคัญก่อนที่คุณจะรันอะไร อย่างแรก OpenTofu เข้ากันได้กับการตั้งค่าแบบ HCL สไตล์ Terraform เป็นส่วนใหญ่สำหรับกรณีที่คู่มือนี้อธิบาย แต่ฟีเจอร์ที่เพิ่มเข้ามาหลัง Terraform 1.5.x ยังคงต้องตรวจสอบความเข้ากันได้ อย่างที่สอง tofu init -upgrade อาจอัปเดต .terraform.lock.hcl รวมถึงที่อยู่แหล่งที่มาของ provider และรายการ checksum ให้ตรวจสอบข้อมูลเมทาดาทานี้แยกจากการเบี่ยงเบนของโครงสร้างพื้นฐาน

อุปสรรคตัวจริง

มีสามสิ่งที่สามารถเปลี่ยนการย้ายระบบผ่าน CLI แบบรวดเร็วให้กลายเป็นโปรเจกต์แพลตฟอร์มที่ใหญ่ขึ้นได้ ไม่มีสักอย่างที่เป็นบั๊ก

Workspace ของ HCP Terraform OpenTofu มาพร้อมกับ การผสานรวมแบบ cloud และ remote สำหรับบริการ remote ที่เข้ากันได้ รวมถึง HCP Terraform ในสถานการณ์รันแบบโลคอลและการเก็บ state ส่วนที่ยากกว่าคือการรันจากระยะไกลและฟีเจอร์แพลตฟอร์มเฉพาะของ HCP ได้แก่ Sentinel, run trigger, ข้อมูลรับรองแบบไดนามิก, Stacks และพฤติกรรมของบริการใดๆ ที่ OpenTofu ไม่สามารถทดสอบหรือรองรับได้อย่างสมบูรณ์ หากสิ่งเหล่านี้เป็นแกนหลัก ให้ลองใช้กับ workspace เดียวก่อน หากคุณกำลังจะเลิกใช้ HCP ให้ย้าย state และสร้างการควบคุมระดับแพลตฟอร์มเหล่านั้นขึ้นมาใหม่

เคล็ดลับ: การเลิกใช้ HCP Terraform อาจเป็นต้นทุนแฝงที่ใหญ่ที่สุดเมื่อระบบทั้งหมดพึ่งพาเวิร์กโฟลว์เฉพาะของ HCP ก่อนตัดสินใจ ให้รัน terraform state pull > state.json แล้วตรวจสอบขนาดและจำนวน resource workspace เดียวที่มี 200 resource เป็นโปรเจกต์ที่ต่างจากกองเรือ 50 workspace ที่มี run trigger และ policy set อย่างสิ้นเชิง กรณีหลังคือการย้ายระบบระดับ platform engineering ไม่ใช่แค่การเปลี่ยนเครื่องมือ

ไปป์ไลน์ CI/CD ที่ hardcode ไว้สำหรับ terraform. การอ้างอิงทุกจุดไปยัง terraform plan, terraform apply เส้นทางไบนารี อิมเมจ Docker และขั้นตอน GitHub Actions หรือ GitLab CI ต้องได้รับการทบทวน สำหรับ GitHub Actions การสลับมีลักษณะคร่าวๆ ดังนี้:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

นั่นคือกรณีง่ายๆ workflow เดียว repo เดียว ใน monorepo ที่มี composite action ที่ใช้ร่วมกัน หลายไปป์ไลน์ และไลบรารี workflow ที่ใช้ซ้ำได้ พื้นที่ที่ต้องทบทวนจะกว้างขึ้นมาก งานนี้เป็นงานเชิงกลไก แต่อาจใช้เวลานานกว่าการสลับ CLI

การทบทวนไฟล์ dependency lock tofu init อาจอัปเดต .terraform.lock.hcl รวมถึงที่อยู่แหล่งที่มาของ provider และรายการ checksum อาจได้รับการอัปเดต OpenTofu 1.12 ยังสามารถเพิ่มชุด checksum h1: แบบสมบูรณ์ด้วย ให้ถือว่า diff นี้เป็นเมทาดาทาของ dependency ที่ต้องทบทวนและ commit แยกต่างหาก ไม่ใช่การเบี่ยงเบนของโครงสร้างพื้นฐาน

เคล็ดลับ: diff ของไฟล์ lock อาจดูรกในการ commit ครั้งแรก tofu init -upgrade บนแบรนช์ที่สะอาด แล้ว commit เฉพาะไฟล์ lock ด้วยข้อความที่ชัดเจน เช่น "review OpenTofu lock-file changes" จากนั้น rebase งานฟีเจอร์ทับลงไป การผสมข้อมูลเมตาของ dependency เข้ากับ PR ของฟีเจอร์ทำให้ตรวจสอบการเปลี่ยนแปลงทั้งสองยากขึ้น

การต่อต้านจากผู้มีส่วนได้ส่วนเสีย "ตอนนี้เรากำลังใช้ fork อยู่" ถูกรับรู้แตกต่างกันไปในแต่ละองค์กร คำตอบที่ตรงไปตรงมาคือ OpenTofu ยังคงเข้ากันได้กับการตั้งค่าแบบ HCL สไตล์ Terraform เป็นส่วนใหญ่สำหรับกรณีที่คู่มือนี้อธิบาย ดังนั้นการเปลี่ยนแปลงนี้มักย้อนกลับได้ ถ้า OpenTofu หายไปพรุ่งนี้ หลายทีมสามารถติดตั้ง Terraform กลับ ทบทวนไฟล์ lock และใช้ .tf ไฟล์ .tf เดิมต่อไปได้ ตรวจสอบฟีเจอร์หลังการแยกโค้ดก่อน ข้อควรระวังนี้น่าเชื่อถือกว่าการสัญญาว่าจะใช้แทนกันได้อย่างสมบูรณ์แบบ

เมื่อการย้ายระบบยากจริงๆ

เส้นทางง่ายๆ นั้นไม่ได้ใช้ได้กับทุกระบบ Terraform

การย้ายระบบจะยากขึ้นอย่างมีนัยสำคัญเมื่อ:

• state มีขนาดใหญ่ (มีทรัพยากรนับพันและ workspace หลายสิบตัว) และอยู่ใน HCP Terraform
• โค้ดเบสใช้ฟีเจอร์ที่มีเฉพาะใน HCP อย่างลึกซึ้ง เช่น นโยบาย Sentinel ที่เชื่อมกับ workspace, run trigger, ข้อมูลรับรอง provider แบบไดนามิกที่ HCP จัดการ ส่วน Terraform Stacks มีเฉพาะใน HCP และไม่มีสิ่งที่เทียบเท่าใน OpenTofu ซึ่งอยู่นอกขอบเขตของบทความนี้
• การตรวจสอบระดับองค์กรหรือกรอบการปฏิบัติตามข้อกำหนดระบุชื่อ "Terraform" เป็นเครื่องมือ IaC อย่างเป็นทางการ ซึ่งเป็นปัญหาด้านการจัดซื้อและเอกสารที่ซ้อนทับปัญหาทางเทคนิค
• ไลบรารีโมดูลขนาดใหญ่มีข้อจำกัดเวอร์ชันภายในที่แก้ปัญหาโดยอิงกับพฤติกรรม registry เฉพาะของ Terraform

ไม่ใช่ทุกทีมที่ควรย้ายระบบ ความคุ้มค่าจะสมเหตุสมผลก็ต่อเมื่อข้อจำกัดของ BSL ส่งผลกระทบต่อกรณีการใช้งานของคุณจริงๆ เมื่อฟีเจอร์เฉพาะของ OpenTofu ปลดล็อกบางสิ่งที่เป็นรูปธรรม หรือเมื่อแผนงานที่ IBM ควบคุมเป็นความกังวลจริงสำหรับองค์กรของคุณ หากไม่มีข้อใดตรงกับสถานการณ์ การอยู่กับ Terraform ต่อไปก็เป็นทางเลือกที่ปกป้องได้อย่างสมเหตุสมผล

คุณควรเปลี่ยนไหม?

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

การนำ IaC มาใช้ใหม่ (greenfield) เริ่มต้นด้วย OpenTofu ใบอนุญาตคือ MPL 2.0 การกำกับดูแลอยู่ภายใต้ Linux Foundation และ CNCF และโครงการมีจังหวะการออกรุ่นที่กระตือรือร้น จุดเด่นของมันได้แก่การเข้ารหัส state ฝั่งไคลเอนต์ provider for_each, enabled และ dynamic prevent_destroy ไม่มีแรงเสียดทานจาก BSL ที่ต้องวางแผนหลีกเลี่ยง นี่คือคำแนะนำที่หนักแน่นที่สุดในบทความนี้

ผู้ใช้ Terraform เดิม โปรเจกต์ขนาดเล็กถึงกลาง เปลี่ยนหากตัวกระตุ้นสามอย่างนี้อย่างใดอย่างหนึ่งเกิดขึ้น หนึ่ง คุณขายหรืออาจขายผลิตภัณฑ์ที่อาจแตะกับข้อยกเว้น "แข่งขันกับ HashiCorp" ของ BSL การคำนวณทางกฎหมายจะชัดเจนกว่าบน MPL 2.0 สอง คุณต้องการการเข้ารหัส state ฝั่งไคลเอนต์ provider for_each, enabled หรือ dynamic prevent_destroy และวิธีแก้ปัญหาแบบเลี่ยงๆ ใน Terraform ไม่คุ้มค่าที่จะดูแลต่อไปแล้ว สาม คุณต้องการการกำกับดูแลแบบหลายฝ่ายมากกว่าแผนงานที่ควบคุมโดยผู้ให้บริการรายเดียว หากไม่มีข้อใดตรงและ Terraform ทำงานได้ราบรื่น ก็ให้อยู่ต่อไป การย้ายระบบย้อนกลับได้ในหลายกรณี แต่ไม่ใช่ฟรี

ผู้ใช้ HCP Terraform หนัก จงถือว่านี่เป็นการตัดสินใจระดับแพลตฟอร์ม ไม่ใช่การย้าย backend โดยอัตโนมัติ OpenTofu สามารถใช้ remote backend ที่เข้ากันได้ แต่การรันจากระยะไกลเฉพาะของ HCP, Sentinel, run trigger, ข้อมูลรับรองแบบไดนามิก และ Stacks ยังคงต้องประเมินทีละฟีเจอร์ หากการควบคุมเหล่านั้นเป็นแกนหลัก ให้ทดลองก่อน หากคุณกำลังจะเลิกใช้ HCP ด้วยเหตุผลด้านใบอนุญาต ต้นทุน หรือการกำกับดูแล ให้วางแผนงานนี้เป็นการย้ายระบบระดับแพลตฟอร์ม

การพิจารณา Pulumi หรือทางเลือกอื่นที่ไม่ใช่ HCL OpenTofu คือเส้นทางที่ใกล้ที่สุดหากคุณต้องการรักษา HCL และเวิร์กโฟลว์เดิมส่วนใหญ่ไว้ ส่วน Pulumi เป็นทางเลือกแพลตฟอร์มและภาษาที่กว้างกว่า ได้แก่ TypeScript, Python, Go หรือ .NET ที่ขับเคลื่อน cloud API การย้ายไปทางนั้นอาจต้องแปลงหรือเขียนใหม่ ดังนั้นให้ประเมินแยกต่างหากจากการเปลี่ยนไบนารีจาก Terraform เป็น OpenTofu

มีอีกเรื่องหนึ่งที่ควรพูดถึงตรงๆ นั่นคือคำวิจารณ์ที่ชอบธรรมว่า OpenTofu เป็นการป้องกันความเสี่ยงให้ผู้ให้บริการ SaaS บางส่วน กระทู้ Hacker News เกี่ยวกับการเปลี่ยนแปลง BSL ได้จุดประเด็นความกังวลว่าสมาชิกผู้ก่อตั้งโครงการเป็นแพลตฟอร์ม Terraform เชิงพาณิชย์ที่มีแรงจูงใจด้านความยืดหยุ่นของใบอนุญาตของตัวเอง ผมให้ความสำคัญกับความกังวลนี้อย่างจริงจัง สิ่งที่ช่วยบรรเทาคือโครงสร้างการกำกับดูแล การโฮสต์โดย Linux Foundation สถานะ CNCF Sandbox และ MPL 2.0 บนทุกไฟล์ ซึ่งทำให้การเปลี่ยนใบอนุญาตในอนาคตยากกว่าตอนที่เป็นผู้ให้บริการรายเดียวมาก มันไม่ได้ทำให้เป็นไปไม่ได้ แต่ทำให้มีต้นทุนสูงพอที่จะเป็นการตรวจสอบถ่วงดุลที่แท้จริง

บทสรุปโดยย่อ สำหรับงาน IaC ใหม่ในปี 2026 ให้เริ่มด้วย OpenTofu ใบอนุญาต การกำกับดูแล การพัฒนาที่กระตือรือร้น และชุดฟีเจอร์ของมันทำให้เป็นตัวเลือกเริ่มต้นที่แข็งแกร่ง สำหรับการใช้งาน Terraform ที่มีอยู่แล้ว ให้เปลี่ยนเมื่อตัวกระตุ้นสามอย่างข้างต้นอย่างใดอย่างหนึ่งตรงกับสถานการณ์ นอกเหนือจากนั้นความคุ้มค่าถือว่าน้อยและการอยู่ต่อไปก็ไม่มีปัญหา

เมื่อการเลือกเครื่องมือชัดเจนแล้ว คำถามเชิงปฏิบัติต่อไปคือควรรัน OpenTofu ที่ไหน การตัดสินใจนี้ส่งผลต่อการจัดการความลับ ต้นทุน ความสามารถในการทำซ้ำ และการควบคุมสภาพแวดล้อมการทำงานของทีมคุณ

การรัน OpenTofu ด้วยตัวเอง

OpenTofu เป็นไบนารีแบบ CLI สถานที่ที่คุณรันมันกำหนดต้นทุน ความปลอดภัย และสิ่งที่คุณทำได้กับมันอย่างมาก มีสถานที่ที่สมเหตุสมผลอยู่ราวสามแห่งในการวางมันไว้

แล็ปท็อปหรือเครื่องพัฒนา เหมาะสำหรับแผนแบบครั้งเดียว การสร้างต้นแบบ และโปรเจกต์ส่วนตัวขนาดเล็ก แต่เป็นค่าเริ่มต้นที่ไม่ดีสำหรับเวิร์กโฟลว์การผลิตที่ใช้ร่วมกัน เว้นแต่จะมีการบังคับใช้ state ระยะไกล การล็อก และวินัยการทบทวนอยู่แล้ว ทีมมักได้ประโยชน์จากสภาพแวดล้อมการรันแบบมาตรฐานมากกว่าที่จะพึ่งพาแล็ปท็อปเครื่องล่าสุดที่รัน tofu apply.

CI runner แบบมีผู้ดูแล (GitHub Actions, GitLab CI ฯลฯ) เส้นทางทั่วไป opentofu/setup-opentofu action เป็นตัวแทนที่ใช้แทนกันได้ทันทีสำหรับ hashicorp/setup-terraform ซึ่งใช้งานได้ดีสำหรับทีมและโปรเจกต์ส่วนใหญ่ ข้อแลกเปลี่ยน ความลับต้องผ่านบริการ CI ของบุคคลที่สาม นาทีของแผนฟรีอาจหมดลงในการดำเนินการ state ขนาดใหญ่ และสภาพแวดล้อมของ runner เป็นแบบชั่วคราว ซึ่งมักเป็นข้อดีแต่บางครั้งก็เป็นข้อจำกัด ดู GitHub vs GitLab หากคุณยังตัดสินใจไม่ได้ระหว่างตัวเลือก CI แบบโฮสต์ และ Best CI/CD Tools สำหรับภาพรวมที่กว้างขึ้น

Runner ที่โฮสต์เองบน VPS มีประโยชน์เมื่อข้อแลกเปลี่ยนของ CI แบบมีผู้ดูแลเริ่มใช้ไม่ได้ผล เช่น ความลับต้องไม่อยู่บนบริการของบุคคลที่สาม นาที CI เริ่มแพง หรือคุณต้องการแคช provider แบบถาวร การตั้งค่านั้นตรงไปตรงมา VPS ที่ใช้ Linux ไบนารี OpenTofu เอเจนต์ GitHub Actions หรือ GitLab Runner และ Docker สำหรับแยกงาน ดู Install Docker on VPS หากส่วนนั้นเป็นเรื่องใหม่สำหรับคุณ สำหรับ runner ของทีมเล็ก RAM 4 GB, vCPU 2 คอร์ และ NVMe 60 GB เป็นจุดเริ่มต้นที่สมเหตุสมผล ขยาย CPU หน่วยความจำ และพื้นที่จัดเก็บสำหรับแผนที่ใหญ่ขึ้นและการทำงานพร้อมกันที่สูงขึ้น

สำหรับทีมที่ต้องการควบคุมความลับของ runner อย่างเข้มงวดขึ้น แคช provider แบบถาวร หรือต้นทุน CI ที่คาดการณ์ได้ runner ที่โฮสต์เองบน VPS อาจสมเหตุสมผล ในการตั้งค่านั้น ให้ความสำคัญกับสิทธิ์ root การจัดเก็บ NVMe ที่รวดเร็ว การปรับขนาดที่ง่าย และ CPU/RAM ที่เพียงพอสำหรับการดำเนินการ plan ขนาดใหญ่

Cloudzy Linux VPS มีลักษณะที่เหมาะกับรูปแบบ runner ที่โฮสต์เองนี้ด้วยสิทธิ์ root การจัดเก็บ NVMe และการปรับขนาดที่ยืดหยุ่น ทำให้คุณเริ่มต้นเล็กๆ ได้และขยาย runner ตามที่ภาระงาน OpenTofu ของคุณเติบโตขึ้น

คำถามที่พบบ่อย

OpenTofu เหมือนกับ Terraform หรือไม่?

ไม่เชิง OpenTofu เริ่มต้นจากการเป็น fork ของ Terraform 1.5.x และยังคงเข้ากันได้กับการตั้งค่าแบบ HCL สไตล์ Terraform เป็นส่วนใหญ่ นั่นคือไฟล์ .tf .tf, provider เดียวกัน และ plan/apply workflow แบบ plan/apply เดียวกันสำหรับหลายโปรเจกต์ ทั้งสองแตกต่างกันในเรื่องใบอนุญาตและฟีเจอร์ที่เพิ่มเข้ามาหลังการแยกโค้ด OpenTofu มีการเข้ารหัส state ฝั่งไคลเอนต์ provider for_each, enabled และ dynamic prevent_destroy ; ส่วน Terraform ก็มีฟีเจอร์หลังการแยกโค้ดของตัวเอง รวมถึง ephemeral resources

OpenTofu จะรองรับ Terraform Provider ทั้งหมดของฉันหรือไม่?

สำหรับ provider หลักๆ เช่น AWS, GCP, Azure, Kubernetes และ Helm โดยทั่วไปแล้วใช่ OpenTofu Registry รายงานว่ามี provider มากกว่า 3,900 รายการ ณ เดือนกรกฎาคม 2026 tofu init อาจอัปเดต .terraform.lock.hcl tofu init อาจอัปเดตเมทาดาทา สำหรับ provider เฉพาะกลุ่ม เฉพาะผู้ให้บริการ หรือที่เพิ่งเผยแพร่ ให้ตรวจสอบความพร้อมใช้งานและการรองรับเวอร์ชันโดยตรงก่อนสลับ

OpenTofu เองอาจถูกเปลี่ยนใบอนุญาตในวันหนึ่งได้หรือไม่?

การเปลี่ยนใบอนุญาตในอนาคตยากกว่าที่เคยเกิดกับ Terraform แต่ไม่ใช่ว่าเป็นไปไม่ได้ OpenTofu อยู่ภายใต้ MPL 2.0 โฮสต์โดย Linux Foundation และเป็นโครงการ CNCF Sandbox ตั้งแต่วันที่ 23 เมษายน 2025 การกำกับดูแลเป็นแบบหลายฝ่ายและใบอนุญาตได้รับการรับรองจาก OSI การเปลี่ยนใบอนุญาตฝ่ายเดียวโดยผู้ก่อตั้งคนใดคนหนึ่งจะขัดแย้งทั้งกับกฎบัตรของมูลนิธิและการสนับสนุนภายใต้ MPL 2.0 ที่มีอยู่ ซึ่งจะต้องถูกลบหรือเขียนใหม่ ความกังวลนี้ชอบธรรม อุปสรรคเชิงโครงสร้างมีอยู่จริง

การที่ IBM เข้าซื้อ HashiCorp หมายความว่าอย่างไรต่ออนาคตของ Terraform?

IBM เสร็จสิ้นการเข้าซื้อกิจการ HashiCorp เมื่อวันที่ 27 กุมภาพันธ์ 2025 มูลค่า 6.4 พันล้านดอลลาร์ แผนงานของ Terraform ตอนนี้อยู่ภายในผู้ให้บริการองค์กรที่ใหญ่กว่า การเข้าซื้อกิจการเพียงอย่างเดียวไม่ได้พิสูจน์ทิศทางใบอนุญาตหรือผลิตภัณฑ์ในอนาคต ให้ประเมินบันทึกการเปลี่ยนแปลงปัจจุบัน แนวทางใบอนุญาต และการเปลี่ยนแปลงผลิตภัณฑ์ HCP แทนที่จะมองความเป็นเจ้าของเป็นการทำนาย

OpenTofu พร้อมใช้งานจริงในปี 2026 หรือไม่?

ใช่ v1.12.5 คือรุ่นบำรุงรักษาปัจจุบัน โครงการนี้อยู่ใน CNCF Sandbox และ Fidelity ได้อธิบายการนำไปใช้งานจริงทั่วทั้งระบบ IaC ที่มีไฟล์ state มากกว่า 50,000 ไฟล์และทรัพยากรสี่ล้านรายการ พร้อมใช้งานจริงไม่ได้แปลว่ามีฟีเจอร์เหมือนกันทุกประการ ทีมที่พึ่งพาความสามารถเฉพาะของ HCP เช่น Terraform Stacks ยังคงต้องตัดสินใจเรื่องความเข้ากันได้แยกต่างหาก