Terraform: Những mẹo hay hữu ích

Chào các bác, tôi biết các bác đây toàn dân IT gạo cội, ai cũng rành Terraform rồi. Công nhận nó mạnh thật, nhưng mà để triển khai mấy cái dự án to đùng, phức tạp thì không chỉ dừng lại ở mấy cái lệnh cơ bản đâu. Hôm nay tôi với các bác cùng tâm sự mỏng về mấy chiêu nâng cao để Terraform của mình ngon lành, mượt mà, lại còn an toàn, tuân thủ nữa. Nghe tôi đi, đảm bảo không phí thời gian đâu

1. Dùng “Đường Ống” Tự Động Hóa Workflow Terraform Cho Đỡ Mệt

Mấy dự án lớn, mà cứ ngồi gõ lệnh Terraform tay bo thì thôi rồi, dễ “toang” lắm. Mình phải chơi Infrastructure Pipelines để tự động hóa mọi thứ, vừa nhanh vừa chuẩn, lại còn tránh được mấy vụ sai sót vớ vẩn nữa.

Mấy chiêu hay ho khi tích hợp CI/CD:

Tự động kiểm tra lỗi và bảo mật: Cứ cho nó chạy mấy cái lệnh như terraform fmt, terraform validate, tflint, checkov tự động là biết ngay lỗi hay lỗ hổng nào.
Tự động kiểm thử hạ tầng: Dùng Terratest hay InSpec để đảm bảo hạ tầng mình tạo ra đúng ý, không có gì sai lệch.
Bắt buộc xem xét code: Cái này quan trọng nè, khi ai đó tạo Terraform Plan thì phải có người khác xem xét, duyệt qua GitHub/GitLab merge requests rồi mới cho chạy. Sai một li đi một dặm đấy các bác.
Hạn chế quyền “apply”: Chỉ mấy cái tài khoản dịch vụ của CI/CD mới được quyền “apply” lên production thôi. Chứ cứ ai cũng được “apply” thì loạn!

Ví dụ thực tế với GitHub Actions:

name: Terraform CI/CD

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
      - name: Terraform Format &amp; Validate
        run: |
          terraform fmt -check
          terraform validate
      - name: Security Scan with Checkov
        run: |
          pip install checkov
          checkov -d .
      - name: Terraform Plan
        run: terraform plan -input=false
      - name: Terraform Apply
        if: github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve

2. Ép Buộc “Policy as Code” (OPA, Sentinel, Regula) Không “Lách” Được Đâu

Các bác làm lâu năm sẽ hiểu là phải lo vụ tuân thủ, bảo mật, quản trị ở quy mô lớn. Dùng Policy as Code (PaC) là cách để ngăn chặn mấy vụ cấu hình sai, cấu hình nguy hiểm từ trong trứng nước, không cho nó lọt được vào production.

Mấy chiêu hay ho:

Chặn cấu hình “ngáo ngơ”: Ví dụ như chặn tạo database không mã hóa, hay mấy cái S3 bucket public nhạy cảm.
Bắt buộc đặt tên và gắn thẻ (tagging) chuẩn: Cái này để dễ quản lý chi phí, quản lý bảo mật sau này.
Hạn chế các loại tài nguyên cụ thể: Chẳng hạn, không cho phép tạo mấy con EC2 instance khủng bố ở môi trường dev/test. Tiết kiệm tiền chứ các bác!

Ví dụ xịn sò với Open Policy Agent (OPA):

package terraform

deny[msg] {
  input.resource.type == "aws_s3_bucket"
  input.resource.public
  msg := "Public S3 buckets are not allowed"
}

3. Tối Ưu Hiệu Năng Terraform Cho Dự Án “Khủng” Nhanh Như Điện

Đụng tới hàng ngàn tài nguyên thì Terraform cũng có lúc “ì ạch” lắm. Mình phải có chiêu tối ưu để nó chạy nhanh, mượt mà hơn.

Mấy chiêu lợi hại:

Chạy song song (-parallelism flag): Tăng số lượng tài nguyên được tạo/cập nhật cùng lúc.
Tối ưu Remote State: Ví dụ như tối ưu cái vụ khóa của DynamoDB để truy cập state nhanh hơn.
Giảm bớt sự phụ thuộc giữa các module: Càng ít phụ thuộc thì càng dễ quản lý và tối ưu.
Dùng Terraform Data Sources thay vì “hardcode”: Để dữ liệu linh động hơn, dễ thay đổi hơn.
Chạy “plan” và “apply” một phần (-target): Chỉ chạy những phần mình muốn thay đổi, tiết kiệm thời gian.

Ví dụ đơn giản để chạy song song:

terraform apply -parallelism=50

4. Phát Hiện “Drift” Trong Terraform Không Lách Được Đâu

Cái vụ “Drift” này là khi có ai đó vào chỉnh sửa hạ tầng bằng tay mà không thông qua Terraform. Lâu dần là hạ tầng mình không còn khớp với cái file cấu hình nữa, dễ sinh chuyện lắm. Mình phải tự động phát hiện mấy vụ này.

Ví dụ phát hiện “drift” với GitHub Actions:

name: Terraform Drift Detection

on:
  schedule:
    - cron: '0 0 * * *' # Chạy mỗi ngày lúc 0h

jobs:
  drift-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
      - name: Terraform Plan (Detect Drift)
        run: terraform plan -detailed-exitcode || echo "Drift detected!"

5. Quản Lý State Terraform Nâng Cao Quan Trọng Lắm Đấy

Quản lý cái file Terraform State ở quy mô lớn đòi hỏi phải có chiến lược rõ ràng, không là dễ “toang” lắm.

Mấy chiêu hay ho cho dự án enterprise:

Dùng Remote State Backends: Dùng mấy cái dịch vụ như Terraform Cloud, AWS S3 + DynamoDB, GCP Storage để lưu trữ state, an toàn và dễ quản lý hơn.
Chia nhỏ State File: Nếu state file quá lớn thì nên chia thành nhiều file nhỏ hơn, mỗi file quản lý một phần. Tránh lỗi và dễ quản lý.
Bật Versioning và Backup cho State: Đề phòng trường hợp “lỡ tay” xóa nhầm hay chỉnh sửa sai, mình còn có cái mà khôi phục lại được.

6. Tự Động Kiểm Thử Hạ Tầng Với Terratest Chắc Ăn Hơn

Chỉ chạy Terraform không thì chưa đủ để khẳng định hạ tầng mình tạo ra đúng ý đâu. Mình phải dùng Terratest để viết các bài kiểm thử tự động, đảm bảo mọi thứ chạy ngon lành.

Ví dụ Terratest cho AWS EC2:

package test

import (
 "testing"
 "github.com/gruntwork-io/terratest/modules/aws"
 "github.com/stretchr/testify/assert"
)

func TestInstanceRunning(t *testing.T) {
 instanceID := aws.GetEc2InstanceId(t, "us-east-1", "Name", "web-server")
 instanceStatus := aws.GetEc2InstanceStatus(t, instanceID, "us-east-1")
 assert.Equal(t, "running", instanceStatus)
}

Lời Kết: Chơi Terraform Như Kỹ Sư Giỏi Là Phải Thế

Nói chung, để triển khai Terraform ở quy mô lớn, mình phải chú trọng vào tự động hóa, quản trị chặt chẽ và tối ưu hiệu năng. Cứ áp dụng mấy chiêu như CI/CD, Policy as Code, phát hiện drift, với mấy kỹ thuật quản lý state nâng cao này, đảm bảo hạ tầng của các bác sẽ vừa an toàn, vừa linh hoạt, lại còn “trâu bò” nữa.

Các bác thấy sao? Nghe ổn áp hơn chưa? Có chỗ nào cần chỉnh sửa nữa không, cứ nói tôi nhé!