Terraform Data Sources — Đọc Infrastructure thay vì tạo mới

Ở bài trước, chúng ta đã tìm hiểu về Terraform Modules và cách chia Infrastructure thành những thành phần nhỏ có thể tái sử dụng.

Tuy nhiên, trong thực tế, không phải toàn bộ Infrastructure đều do Terraform tạo ra.

Rất nhiều hệ thống đã tồn tại từ trước.

Ví dụ:

• VPC được platform team quản lý.
• Database được DBA tạo thủ công.
• Kubernetes Cluster được provision bởi EKS Blueprint.
• DNS Zone đã tồn tại nhiều năm.
• AWS Account có sẵn hàng trăm resource.

Nếu Terraform chỉ biết tạo mới thì gần như không thể áp dụng vào các hệ thống lớn.

Đó là lý do Data Sources ra đời.

Terraform không chỉ biết tạo Resource

Khi mới học Terraform, chúng ta thường nghĩ workflow sẽ như sau:

Terraform
      ↓
Create Resource

Nhưng trên thực tế Terraform còn có một khả năng khác rất quan trọng:

Terraform
      ↓
Read Existing Infrastructure
      ↓
Use Information
      ↓
Create New Infrastructure

Nói cách khác:

Terraform không chỉ tạo Infrastructure.

Terraform còn có thể đọc Infrastructure đã tồn tại.

Đó chính là nhiệm vụ của Data Sources.

Resource và Data Source khác nhau như thế nào?

Terraform có hai khái niệm rất dễ bị nhầm:

Resource

Resource dùng để quản lý vòng đời của Infrastructure.

Ví dụ:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

Terraform sẽ:

• tạo
• cập nhật
• xoá

resource này khi cần.

Terraform chịu trách nhiệm hoàn toàn cho lifecycle của resource.

Data Source

Data Source chỉ có nhiệm vụ:

Đọc thông tin.

Ví dụ:

data "aws_vpc" "main" {
  default = true
}

Terraform sẽ:

• gọi AWS API
• tìm Default VPC
• đọc toàn bộ thông tin
• lưu kết quả trong Memory

Terraform không tạo VPC.

Terraform không sửa VPC.

Terraform không xoá VPC.

Chỉ đọc.

Một cách hình dung rất đơn giản

Hãy tưởng tượng Terraform giống như một nhân viên văn phòng.

Có hai hành động khác nhau.

Resource

"Tạo một nhân viên mới."

Terraform sẽ:

• tạo hồ sơ
• quản lý
• cập nhật
• xoá

Data Source

"Tìm nhân viên tên John trong công ty."

Terraform chỉ mở database.

Đọc thông tin.

Sau đó dùng thông tin đó cho các công việc khác.

Không thay đổi gì cả.

Cú pháp của Data Source

Cấu trúc gần giống Resource.

data "<provider>_<type>" "<name>" {
 
}

Ví dụ:

data "aws_availability_zones" "available" {}

Hoặc:

data "aws_caller_identity" "current" {}

Hoặc:

data "aws_region" "current" {}

Hay:

data "aws_vpc" "main" {
  default = true
}

Sau khi đọc xong, Terraform sẽ expose các thuộc tính tương tự Resource.

Ví dụ:

data.aws_vpc.main.id

Hoặc

data.aws_region.current.name

Data Sources hoạt động khi nào?

Workflow của Terraform sẽ trở thành:

Configuration
      ↓
Read Data Sources
      ↓
Refresh Resources
      ↓
Build Execution Plan
      ↓
Apply

Điểm khác biệt quan trọng là:

Terraform luôn đọc Data Sources trước khi lập Execution Plan.

Điều này giúp Plan luôn sử dụng thông tin mới nhất từ Cloud Provider.

Ví dụ thực tế

Giả sử công ty đã có sẵn VPC.

Bạn chỉ cần tạo EC2.

Không nên tạo lại VPC.

Thay vào đó:

data "aws_vpc" "main" {
  tags = {
    Name = "production-vpc"
  }
}

Sau đó:

resource "aws_security_group" "web" {
  vpc_id = data.aws_vpc.main.id
}

Tiếp theo:

resource "aws_instance" "web" {
  subnet_id = data.aws_subnets.private.ids[0]
}

Terraform sẽ:

Read Existing VPC
        ↓
Read Existing Subnets
        ↓
Create Security Group
        ↓
Create EC2

Không có tài nguyên nào bị tạo lại.

Một ví dụ khác

AWS Account hiện tại là account nào?

Terraform có thể đọc bằng:

data "aws_caller_identity" "current" {}

Sau đó:

output "account_id" {
  value = data.aws_caller_identity.current.account_id
}

Hoặc:

output "user_id" {
  value = data.aws_caller_identity.current.user_id
}

Đây là Data Source được sử dụng rất nhiều trong Terraform Module.

Lấy Region hiện tại

Terraform cũng có thể đọc Region đang sử dụng.

data "aws_region" "current" {}

Sau đó:

output "region" {
  value = data.aws_region.current.name
}

Không cần hard-code:

ap-southeast-1

Module sẽ trở nên linh hoạt hơn rất nhiều.

Lấy Availability Zones

Một ví dụ cực kỳ phổ biến.

data "aws_availability_zones" "available" {}

Sau đó:

resource "aws_subnet" "private" {
  availability_zone = data.aws_availability_zones.available.names[0]
}

Terraform luôn lấy AZ mới nhất.

Không cần hard-code:

ap-southeast-1a

Điều này giúp module hoạt động ở mọi Region.

Kết hợp Resource và Data Source

Đây là mô hình phổ biến nhất.

                Existing Infrastructure

                  VPC
                  Subnet
                  Route Table
                  Hosted Zone

                        │
                        ▼

                 Terraform Data Sources

                        │
                        ▼

                Terraform Resources

                  EC2
                  ECS
                  RDS
                  Lambda

Infrastructure cũ được đọc bằng Data Sources.

Infrastructure mới được tạo bằng Resources.

Hai phần phối hợp với nhau để tạo thành toàn bộ hệ thống.

Data Sources có nằm trong Terraform State không?

Đây là câu hỏi rất nhiều người mới thắc mắc.

Câu trả lời là:

Có.

Nhưng khác với Resource.

Terraform lưu kết quả đọc được vào State để sử dụng trong lần Apply hiện tại.

Tuy nhiên Terraform không quản lý lifecycle của Data Source.

Nếu Infrastructure thay đổi, Terraform sẽ đọc lại ở lần Plan tiếp theo.

Những lỗi phổ biến

1. Dùng Data Source để tạo Resource

Ví dụ:

data "aws_vpc" "main" {
    cidr_block = "10.0.0.0/16"
}

Nhiều người nghĩ Terraform sẽ tạo VPC.

Không.

Terraform sẽ đi tìm VPC có CIDR này.

Nếu không tìm thấy:

No matching VPC found

2. Hard-code ID

Ví dụ:

vpc_id = "vpc-123456"

Điều này khiến module rất khó tái sử dụng.

Tốt hơn:

vpc_id = data.aws_vpc.main.id

3. Đọc quá nhiều Data Sources

Mỗi Data Source đều gọi API.

Nếu project có hàng trăm Data Source:

Terraform Plan
      ↓
500 API Calls

Execution Plan sẽ chậm hơn đáng kể.

Chỉ nên đọc những gì thực sự cần.

Best Practices

• Chỉ dùng Data Source để đọc Infrastructure đã tồn tại.
• Không hard-code Resource ID nếu có thể truy vấn được.
• Kết hợp Resource và Data Source thay vì cố gắng quản lý toàn bộ Infrastructure trong một project.
• Đặt tên Data Source rõ ràng (current, main, default, production...).
• Tránh tạo quá nhiều Data Source không cần thiết vì mỗi Data Source đều cần gọi API tới Cloud Provider.

Tổng kết

Data Sources là một trong những tính năng quan trọng nhất của Terraform.

Nếu Resources giúp Terraform tạo và quản lý Infrastructure, thì Data Sources giúp Terraform hiểu Infrastructure đã tồn tại.

Trong các dự án thực tế, gần như mọi Terraform project đều sử dụng kết hợp cả hai.

Bạn sẽ rất hiếm khi gặp một hệ thống mà Terraform tạo mọi thứ từ đầu.

Thay vào đó, Terraform thường phải đọc rất nhiều thông tin từ hạ tầng hiện có rồi mới tiếp tục tạo các tài nguyên mới.

Đó cũng là lý do Data Sources trở thành một phần không thể thiếu trong Terraform.

Ở bài tiếp theo

Đến đây chúng ta đã hiểu:

• Terraform Configuration
• Terraform State
• Terraform Modules
• Terraform Data Sources

Nhưng vẫn còn một khái niệm cực kỳ quan trọng mà hầu hết người mới đều chưa hiểu đúng:

Terraform Variables hoạt động như thế nào?

Rất nhiều người xem Variables chỉ là nơi lưu các giá trị như:

• Region
• Instance Type
• Environment

Nhưng thực tế Variables còn là nền tảng để xây dựng những Terraform Module có thể tái sử dụng, mở rộng và triển khai ở nhiều môi trường khác nhau.

Ở bài tiếp theo, chúng ta sẽ tìm hiểu toàn bộ về Terraform Variables, từ cách hoạt động, phạm vi, thứ tự ưu tiên cho đến những best practices được sử dụng trong các dự án thực tế.