Hướng dẫn Terraform AWS: Tự động triển khai tác nhân trên EC2

Tôi đã dành vô số giờ nhấp từng bước trong AWS Console, khởi chạy EC2 thủ công, cấu hình security group và rồi tất yếu mắc những lỗi phải mất hàng giờ để dò tìm. Nghe quen chứ? Bạn tạo instance sai availability zone, quên gắn thẻ tài nguyên, hoặc mất cả buổi chiều để dựng lại đúng cấu hình bạn làm tháng trước vì không ghi chép quy trình.

Cấp phát hạ tầng thủ công không chỉ tẻ nhạt mà còn dễ lỗi, khó mở rộng và gần như không thể kiểm toán. Đó là lúc Terraform thay đổi cuộc chơi. Hãy tưởng tượng bạn định nghĩa toàn bộ hạ tầng AWS trong các tệp văn bản có thể quản lý phiên bản, review và triển khai tự động. Không còn cảnh nhấp qua hàng chục màn hình. Không còn những cuộc trao đổi kiểu “nhưng trên máy tôi chạy được”.

Trong hướng dẫn này, tôi sẽ chỉ bạn cách tự động hóa hạ tầng AWS bằng Terraform, tập trung vào ví dụ thực tế: cấp phát một EC2 với tác nhân SSM (Systems Manager) được cài tự động khi khởi động. Kết thúc, bạn sẽ nắm được nền tảng Infrastructure as Code và có mã chạy được để triển khai ngay trên tài khoản AWS của bạn.

Nếu bạn mới làm quen AWS, hãy cân nhắc tham gia một trong các khóa học của chúng tôi như AWS Concepts, Introduction to AWS Boto in Python, hoặc AWS Security and Cost Management. 

Terraform là gì?

Terraform là công cụ mã nguồn mở cho Infrastructure as Code (IaC) do HashiCorp tạo ra, cho phép bạn định nghĩa, cấp phát và quản lý tài nguyên đám mây bằng HashiCorp Configuration Language (HCL). 

Thay vì nhấp qua các console đám mây hoặc viết script bash theo kiểu mệnh lệnh, bạn khai báo hạ tầng mong muốn trong các tệp cấu hình, và Terraform xử lý chi tiết để hiện thực hóa. Sự chuyển dịch từ cách tiếp cận mệnh lệnh sang khai báo là thay đổi căn bản trong cách chúng ta nghĩ về tài nguyên đám mây. 

Cách tiếp cận mệnh lệnh vs. khai báo khi khởi chạy một AWS EC2

Với cách mệnh lệnh, bạn viết hướng dẫn từng bước: “đầu tiên tạo security group này, rồi chờ nó tồn tại, sau đó khởi chạy instance với security group đó, rồi gắn volume này, rồi tạo các thẻ này.” Bạn phải chịu trách nhiệm về thứ tự chính xác và xử lý lỗi ở mỗi bước. 

Với cách khai báo của Terraform, bạn chỉ cần định nghĩa trạng thái cuối cùng: “Tôi muốn một EC2 với các thông số này, kết nối với security group này, có các thẻ này.” Terraform phân tích phụ thuộc, xác định thứ tự đúng và thực thi kế hoạch. Nếu có gì thất bại, Terraform biết chính xác dừng ở đâu.

Vì sao chọn Terraform cho AWS?

1. Thứ nhất, hệ sinh thái cộng đồng cực lớn, bạn sẽ tìm thấy module, ví dụ và lời giải cho hầu như mọi dịch vụ AWS có thể tưởng tượng. 
2. Thứ hai, Terraform trung lập nhà cung cấp. Học một lần, và kỹ năng, mô thức đó áp dụng được trên AWS, Azure, GCP và nền tảng khác. Tránh khóa chặt nhà cung cấp đồng thời giữ quy trình làm việc thống nhất. 
3. Thứ ba, hệ thống quản lý state của Terraform theo dõi mọi tài nguyên, khiến cập nhật và thay đổi có thể dự đoán được. Terraform biết bạn đã tạo gì và có thể sửa đổi hoặc hủy an toàn.

Trước khi đi vào cấu hình thực hành, bạn cần hiểu ba khái niệm then chốt làm nền tảng cho Terraform:

• Resource là các thành phần hạ tầng bạn tạo—EC2, S3 bucket, security group. 
• Provider là plugin cho phép Terraform tương tác với các nền tảng; AWS provider chuyển HCL của bạn thành các gọi API AWS. 
• HCL là cú pháp dễ đọc để bạn định nghĩa hạ tầng, được thiết kế vừa biểu đạt vừa đơn giản.

Nắm rõ những nền tảng này, hãy chuẩn bị môi trường để bắt đầu xây dựng hạ tầng thực tế. 

Thiết lập môi trường Terraform cho AWS

Trước khi viết bất kỳ mã Terraform nào, bạn cần cài CLI và cấu hình thông tin xác thực AWS. Tôi sẽ hướng dẫn từng bước.

Cài đặt Terraform

Cài Terraform khác nhau theo hệ điều hành:

• Trên macOS, dùng Homebrew: trước tiên thêm tap của HashiCorp với brew tap hashicorp/tap, sau đó cài Terraform bằng brew install hashicorp/tap/terraform. 

• Trên Windows, tải binary từ hashicorp.com và thêm vào PATH, hoặc dùng Chocolatey: choco install terraform. 

• Trên Linux, tải gói phù hợp hoặc dùng trình quản lý gói của bản phân phối. 

Sau khi cài, xác minh bằng cách chạy terraform version.

Cấu hình thông tin xác thực AWS

Cấu hình thông tin xác thực AWS yêu cầu một tài khoản AWS, access key và secret từ IAM. Không bao giờ dùng tài khoản root. Thay vào đó, tạo người dùng IAM có quyền truy cập theo chương trình và quyền phù hợp (AdministratorAccess). Cách chuẩn là dùng tệp thông tin xác thực AWS tại ~/.aws/credentials:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEYĐược hỗ trợ bởi

Hoặc, đặt biến môi trường: AWS_ACCESS_KEY_ID và AWS_SECRET_ACCESS_KEY. Với môi trường production, hãy dùng IAM role gắn cho EC2 hoặc hệ thống CI/CD thay vì thông tin xác thực tồn tại lâu dài.

Nếu bạn đang cân nhắc dùng hệ sinh thái khác của Amazon hoặc chỉ muốn có cái nhìn tổng quan về cách “bộ ba lớn” so sánh, tôi khuyên đọc AWS, Azure và GCP: So sánh dịch vụ cho Khoa học dữ liệu & AI.

Triển khai tác nhân EC2 với Terraform trên AWS

Khi đã có nền tảng, hãy xây dựng thứ gì đó thực tế: một EC2 tự động cài tác nhân SSM khi khởi động.

Thiết lập cấu trúc dự án

Dự án Terraform hưởng lợi từ cách tổ chức rõ ràng. Tạo ba tệp: main.tf cho định nghĩa resource, variables.tf cho input và outputs.tf cho các giá trị bạn cần sau khi triển khai. Cách tách này giúp mã có tổ chức và dễ bảo trì.

 aws-terraform
├── main.tf
├── output.tf
└── variables.tfĐược hỗ trợ bởi

Vì sao điều này quan trọng: khi dự án lớn lên, trộn mọi thứ trong một tệp sẽ không thể bảo trì. Biến cho phép bạn tái sử dụng cùng một mã cho các môi trường khác nhau (dev, staging, production) bằng cách thay đổi input. Output cung cấp các giá trị bạn cần, như ID instance hoặc địa chỉ IP, mà không phải dò tìm thủ công trong AWS Console.

Viết cấu hình resource EC2

Giờ hãy tạo hạ tầng: một EC2 với tác nhân SSM cài sẵn. Trong tệp main.tf, thêm cấu hình sau:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  owners = ["amazon"]
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
  
  iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
  
  user_data = <<-EOF
              #!/bin/bash
              cd /tmp
              sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
              sudo systemctl enable amazon-ssm-agent
              sudo systemctl start amazon-ssm-agent
              EOF
  
  tags = {
    Name = "TerraformWebServer"
  }
}

resource "aws_iam_instance_profile" "ssm_profile" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ssm_role.name
}

resource "aws_iam_role" "ssm_role" {
  name = "ec2-ssm-role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}Được hỗ trợ bởi

Cấu hình Terraform EC2 Instance

Khối data truy vấn AWS để lấy AMI Amazon Linux 2 mới nhất. Các bộ lọc đảm bảo bạn có đúng loại ảnh, và owners = ["amazon"] đảm bảo bạn dùng AMI chính thức của Amazon. Cách này hoạt động trên mọi vùng mà không cần chỉnh sửa—Terraform tự động tìm AMI khu vực phù hợp.

Phần then chốt là user_data: một script shell chạy khi instance khởi động lần đầu. Script này tải và cài tác nhân SSM, rồi bật để khởi động tự động. IAM role cung cấp quyền mà SSM cần để quản lý instance.

Mẫu này áp dụng cho bất kỳ tác nhân nào. Muốn CloudWatch cho log và metric? Chỉ cần sửa script user_data để cài CloudWatch agent. Nguyên tắc không đổi: định nghĩa những gì bạn muốn cài, và Terraform đảm bảo điều đó xảy ra trên mọi instance.

Với tệp output.tf, bạn có thể thêm, chẳng hạn, ID instance. Sau đó, khi chạy các lệnh Terraform mà tôi đề cập ở chương sau, giá trị sẽ hiển thị trên terminal.

output "instance_id" {
  description = "EC2 instance ID for SSM connection"
  value       = aws_instance.web_server.id
}Được hỗ trợ bởi

Khởi tạo và áp dụng cấu hình

Khi đã viết xong cấu hình, quy trình Terraform gồm ba lệnh. Đầu tiên, lệnh sau tải plugin AWS provider và chuẩn bị thư mục của bạn:

terraform initĐược hỗ trợ bởi

terraform init

Tiếp theo, terraform plan cho biết chính xác Terraform sẽ tạo, sửa hay xóa gì. Bản xem trước này giúp bạn bắt lỗi trước khi thay đổi thực sự:

terraform planĐược hỗ trợ bởi

terraform plan

Xem kỹ đầu ra. Bạn sẽ thấy EC2 instance, IAM role, instance profile và policy attachment mà Terraform sẽ tạo.

Cuối cùng, terraform apply thực thi các thay đổi. Terraform sẽ hỏi xác nhận trước khi tiến hành. Gõ yes sau khi chạy lệnh này:

terraform applyĐược hỗ trợ bởi

terraform apply

Nếu mọi thứ chạy ổn, bạn sẽ thấy thông báo sau khi tài nguyên đã được tạo. 

Xác nhận: Terraform đã tạo tài nguyên

Trong vài phút, bạn sẽ có một EC2 đang chạy với SSM đã cấu hình, truy cập được mà không cần SSH key. Hãy kiểm tra AWS Console để xem các tài nguyên vừa được tạo.

Quản lý Terraform State trên AWS S3

Sau khi chạy các lệnh trên, bạn sẽ thấy một tệp mới trong thư mục tên là terraform.tfstate. Tệp state của Terraform ánh xạ cấu hình của bạn với tài nguyên AWS thực. Hãy xem qua tệp này để hiểu nội dung của nó.

Tìm hiểu tệp state

Tệp state chứa mọi chi tiết về hạ tầng đã triển khai: ID tài nguyên, địa chỉ IP và phụ thuộc. Terraform so sánh state này với cấu hình của bạn và trạng thái thực tế trên AWS để quyết định hành động. Mất tệp state, Terraform sẽ mất dấu mọi thứ nó đã tạo.

Giữ state trên laptop là rủi ro. Nếu máy bạn hỏng, state biến mất. Nếu nhiều thành viên cùng làm trên cùng hạ tầng, state cục bộ xung đột dẫn đến hỏng hóc. Giải pháp: lưu trữ state từ xa.

Để đào sâu về S3 và EFS, hãy xem Hướng dẫn lưu trữ AWS.

Cấu hình backend S3 từ xa

Backend S3 của Terraform lưu state ở vị trí tập trung, bền vững và cả nhóm có thể truy cập. Trước hết, tạo một S3 bucket:

aws s3api create-bucket \
  --bucket datacamp-terraform-state \
  --region eu-central-1 \ 
   --create-bucket-configuration LocationConstraint=eu-central-1

aws s3api put-bucket-versioning \
  --bucket datacamp-terraform-state \
  --versioning-configuration Status=EnabledĐược hỗ trợ bởi

Bật versioning là tối quan trọng: nó giúp bạn khôi phục sau sự cố bằng cách quay lại phiên bản state trước đó.

Giờ, thêm cấu hình backend vào mã Terraform của bạn:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket = "datacamp-terraform-state"
    key    = "terraform.tfstate"
    region = "eu-central-1"
    use_lockfile = true
  }  
}Được hỗ trợ bởi

Chạy lại terraform init để di chuyển state cục bộ lên S3. Terraform sẽ hỏi xác nhận trước khi chuyển tệp state.

Terraform S3 remote backend

Sau khi chạy lệnh, bucket S3 sẽ chứa tệp state mới. Bạn có thể kiểm tra trong AWS Console.

Khóa state với lock file gốc của S3

Có lẽ bạn đã thấy chúng ta thêm dòng sau vào tệp main.tf: use_lockfile = true. Thiết lập này bật tính năng mới của Terraform: khóa state gốc trên S3. Trước đây, bạn cần một bảng DynamoDB riêng để khóa.

Trạng thái khóa Terraform

Sự đơn giản hóa này loại bỏ hẳn một dịch vụ AWS khỏi phần thiết lập hạ tầng của bạn trong khi vẫn đảm bảo bảo vệ khỏi tình trạng tranh chấp. Nhiều kỹ sư có thể làm việc an toàn, biết rằng tại một thời điểm chỉ có thay đổi của một người được áp dụng.

Mở rộng hạ tầng với Terraform trên AWS

Khi hạ tầng tăng trưởng, các giá trị hardcode và mã sao chép-dán trở thành cơn ác mộng bảo trì. Hệ thống biến và module của Terraform giải quyết vấn đề này.

Refactor với biến đầu vào

Trước đó, chúng ta đã tạo tệp variables.tf. Giờ bạn có thể chuyển các giá trị từng hardcode trong main.tf sang tệp mới chứa các biến này:

variable "aws_region" {
  description = "AWS region for resources"
  type        = string
  default     = "eu-central-1"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}Được hỗ trợ bởi

Giờ hãy tham chiếu biến trong resource của bạn ở tệp main.tf:

provider "aws" {
  region = var.aws_region
}

resource "aws_instance" "web_server" {
  instance_type = var.instance_type
  # ... rest of configuration
  
  tags = {
    Environment = var.environment
  }
}Được hỗ trợ bởi

Lưu ý S3 bucket của AWS là duy nhất, nên bạn không thể dùng biến cho region trong tham số backend của main.tf. Ở đây, bạn phải giữ region hardcode như “eu-central-1” thay vì var.region_aws.

Khi các biến đã được định nghĩa, bạn cũng có thể tạo môi trường khác nhau như development hoặc production, nơi các biến có thể khác. Thực hiện bằng cách tạo các tệp mới có phần mở rộng .tfvars.

Ví dụ, bạn có thể tạo terraform-dev.tfvars cho development và terraform-prod.tfvars cho production:

Development:

aws_region    = "eu-central-1"
instance_type = "t2.micro"Được hỗ trợ bởi

Production:

aws_region    = "eu-central-1"
instance_type = "t3.medium"Được hỗ trợ bởi

Sau đó, bạn có thể triển khai lên các môi trường khác nhau bằng cách chỉ định tệp phù hợp:

terraform apply -var-file="terraform-dev.tfvars”Được hỗ trợ bởi

Biến giải quyết vấn đề giá trị theo môi trường, nhưng còn việc nhân bản cả mô hình hạ tầng thì sao? Đó là lúc module trở nên thiết yếu.

Tạo module tài nguyên có thể tái sử dụng

Module đóng gói các resource liên quan thành thành phần có thể tái sử dụng. Cách tốt nhất là tạo thư mục riêng. Ví dụ, bạn có thể tạo cấu trúc như sau:

modules/
  ec2-with-ssm/
    main.tf
    variables.tf
    outputs.tfĐược hỗ trợ bởi

Bạn có thể chuyển tệp variables.tf đã tạo (hoặc tạo tệp mới) vào thư mục module. Thay đổi chính nằm ở tệp main.tf. Tệp trong module sẽ chứa các resource của chúng ta. Vì vậy, mọi thứ từ AMI đến cuối tệp sẽ được chuyển vào đó:

data "aws_ami" "amazon_linux" {
  most_recent = true
  
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  owners = ["amazon"]
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type
  
  iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
  
  user_data = <<-EOF
              #!/bin/bash
              cd /tmp
              sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
              sudo systemctl enable amazon-ssm-agent
              sudo systemctl start amazon-ssm-agent
              EOF
  
  tags = {
    Name = "TerraformWebServer"
  }
}

resource "aws_iam_instance_profile" "ssm_profile" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ssm_role.name
}

resource "aws_iam_role" "ssm_role" {
  name = "ec2-ssm-role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}Được hỗ trợ bởi

Để thay cho phần đã chuyển, bạn giữ phần còn lại của tệp nhưng thêm một tham số module tham chiếu tới module cụ thể.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket = "datacamp-terraform-state"
    key    = "terraform.tfstate"
    region = "eu-central-1"
    use_lockfile = true
  }
}

provider "aws" {
  region = var.aws_region
}

module "web_server" {
  source = "./modules/ec2-with-ssm"
  
  instance_type = var.instance_type
}Được hỗ trợ bởi

Giờ đây, nếu bạn chạy các lệnh init, plan và apply với thiết lập này, bạn sẽ triển khai cùng tài nguyên như trước. Khác biệt là module cho phép bạn khởi chạy hạ tầng với cấu hình tương tự có thể tái sử dụng. Chúng là chìa khóa để mở rộng Terraform vượt ra các dự án đơn giản.

Giờ hãy chuyển sang một chủ đề quan trọng khác: bảo mật.

Thực hành bảo mật tốt nhất cho Terraform trên AWS

Mã hạ tầng cần mức độ nghiêm ngặt về bảo mật như mã ứng dụng. Do đó, việc bảo vệ các triển khai Terraform là rất quan trọng.

Quản lý bí mật và dữ liệu nhạy cảm

Không bao giờ commit bí mật lên Git. Không bao giờ. Hãy dùng AWS Secrets Manager cho các giá trị nhạy cảm. Bạn có thể dùng resource sau trong Terraform để làm điều đó:

resource "aws_secretsmanager_secret" "example" {
  name = "example"
}Được hỗ trợ bởi

Với bí mật theo môi trường, bạn có thể dùng biến môi trường với tiền tố TF_VAR_. 

Ví dụ, bạn có thể dùng variable "aws_access_key" {} trong tệp variables.tf và export trong terminal với export TF_VAR_aws_access_key=<access_key_value>. Terraform tự động nạp chúng làm giá trị biến mà không để lộ trong mã.

Xử lý cấu hình trôi (drift)

Một chủ đề quan trọng khác là drift. Điều này xảy ra khi ai đó sửa hạ tầng qua AWS Console hoặc CLI, bỏ qua Terraform. Hãy chạy terraform plan thường xuyên để phát hiện drift. Kết quả plan hiển thị các tài nguyên tồn tại nhưng không khớp cấu hình của bạn.

Khi thấy drift, bạn có hai lựa chọn: cập nhật mã Terraform để khớp thực tế, hoặc chạy terraform apply để buộc hạ tầng quay về trạng thái mong muốn. Lựa chọn đúng tùy vào việc thay đổi thủ công đó có chủ ý hay không.

Dọn dẹp tài nguyên

Cuối cùng, việc xóa toàn bộ tài nguyên khi không cần nữa cũng quan trọng để tránh chi phí không cần thiết. Bạn có thể dọn dẹp bằng lệnh sau:

terraform destroyĐược hỗ trợ bởi

Xem kỹ kế hoạch hủy. Terraform sẽ xóa mọi tài nguyên nó đã tạo. Với production, cân nhắc dùng terraform destroy -target để xóa tài nguyên cụ thể thay vì tất cả.

Kết luận

Bạn đã học quy trình cốt lõi của Terraform: định nghĩa hạ tầng bằng mã, xem trước thay đổi với plan, áp dụng bằng apply và theo dõi mọi thứ với quản lý state. Chúng ta đã triển khai EC2 với cài đặt tác nhân tự động, chuyển state lên S3 với khóa gốc, mở rộng bằng biến và module, và bảo mật hạ tầng với quản lý bí mật.

Hãy đối xử với mã hạ tầng nghiêm ngặt như mã ứng dụng. Dùng hệ thống quản lý phiên bản, yêu cầu review mã cho các thay đổi và thử nghiệm trước ở môi trường không phải sản xuất. CI/CD có thể tự động hóa terraform apply, giúp cập nhật hạ tầng trơn tru như triển khai ứng dụng.

Bước tiếp theo của bạn: khám phá GitHub Actions hoặc GitLab CI để tự động chạy Terraform khi bạn đẩy mã. Cách tiếp cận Infrastructure as Code kết hợp tự động hóa sẽ thay đổi cách đội ngũ quản lý tài nguyên đám mây, thay thế thao tác thủ công trên console bằng hạ tầng đáng tin cậy, lặp lại được và có quản lý phiên bản.

Khuyến nghị của tôi là hãy phát triển thêm từ nền tảng này và đăng ký AWS Cloud Practitioner (CLF-C02), lộ trình kỹ năng sẽ dạy bạn mọi thứ cần biết để đạt chứng chỉ CLF-C02 của Amazon.