Terraform State — Bộ não của Terraform

Ở bài trước chúng ta đã hiểu cách Terraform hoạt động.

Terraform không đơn giản là đọc file .tf, sau đó gọi API của AWS hay Azure.

Nó luôn đi qua một quy trình:

Configuration
      ↓
Terraform State
      ↓
Refresh
      ↓
Execution Plan
      ↓
Apply

Trong toàn bộ quy trình này, Terraform State chính là thứ quan trọng nhất.

Có thể nói:

Nếu Configuration là "ý định" của chúng ta thì Terraform State chính là "trí nhớ" của Terraform.

Đây cũng là thành phần mà gần như mọi người mới học Terraform đều hiểu chưa đúng.

Terraform có cần State không?

Hãy tưởng tượng bạn có một EC2.

File Terraform:

resource "aws_instance" "web" {
  instance_type = "t3.micro"
}

Terraform Apply lần đầu.

AWS tạo ra:

EC2
ID = i-0123456789

Sau đó bạn chạy lại:

terraform plan

Một câu hỏi xuất hiện.

Terraform làm sao biết:

• EC2 này đã tồn tại?
• EC2 nào là của resource này?
• ID của EC2 là gì?
• IP Address hiện tại là bao nhiêu?
• ARN là gì?
• Có cần tạo mới không?

Terraform không thể đoán.

Provider cũng không biết EC2 nào thuộc resource nào.

AWS chỉ biết:

"Có một EC2."

Nó hoàn toàn không biết resource trong Terraform tên là:

aws_instance.web

Terraform cần một nơi lưu mối liên kết đó.

Đó chính là State.

Terraform State thực chất là gì?

Terraform State chỉ là một file.

Thông thường nó tên là:

terraform.tfstate

Bên trong chứa rất nhiều metadata.

Ví dụ đơn giản:

{
  "resources": [
    {
      "type": "aws_instance",
      "name": "web",
      "instances": [
        {
          "attributes": {
            "id": "i-0123456789",
            "instance_type": "t3.micro",
            "private_ip": "10.0.0.15"
          }
        }
      ]
    }
  ]
}

Điều quan trọng không phải format JSON.

Điều quan trọng là Terraform biết:

aws_instance.web

↓

AWS EC2

↓

i-0123456789

Mapping này chính là lý do Terraform hoạt động được.

Terraform State lưu những gì?

State không chỉ lưu Resource ID.

Nó còn lưu rất nhiều thông tin khác.

Ví dụ:

• Resource ID
• ARN
• IP Address
• DNS Name
• Metadata
• Provider Information
• Dependency Information
• Outputs
• Sensitive Values (nếu provider trả về)

Ví dụ:

aws_lb.main

↓

arn:aws:elasticloadbalancing...

↓

DNS

↓

Security Group

↓

Subnets

Terraform không cần hỏi AWS mọi thứ từ đầu.

Nó đã có "bộ nhớ".

Terraform làm việc với State như thế nào?

Mỗi lần chạy Terraform.

Quy trình sẽ như sau.

Read Configuration

↓

Read State

↓

Refresh State

↓

Compare

↓

Create Execution Plan

Điều này cực kỳ quan trọng.

Terraform không compare Configuration với Cloud.

Terraform compare:

Configuration

VS

Terraform State (đã Refresh)

Đây là điểm mà rất nhiều người hiểu nhầm.

Refresh là gì?

Giả sử bạn login AWS Console.

Bạn đổi EC2 từ:

t3.micro

sang

t3.small

Terraform không hề biết điều này.

Lúc này State vẫn ghi:

t3.micro

Terraform sẽ hỏi Provider:

EC2 hiện tại thế nào?

Provider trả lời:

t3.small

Terraform cập nhật State.

Sau đó mới compare.

Desired

↓

t3.micro

Actual

↓

t3.small

Terraform kết luận:

Infrastructure Drift

Và plan sẽ xuất hiện.

~ update in-place

Infrastructure Drift là gì?

Drift xảy ra khi hạ tầng thật và Configuration không còn giống nhau.

Ví dụ:

Developer sửa Security Group bằng AWS Console.

Hoặc:

Ops đổi RAM của VM.

Hoặc:

Xóa Resource bằng Portal.

Terraform sẽ phát hiện sự khác biệt trong bước Refresh.

Đây cũng là lý do vì sao Infrastructure nên được quản lý hoàn toàn bằng IaC thay vì thao tác thủ công.

Nếu không có State thì sao?

Terraform sẽ không biết:

• Resource nào đã tồn tại
• Resource nào thuộc file nào
• Resource nào cần update
• Resource nào cần destroy

Kết quả thường là:

Plan:

+ Create everything

Đây là lý do mất file State là một trong những sự cố nghiêm trọng nhất khi làm IaC.

Local State

Mặc định.

Terraform lưu State ngay trên máy.

terraform.tfstate

Ưu điểm:

• Đơn giản
• Không cần cấu hình

Nhược điểm:

• Không chia sẻ được
• Không lock
• Dễ mất
• Không phù hợp cho team

Local State chỉ phù hợp để học hoặc thử nghiệm.

Remote State

Production gần như luôn dùng Remote State.

Ví dụ:

• Terraform Cloud
• S3 + DynamoDB (AWS)
• Azure Storage
• Google Cloud Storage

Lợi ích:

• Team dùng chung một State
• Có Version History
• Có State Locking
• Không bị ghi đè
• Backup
• Phân quyền

Remote State gần như là tiêu chuẩn trong mọi dự án thực tế.

Vì sao State Lock quan trọng?

Hãy tưởng tượng.

Hai người cùng chạy:

terraform apply

cùng lúc.

Người A:

Create VPC

Người B:

Delete Security Group

Nếu cùng ghi vào State.

State sẽ hỏng.

Đó là lý do Remote Backend luôn có cơ chế Lock.

Người thứ hai sẽ phải đợi.

Acquiring state lock...

Đây là cơ chế bảo vệ cực kỳ quan trọng trong môi trường production.

Có nên sửa trực tiếp State không?

Câu trả lời gần như luôn là:

Không.

State là nguồn dữ liệu mà Terraform tin tưởng tuyệt đối.

Chỉnh sửa thủ công có thể khiến Terraform:

• Mất mapping Resource
• Tạo lại Infrastructure
• Destroy nhầm Resource
• Không còn đồng bộ với Cloud

Nếu cần thao tác với State, hãy sử dụng các lệnh như:

terraform state list
terraform state show
terraform state mv
terraform state rm

Thay vì mở file JSON để sửa.

Những hiểu lầm phổ biến về Terraform State

Terraform đọc Infrastructure trực tiếp mỗi lần chạy

Không đúng.

Terraform luôn sử dụng State làm trung gian.

State chỉ lưu Resource ID

Không đúng.

State lưu rất nhiều metadata mà Terraform cần để tính toán kế hoạch thay đổi.

Local State đủ dùng cho Production

Không.

Production nên sử dụng Remote State có Locking và Versioning.

Có thể xóa State nếu cần

Chỉ nên làm khi bạn hiểu chính xác hậu quả.

Mất State không đồng nghĩa với mất Infrastructure, nhưng Terraform sẽ không còn biết cách quản lý những tài nguyên đó.

Tổng kết

Terraform State không phải là một file JSON bình thường.

Đó là bộ não giúp Terraform hiểu thế giới mà nó đang quản lý.

Không có State:

• Terraform không biết Resource nào thuộc về mình.
• Không biết cần Update hay Create.
• Không biết Infrastructure đã thay đổi ra sao.

Có thể nói:

Configuration mô tả hạ tầng bạn mong muốn, còn Terraform State ghi nhớ hạ tầng mà Terraform đang quản lý.

Hiểu rõ State là bước quan trọng để chuyển từ việc "biết dùng Terraform" sang thực sự hiểu cách Terraform hoạt động.

Bài tiếp theo

Ở bài này chúng ta đã hiểu Terraform ghi nhớ Infrastructure như thế nào.

Nhưng khi dự án bắt đầu có hàng chục hoặc hàng trăm Resource, việc tổ chức các file .tf sẽ trở nên rất quan trọng.

Ở bài tiếp theo, chúng ta sẽ tìm hiểu cách thiết kế Terraform Module như một Software Engineer, để Infrastructure có thể tái sử dụng, dễ mở rộng và dễ bảo trì trong các dự án thực tế.