Terraform Enterprise (TFE) คือเวอร์ชัน self-hosted ของ Terraform Cloud ที่องค์กรสามารถติดตั้งบนโครงสร้างพื้นฐานของตนเอง ไม่ว่าจะเป็น data center ภายในบริษัท หรือ cloud account ที่ควบคุมเอง เหมาะสำหรับองค์กรที่มีข้อกำหนดด้าน compliance เข้มงวด เช่น ต้องเก็บข้อมูล state file ไว้ในประเทศ (data residency) หรือทำงานในสภาพ air-gap ที่ไม่มีการเชื่อมต่ออินเทอร์เน็ต

บทความนี้อธิบายความแตกต่างระหว่าง TFE กับ Terraform Cloud (TFC), รูปแบบการติดตั้ง, ข้อกำหนดทางเทคนิค, licensing และแนวทางการดูแลรักษา เพื่อให้ผู้ดูแลระบบสามารถประเมินและวางแผน deploy ได้อย่างถูกต้อง

TFE ต่างจาก Terraform Cloud อย่างไร

ทั้งสองผลิตภัณฑ์ใช้ engine เดียวกันและ feature หลักเหมือนกัน (workspace, run, policy, private registry) แต่ต่างกันที่การ host และระดับการควบคุม

ประเด็น	Terraform Cloud (SaaS)	Terraform Enterprise (TFE)
การ host	HashiCorp บริหาร	องค์กรติดตั้งเอง
Data residency	US / EU (ตามภูมิภาคของ HashiCorp)	ควบคุมเองเต็มที่
Air-gap	ไม่รองรับ	รองรับ
SSO	SAML (ใน Plus tier)	SAML รวมในทุก license
Upgrade	อัตโนมัติ	ผู้ดูแลติดตั้งเอง
Cost	Subscription รายเดือน	License + infra cost

TFE เหมาะสำหรับบริษัทที่ต้องทำงานภายใต้กฎหมาย เช่น PDPA, HIPAA, GDPR ที่กำหนดให้ข้อมูลต้องอยู่ในประเทศ หรือองค์กรทางการเงิน การทหาร ที่ระบบภายในต้องแยกออกจาก public internet

รูปแบบการติดตั้ง

TFE รุ่นปัจจุบันใช้ Kubernetes เป็น runtime หลัก (หรือ Docker ในบางสถาปัตยกรรม) มีสองโหมดใหญ่ที่เลือกได้

Mounted disk / Standalone mode

เหมาะสำหรับการทดสอบหรือทีมขนาดเล็ก ข้อมูลทั้งหมดอยู่ในดิสก์ของ node เดียว รวมทั้ง PostgreSQL, object storage และ Redis ติดตั้งง่ายแต่ไม่มี HA และ backup ต้อง snapshot ทั้งเครื่อง เหมาะกับ workload ต่ำกว่า 10 run พร้อมกัน

External services mode (แนะนำสำหรับ production)

แยก data store ออกเป็น service ภายนอก เพื่อรองรับ HA และ scale ได้ กำหนดคอมโพเนนต์ดังนี้

• PostgreSQL 14+ สำหรับ metadata (workspace, run, user)
• Object storage: S3, Azure Blob, GCS หรือ MinIO สำหรับเก็บ state file และ plan artifact
• Redis (optional) สำหรับ caching และ queue
• TLS certificate จาก internal CA หรือ Let’s Encrypt
• SMTP server สำหรับแจ้งเตือนและส่งอีเมลเชิญผู้ใช้

การแยก PostgreSQL และ object storage ออกมาช่วยให้ backup/restore ทำงานแยกจาก application layer และสามารถ scale application pod ได้ตามโหลด

ข้อกำหนดขั้นต่ำ

สำหรับ production deployment ขนาดกลาง (10-50 concurrent run)

• Application node: 4 vCPU, 16 GB RAM ขึ้นไป ต่อ node (แนะนำ 3 node สำหรับ HA)
• PostgreSQL: 4 vCPU, 16 GB RAM, SSD 200 GB+
• Object storage: อย่างน้อย 500 GB เผื่อ log และ plan artifact
• Network: low-latency ระหว่าง app และ database (<5ms)
• OS: RHEL 8/9, Ubuntu 22.04 LTS หรือ Kubernetes cluster 1.27+

การติดตั้งแบบ Air-gap

Air-gap คือสภาพแวดล้อมที่ระบบไม่สามารถเข้าถึงอินเทอร์เน็ตได้ พบบ่อยในหน่วยงานราชการ ธนาคาร หรือโรงงานอุตสาหกรรม TFE รองรับ air-gap ผ่านการเตรียม package ล่วงหน้า

• ดาวน์โหลด installation bundle (.airgap file) จากเครื่องที่ online
• ย้ายไฟล์เข้าไปยัง environment air-gap ผ่าน USB หรือ approved transfer
• ติดตั้งผ่าน installer ที่มาพร้อม bundle โดยไม่ต้อง pull image จาก registry ภายนอก
• Provider plugin ต้องเตรียม mirror ไว้ใน private registry (เช่น Artifactory, Nexus)

ขั้นตอน upgrade ใน air-gap ต้องดาวน์โหลด bundle รุ่นใหม่ทุกครั้งและ apply ตามลำดับ ห้ามข้าม major version เพราะ schema migration ไม่รองรับ

สถาปัตยกรรมเครือข่าย

โครงสร้างมาตรฐานสำหรับ TFE production

[User/VCS Webhook]
       ↓
[Load Balancer HTTPS 443]
       ↓
[TFE Application Pods × 3] ← PostgreSQL (HA)
       ↓                    ← Object Storage (S3/Blob)
[VCS Integration]           ← Vault / Secrets Manager
[Cloud Provider APIs]       ← SMTP
       ↓
[Agent Pools (optional)] — สำหรับ reach private network

Load balancer ต้องรองรับ WebSocket เพราะ log streaming ของ run ใช้ WebSocket connection ส่วน DNS ต้อง resolve hostname ของ TFE ไปยัง virtual IP ของ LB

Licensing

TFE ใช้ license key แบบ subscription คิดตามจำนวน workspace หรือ resource under management (RUM) โดยติดต่อ HashiCorp sales เพื่อขอใบเสนอราคา ไม่มีแพลน community free สำหรับ TFE การใช้งานเชิง production ต้องมี license ที่ยังไม่หมดอายุ หาก expire ระบบจะไม่ปล่อยให้สร้าง run ใหม่ แต่จะยังอ่าน state เดิมได้

การสำรองข้อมูล (Backup)

External services mode สามารถ backup ได้หลาย layer

• PostgreSQL: pg_dump รายวัน หรือ continuous archiving (WAL) ไปยัง object storage
• Object storage: เปิด versioning + cross-region replication
• Application config: export ผ่าน snapshot API ที่ TFE เตรียมไว้
• TLS certificate และ license key: เก็บใน secret vault แยก

ทดสอบ restore อย่างน้อยไตรมาสละครั้ง ให้มั่นใจว่า runbook ใช้งานได้จริง พร้อม document หมายเลข workspace/run ล่าสุดก่อน restore เพื่อตรวจ integrity

Upgrade Strategy

TFE ออกรุ่นใหม่ประมาณเดือนละครั้ง แนวทาง upgrade ที่ปลอดภัย

• อ่าน release notes เพื่อดู breaking change และ migration step
• Backup PostgreSQL และ object storage ก่อน upgrade เสมอ
• ทดสอบใน staging cluster ที่ mirror production ก่อน rollout จริง
• ใช้ blue/green: install รุ่นใหม่บน cluster สำรอง แล้วสลับ DNS
• ห้ามข้าม major version (เช่น v202310 → v202402 ต้อง upgrade ผ่านรุ่นกลาง)

SSO และการจัดการผู้ใช้

TFE รองรับ SAML 2.0 มาตั้งแต่ tier พื้นฐาน เชื่อมกับ identity provider ได้หลากหลาย

• Okta / Auth0 สำหรับ SaaS IdP
• Active Directory Federation Services (ADFS) สำหรับ on-premise AD
• Azure AD / Entra ID สำหรับองค์กรที่ใช้ Microsoft 365
• Keycloak สำหรับ open-source IdP

Mapping SAML attribute เช่น group ของผู้ใช้ → team ของ TFE ช่วยให้จัดการสิทธิ์รวมศูนย์ผ่าน IdP ได้ ไม่ต้องสร้าง team ใน TFE ด้วยมือ

Monitoring และ Audit Log

TFE export metric ผ่าน Prometheus endpoint และ audit log ผ่าน syslog ช่วยให้ผูกเข้ากับ observability stack ที่ใช้อยู่ได้ เช่น

• Prometheus + Grafana สำหรับดู run rate, queue depth, error rate
• Splunk / Elastic / Loki สำหรับ audit log (login, plan, apply, policy override)
• PagerDuty / Opsgenie สำหรับ alert เมื่อ pod crash หรือ PostgreSQL down

Audit log สำคัญต่อการ compliance สามารถระบุได้ว่าใครสั่ง apply run ไหน ด้วย commit hash อะไร เมื่อใด ซึ่งใช้ตอบคำถาม auditor ในงาน ISO 27001 หรือ SOC 2 ได้

เมื่อไหร่ควรเลือก TFE แทน TFC

ตัดสินใจเลือก TFE เมื่อเข้าเงื่อนไขต่อไปนี้

• กฎหมายหรือ compliance บังคับว่า state file และ metadata ต้องอยู่ในประเทศ
• ระบบ production อยู่ใน air-gap ไม่มี egress ออก public internet
• ต้องการ integrate กับ internal PKI, internal Vault หรือ enterprise IAM อย่างลึก
• Data volume สูงมาก (ค่า egress ของ TFC จะสูงกว่า self-host ระยะยาว)
• มีทีม SRE/platform ที่สามารถดูแล Kubernetes, PostgreSQL, object storage ได้

ถ้าไม่มีข้อกำหนดข้างต้น TFC (SaaS) จะคุ้มค่ากว่าเพราะไม่ต้องแบกภาระ operation เอง และได้ feature ใหม่ทันทีเมื่อ HashiCorp ปล่อยอัปเดต

ข้อควรระวัง

• อย่าแชร์ PostgreSQL instance กับแอปอื่น เพราะ connection pool ของ TFE จะกินจำนวนมาก
• TLS certificate ต้อง renew ก่อนหมดอายุ ถ้า cert expire จะ login ไม่ได้ทั้งระบบ
• Object storage ที่เก็บ state file ต้องเปิด encryption at rest และจำกัด access policy ให้แคบที่สุด
• ระวังเรื่อง disk usage ของ plan artifact เพราะค่า default เก็บไม่จำกัด ควรตั้ง retention policy
• ห้ามแก้ไขข้อมูลใน PostgreSQL โดยตรงเพราะ schema มี constraint เชิง business logic ที่ไม่สามารถเดาได้

สรุป

Terraform Enterprise คือเวอร์ชัน self-hosted ที่เหมาะสำหรับองค์กรที่ต้องการควบคุมข้อมูลเต็มที่ ทำงานในสภาพ air-gap หรือมีข้อกำหนด compliance เข้มงวด เลือกโหมด external services สำหรับ production และแยก PostgreSQL, object storage, TLS certificate ให้จัดการได้อิสระ

การวางแผน upgrade แบบ blue/green, backup ที่ทดสอบ restore สม่ำเสมอ และผูก SSO เข้ากับ IdP ขององค์กรคือรากฐานสำคัญที่ทำให้ระบบ TFE ทำงานได้เสถียรระยะยาว ส่วนการตัดสินใจระหว่าง TFE กับ TFC ขึ้นอยู่กับข้อกำหนดด้าน compliance, ต้นทุนรวม และความพร้อมของทีม operation