Terraform Cloud: จัดการ Infrastructure ผ่าน Web UI แบบ SaaS

Categories

Terraform Cloud (TFC) คือบริการจัดการ Infrastructure as Code ของ HashiCorp ที่ทำงานผ่าน web UI ยกภาระการตั้งค่า CI runner, remote state backend, policy engine ออกจากทีมให้ไปอยู่บน SaaS แทน เหมาะสำหรับองค์กรที่ไม่อยากสร้าง pipeline เองและต้องการ UI กลางให้ทีมมองเห็น workspace, plan, apply, notification, cost, policy ทั้งหมดในที่เดียว

บทความนี้อธิบายส่วนประกอบหลักของ Terraform Cloud ตั้งแต่ organization, workspace, VCS integration, run workflow, variable/secret management, policy (Sentinel/OPA), private module registry, cost estimation และ notification พร้อมแนวทางเลือกใช้ระหว่าง free tier, team tier และ Terraform Enterprise

โครงสร้างหลักของ Terraform Cloud

TFC แบ่งโครงสร้างเป็น 3 ชั้น ชั้นบนสุดคือ organization ซึ่งเป็นขอบเขตของบริษัทหรือทีมใหญ่ ใต้ organization มี workspace ที่เป็นหน่วยจัดการ state แต่ละชุด (1 workspace = 1 state) และใต้ workspace จะเก็บ run history, variable, policy และ notification ที่เกี่ยวกับ state นั้น

  • Organization: ระดับบริษัท จัดการ user, team, billing, policy set, VCS provider
  • Workspace: เทียบเท่า directory ใน CLI แต่มี isolated state ในระบบ TFC
  • Run: การ plan/apply แต่ละครั้ง พร้อม log, plan output, approver
  • Variable Set: กลุ่ม variable ที่ share ข้าม workspace เช่น credential AWS
  • Team: กลุ่ม user ที่มีสิทธิ์คล้ายกัน สามารถกำหนด permission ระดับ workspace ได้

การเชื่อม Terraform Cloud กับโค้ด

เขียน cloud {} ใน block terraform ของโปรเจกต์ แล้วรัน terraform login เพื่อเก็บ API token ในเครื่องครั้งเดียว หลังจากนั้นทุกครั้งที่รัน terraform init โปรเจกต์จะผูกกับ workspace ใน TFC อัตโนมัติ

terraform {
  cloud {
    organization = "my-company"

    workspaces {
      name = "prod-network"
    }
  }
}

ถ้าต้องจัดการหลาย workspace ภายใต้ project เดียวกัน ใช้ tags = ["network"] แทน name เพื่อให้ match กับ workspace ทุกตัวที่มี tag ดังกล่าว วิธีนี้ช่วยให้การเพิ่ม environment ใหม่ (dev/staging/prod) ไม่ต้องแก้ code ทุกครั้ง

Execution Mode: Remote vs Local vs Agent

TFC มี execution mode ให้เลือก 3 แบบ ส่งผลต่อว่า plan/apply จะรันที่ไหน และสำคัญมากในการออกแบบ network security ระหว่าง cloud กับ workload

  • Remote (default): plan/apply รันบน worker ของ HashiCorp เหมาะกับ cloud provider สาธารณะ (AWS, Azure, GCP)
  • Local: plan/apply รันในเครื่อง user แต่เก็บ state ใน TFC เหมาะกับช่วง migration หรือ environment ที่ต้องเรียก resource ใน VPC แต่ยังไม่พร้อมเปิด network
  • Agent: รัน worker (agent) ใน network ของเราเอง TFC orchestrate ผ่าน outbound connection เหมาะกับ environment ที่ API อยู่หลัง firewall เช่น on-premise, private cloud

VCS Integration และ Auto Plan/Apply

จุดแข็งของ TFC คือ integrate กับ GitHub, GitLab, Bitbucket, Azure DevOps ตั้งค่าครั้งเดียว workspace แต่ละตัว bind กับ branch ของ repo เมื่อมี PR จะ run plan อัตโนมัติ และเมื่อ merge เข้า main จะ apply ต่อ (หรือรอ manual approve ก่อน ขึ้นกับการตั้งค่า)

  • Speculative plan: รันตอนมี PR เพื่อโชว์ผลกระทบ ไม่บันทึก state
  • Auto-apply: ถ้า enable → apply ทันทีหลัง plan สำเร็จ เหมาะกับ dev
  • Manual apply: บังคับให้คนกด confirm ก่อน apply เหมาะกับ prod
  • Working directory: กำหนดได้ว่า workspace นี้ดู subfolder ไหนของ repo
  • Trigger patterns: เลือกว่า file หรือ path ไหนเปลี่ยนถึงจะ trigger run

Variables และ Sensitive Values

TFC จัดการตัวแปรสองประเภทคือ Terraform variable (ส่งเข้า var.xxx) และ environment variable (ส่งเป็น env var ของ worker เช่น AWS_ACCESS_KEY_ID) แต่ละตัวตั้งเป็น sensitive ได้ พอ mark แล้วจะซ่อนใน UI, ไม่ logged, ไม่แสดงใน plan output

# ตัวอย่าง variable ใน workspace
# (ตั้งผ่าน UI หรือ terraform-cloud provider)

# Terraform variable
instance_type = "t3.medium"  # ปกติ
db_password   = "xxxx"        # mark sensitive ✓

# Environment variable
AWS_ACCESS_KEY_ID     = "AKIA..."
AWS_SECRET_ACCESS_KEY = "xxxx"   # mark sensitive ✓

หลาย workspace ที่ใช้ credential ชุดเดียวกันไม่ควรตั้งแยกซ้ำ ให้ใช้ Variable Set สร้างกลุ่ม variable แล้ว attach กับ workspace ที่ต้องการ ลด duplication และทำให้การ rotate credential ทำจุดเดียวมีผลทั้งหมด

Dynamic Credentials (ไม่ต้องเก็บ Secret)

Terraform Cloud รองรับ OIDC trust กับ cloud provider ตั้งค่าครั้งเดียว workspace จะได้ short-lived token ทุกครั้งที่รัน โดยไม่ต้องเก็บ static access key ใน environment variable เลย กลายเป็น pattern ที่แนะนำสำหรับ production

  • AWS: ตั้ง variable TFC_AWS_PROVIDER_AUTH=true + TFC_AWS_RUN_ROLE_ARN
  • Azure: ใช้ workload identity federation
  • GCP: ใช้ service account impersonation ผ่าน OIDC
  • Vault: TFC สามารถขอ dynamic secret จาก Vault ตอนรันได้โดยตรง

Policy as Code: Sentinel และ OPA

Terraform Cloud มี policy engine ในตัว 2 ตัว Sentinel เป็น DSL ของ HashiCorp เอง เขียนกฎตรวจ plan ก่อน apply ถ้าไม่ผ่านจะหยุดไม่ให้ apply OPA (Open Policy Agent) ใช้ภาษา Rego มาตรฐานเปิด รองรับได้เหมือนกันแต่ต้อง Terraform Enterprise หรือ plan ระดับ Team

# ตัวอย่าง Sentinel policy: ห้ามสร้าง EC2 ที่ไม่มี tag
import "tfplan/v2" as tfplan

ec2_instances = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_instance" and rc.mode is "managed"
}

main = rule {
  all ec2_instances as _, rc {
    rc.change.after.tags is not null and
    "Environment" in keys(rc.change.after.tags)
  }
}

Policy set ผูกกับ organization หรือ workspace ได้ทั้งสองระดับ ตั้ง enforcement level เป็น advisory (เตือน), soft-mandatory (ต้อง override), hard-mandatory (ห้ามข้าม) ใช้แยกระหว่าง dev/staging/prod เพื่อให้ dev flexible แต่ prod เข้มงวด

Private Module Registry

TFC มี private registry สำหรับแชร์ module ภายในองค์กร publish จาก repo ที่มี tag ตามรูปแบบ semver (v1.2.3) แล้วทีมอื่นเรียกใช้ด้วย source path app.terraform.io/my-org/vpc/aws มี UI สำหรับดู version, variable, output, example

module "vpc" {
  source  = "app.terraform.io/my-company/vpc/aws"
  version = "~> 2.0"

  cidr = "10.0.0.0/16"
  name = "prod-vpc"
}

เหมาะสำหรับองค์กรที่อยากบังคับใช้ module กลางแทนที่จะให้แต่ละทีมเขียนเอง มาตรฐานเดียวกันทั้ง tag naming, security group pattern, logging

Cost Estimation

ฟีเจอร์ cost estimation ในตัว (Team/Business tier) แสดงราคาประมาณของ resource ที่จะถูกสร้างพร้อม delta จาก state ปัจจุบัน ช่วยให้ reviewer เห็นว่า PR นี้จะเพิ่มค่าใช้จ่ายกี่บาทก่อน approve ทำงานร่วมกับ AWS, Azure, GCP

Cost estimation จับได้แค่ resource ที่ provider ส่ง price metadata กลับมา เช่น EC2 instance type, RDS class, S3 storage class แต่ไม่รวม traffic/egress หรือ request count ใช้เป็น sanity check ได้แต่ไม่ควรยึดเป็นตัวเลข billing จริง

Notification และ Audit

Workspace ตั้ง notification ได้หลายช่องทาง Slack, Microsoft Teams, email, webhook เลือก trigger เช่น run started, plan finished, apply errored, policy failed เหมาะกับทีมที่ต้องการให้ทุกคนรู้ deploy status real-time

  • Organization audit log: เก็บทุก action ที่ user/team ทำ สำหรับ compliance
  • Workspace run log: เก็บ plan/apply output อย่างน้อย 6 เดือน
  • API audit: ทุกการเรียก API ของ TFC จะ logged ระบุ token ที่ใช้
  • SAML/SSO: รองรับ integration กับ Okta, Azure AD สำหรับ enterprise

Pricing Tier และการตัดสินใจ

ปัจจุบัน Terraform Cloud มี free tier สำหรับใช้ส่วนตัว/ทีมเล็ก (จำกัด user, resource) และ Standard/Plus tier ที่เปิด policy, cost estimation, agent, private registry, SSO ถ้าต้องการ run on-prem ต้องเลือก Terraform Enterprise (ติดตั้งใน environment เราเอง)

  • Free: เหมาะกับ side project, ทดลอง feature
  • Standard: เหมาะกับทีมขนาดเล็ก-กลาง มี collaboration + VCS + private registry
  • Plus: เพิ่ม policy, drift detection, cost estimation, SSO — เหมาะกับองค์กรที่มีหลายทีม
  • Enterprise: run on-prem, air-gap, audit เต็มรูปแบบ — สำหรับ regulated industry

ข้อควรระวังในการใช้ Terraform Cloud

  • State portability: ถ้าย้ายออก TFC ต้อง terraform state pull เก็บก่อน ไม่มี one-click export
  • Vendor lock-in: Sentinel policy, variable set ผูกกับ TFC เอา OPA ของระบบอื่นมาแทนตรงๆ ไม่ได้
  • Outage risk: ถ้า TFC ล่ม apply ใหม่ไม่ได้ (local mode พอช่วยได้แต่ sync state ลำบาก)
  • Cost growth: ตาม resource-under-management พอ infra โตขึ้นราคาจะขึ้นตาม
  • Network egress: agent/private cloud ต้อง whitelist outbound ไปหา app.terraform.io

สรุป

Terraform Cloud ลดงาน ops ของทีม DevOps อย่างชัดเจน ไม่ต้อง maintain S3 backend, DynamoDB lock, CI pipeline, policy engine เอง มาพร้อม UI กลางที่ผู้จัดการ, SRE, security team ใช้ร่วมกันได้ เหมาะกับทีมที่ต้องการ focus ที่เนื้อหา infrastructure มากกว่าการสร้าง tooling

ทางเลือกในการใช้ขึ้นกับขนาดและ requirement ถ้าเริ่มจากทีมเล็กที่อยาก test workflow → free tier พอ ถ้าต้อง policy และ SSO → upgrade เป็น Plus เมื่อขนาดโต ถ้าต้องการ run ใน air-gap network หรือ datacenter เอง ต้องใช้ Terraform Enterprise ซึ่งเป็น feature เดียวกันแต่ติดตั้งเอง หลักการสำคัญคือเลือกตาม compliance + network constraint ก่อน แล้วค่อยดู feature เพิ่มเติม