18-Terraform Cloud – Cộng tác và quản lý hạ tầng ở tầm team

Khi làm việc một mình, Terraform CLI chạy local là đủ. Nhưng khi cả team cùng quản lý hạ tầng, bạn cần một nơi tập trung để lưu State, kiểm soát quyền, và đảm bảo không ai apply lung tung. Terraform Cloud giải quyết đúng những vấn đề đó.

Terraform Cloud và CLI

Terraform Cloud không thay thế CLI — nó mở rộng CLI. Bạn vẫn viết file .tf như bình thường, vẫn dùng terraform plan và terraform apply, nhưng thay vì chạy local thì các thao tác đó được thực thi và quản lý tập trung trên Terraform Cloud.

Nói cách khác: CLI là công cụ bạn dùng hàng ngày, còn Terraform Cloud là platform đứng phía sau — lưu State, chạy plan/apply, quản lý variable, kiểm soát policy.

Workspace trong Terraform Cloud

Đây là điểm dễ nhầm nhất. Workspace trong Terraform Cloud khác hoàn toàn với terraform workspace của CLI:

Mỗi workspace trên Terraform Cloud có State riêng, variable riêng, run history riêng, và có thể liên kết với VCS repo riêng.

Naming convention cho workspace theo dạng a-b-c, ví dụ:

myapp-dev-us-east
myapp-staging-us-east
myapp-prod-eu-west

Authentication

Để kết nối CLI với Terraform Cloud:

terraform login

Lệnh này mở trình duyệt, redirect đến app.terraform.io để lấy API Token, sau đó lưu token vào local tại ~/.terraform.d/credentials.tfrc.json. Từ đó CLI có thể tương tác với Terraform Cloud mà không cần nhập credential thủ công mỗi lần.

Để ngắt kết nối:

terraform logout

Secure Variables

Thay vì lưu variable trong file .tfvars hay hardcode trong code, Terraform Cloud cho phép quản lý variable trực tiếp trên platform. Có hai loại variable:

Với các thông tin nhạy cảm như API key hay secret, bật chế độ Sensitive — giá trị sẽ bị ẩn hoàn toàn, không hiển thị trong log, UI, hay API response. Một khi đã set sensitive thì không thể đọc lại giá trị, chỉ có thể ghi đè.

Version Control

Terraform Cloud tích hợp với các VCS phổ biến:

• GitHub / GitHub Enterprise
• GitLab / GitLab EE
• Bitbucket Cloud / Bitbucket Server
• Azure DevOps

Mục đích chính là để nhiều người cùng làm việc trên một codebase mà vẫn có single source of truth duy nhất. Khi liên kết workspace với VCS repo:

• Push code lên branch được chỉ định → tự động trigger terraform plan
• Merge pull request → tự động trigger terraform apply
• Không cần ai phải chạy lệnh thủ công

Quan trọng: Workspace đã liên kết VCS thì không được phép chạy terraform apply bằng CLI hay bất kỳ phương thức nào khác ngoài VCS workflow. terraform plan vẫn chạy được. Đây là cơ chế đảm bảo không ai apply “ngoài luồng”.

Ngoài ra, nhiều workspace như dev, staging, prod có thể liên kết và dùng chung một codebase từ cùng một VCS repo — chỉ khác nhau ở variable và State.

Private Registry

Nơi lưu trữ và versioning các Terraform module nội bộ để tái sử dụng trong team, tương tự như public Terraform Registry nhưng chỉ dành cho tổ chức của bạn.

Có hai cách thêm module vào Private Registry:

1. Publish trực tiếp từ VCS repo — repo phải đặt tên theo format bắt buộc:

terraform-<PROVIDER>-<NAME>

Ví dụ:

terraform-aws-vpc
terraform-aws-eks
terraform-gcp-gke

Terraform Cloud sẽ tự động detect các tag version (theo semver v1.0.0, v1.1.0…) và hiển thị trong registry.

2. Publish thủ công — upload module package trực tiếp qua API, không cần VCS.

Sau khi publish, các team khác trong cùng organization có thể dùng module này như bình thường:

module "vpc" {
  source  = "app.terraform.io/<ORG_NAME>/vpc/aws"
  version = "1.0.0"
}

Sentinel Policy

Sentinel là cơ chế Policy-as-Code của Terraform Cloud — cho phép bạn viết policy kiểm soát những gì được phép deploy, tương tự như “code review tự động cho hạ tầng”.

Policy được đánh giá theo thứ tự:

terraform plan  →  Cost Estimation  →  Sentinel Policy  →  terraform apply

Tức là Sentinel chạy sau khi plan và cost estimation hoàn thành, trước khi apply — đây là vị trí lý tưởng để chặn những thay đổi không hợp lệ trước khi chúng được áp dụng thật.

Có 3 enforcement level:

Ví dụ một số policy thực tế hay gặp:

• Tất cả resource phải có tag Owner và Environment
• Không cho phép tạo instance type lớn hơn t3.medium ở môi trường dev
• S3 bucket không được phép có acl = "public-read"
• Chỉ được dùng AMI từ danh sách đã được approve

Agents

Terraform Cloud Agent giải quyết một vấn đề thực tế: Terraform Cloud là SaaS chạy trên internet, nhưng hạ tầng của bạn có thể nằm trong private network hoặc on-premises mà Terraform Cloud không thể kết nối trực tiếp vào.

Agent là một process chạy bên trong network của bạn, làm cầu nối giữa Terraform Cloud và hạ tầng private:

Terraform Cloud
      ↓  gửi plan
   Agent (chạy trong private network)
      ↓  thực thi
   Private Infrastructure

Luồng hoạt động cụ thể:

1. Terraform Cloud tạo plan và đẩy xuống Agent
2. Agent nhận plan, chạy local trong network của bạn
3. Agent apply changes trực tiếp lên private infrastructure
4. Kết quả được gửi ngược lại Terraform Cloud để lưu log và cập nhật State

Agent đặc biệt hữu ích khi bạn dùng Terraform để quản lý hạ tầng on-premises như VMware vSphere, hoặc các resource trong VPC không có public endpoint.

Tóm lại

Các điểm quan trọng cần nhớ — đặc biệt cho kỳ thi Terraform Associate:

• Workspace trong Terraform Cloud ≠ terraform workspace CLI — đây là working directory độc lập hoàn toàn
• Sentinel Policy nằm giữa plan và apply, có 3 level: Advisory → Soft Mandatory → Hard Mandatory
• VCS-linked workspace bắt buộc dùng VCS-driven workflow, không apply bằng CLI
• Private Registry yêu cầu format tên repo terraform-<PROVIDER>-<NAME>
• Agent dùng khi cần quản lý private/on-premises infrastructure từ Terraform Cloud

Bài viết thuộc series Terraform Associate Certification trên ttnguyen.net.