Posted on :: 2415 Words :: Tags: , , ,

Tại sao cần Infrastructure as Code?

Chào bạn! Mình rất vui được đồng hành cùng bạn trong hành trình chinh phục Terraform. Series này sẽ đưa bạn từ những khái niệm cơ bản nhất của Infrastructure as Code (IaC) cho đến việc triển khai hệ thống production với DevSecOps. Sau 12 phần, bạn sẽ tự tin quản lý hạ tầng multi-cloud như một pro.

Nhưng trước khi bắt tay vào code, chúng ta cần trả lời câu hỏi then chốt: Tại sao phải dùng Infrastructure as Code?

📦 Repository đi kèm

Toàn bộ code mẫu cho cả series 12 phần này mình đã chuẩn bị sẵn trên GitHub:

Repository: terraform-hcl-tutorial-series

Tuy Phần 1 này chủ yếu là lý thuyết, nhưng trong repo bạn sẽ tìm thấy:

  • Sơ đồ minh họa sự khác biệt giữa declarative và imperative
  • Bảng so sánh Terraform với các công cụ khác
  • Code mẫu thực tế cho Phần 2-12

Bạn có thể vào xem trước bất cứ lúc nào, hoặc clone về máy để code cùng mình:

git clone https://github.com/khuongdo/terraform-hcl-tutorial-series.git
cd terraform-hcl-tutorial-series

# Mỗi phần có tag riêng để dễ theo dõi
git tag -l
# part-01, part-02, part-03, ...

# Checkout phần nào cũng được
git checkout part-01

Vấn đề: Quản lý hạ tầng thủ công

Thử tưởng tượng bạn cần deploy một web app lên cloud. Với AWS Console, bạn sẽ phải:

  1. Click qua 15 màn hình khác nhau chỉ để tạo một VPC
  2. Ngồi config thủ công từng subnet, route table, security group
  3. Tạo EC2 instance rồi... quên mất lần trước dùng AMI nào
  4. Mất 20 phút để setup lại y hệt môi trường staging
  5. Ghi chép vào file Word... rồi nó lỗi thời ngay sau đó
  6. Sáu tháng sau, chẳng ai nhớ tại sao lại có cái security group đó

Nghe quen không? Đây chính là cơn ác mộng của việc quản lý hạ tầng thủ công.

Những vấn đề nghiêm trọng của hạ tầng thủ công

Không nhất quán: Production và staging của bạn khác nhau mà không ai biết tại sao. Đơn giản vì trí nhớ con người có giới hạn.

Không có Version Control: Bạn không thể git diff để xem hạ tầng đã thay đổi gì từ tuần trước đến giờ.

Documentation lỗi thời: Cái runbook viết công phu kia? Nó lỗi thời ngay khi có người "sửa nhanh" mà quên cập nhật tài liệu.

Triển khai chậm: Click thủ công qua console không scale được. Deploy lên 10 regions? Chúc bạn may mắn nhé.

Rủi ro cao: Một cái click nhầm ở production là có thể bay màu database. Không có preview, không có rollback.

Knowledge Silos: Chỉ có Sarah biết network được config thế nào, mà... cô ấy đang nghỉ phép.

Giải pháp: Infrastructure as Code

Infrastructure as Code (IaC) là cách quản lý hạ tầng như quản lý code. Thay vì ngồi click qua console, bạn viết declarative configuration files để mô tả hạ tầng bạn muốn có.

# Thay vì click...
Click "Create VPC" → Enter CIDR → Click "Create Subnet" → ...

# Bạn viết code:
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

Khi chạy code này với Terraform, nó sẽ tự động tạo đúng hạ tầng bạn mô tả. Chính xác. Mỗi lần.

IaC thay đổi game thế nào?

1. Version Control mọi thứ

Hạ tầng của bạn nằm ngay trong Git, cùng với code:

git log infrastructure/
# Xem ai đã sửa security group và lý do là gì
# Rollback ngay khi có vấn đề bằng `git revert`
# Thoải mái branch và test mà không lo sợ gì

2. Nhất quán giữa các môi trường

Dev, staging và production dùng chung một bộ code, chỉ khác biến:

# Cùng infrastructure definition
module "app" {
  source = "./modules/app"

  # Chỉ các biến thay đổi
  environment = var.environment  # "dev", "staging", "prod"
  instance_count = var.environment == "prod" ? 10 : 2
}

3. Documentation tự động

Code chính là tài liệu. Muốn biết đang chạy bao nhiêu database? Đọc config là ra:

resource "aws_db_instance" "users" {
  identifier = "users-db"
  engine     = "postgres"
  # Tất cả cấu hình hiển thị một cách rõ ràng
}

4. Deploy siêu nhanh

Deploy lên 10 AWS regions cùng lúc chỉ với một lệnh:

terraform apply
# Tạo hàng trăm resources trong vài phút
# Chạy song song tự động
# Xem preview trước khi apply

5. Disaster Recovery

Toàn bộ hạ tầng là code. Mất cả AWS account? Deploy lại mọi thứ từ Git trong vòng 1 giờ.

6. Làm việc nhóm dễ dàng

Quản lý thay đổi hạ tầng giống như quản lý code:

# Tạo branch cho thay đổi hạ tầng
git checkout -b add-redis-cache
# ... làm việc ...
git commit -m "Add Redis for session caching"
# Tạo PR để team review
# Merge sau khi được approve

Declarative vs Imperative: Hai triết lý IaC

Công cụ IaC có hai trường phái: imperativedeclarative. Hiểu rõ sự khác biệt này rất quan trọng.

Imperative: "Làm thế nào"

Công cụ imperative (Bash scripts, Ansible) ra lệnh cho hệ thống từng bước một:

# Imperative (Bash)
aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id vpc-123 --cidr-block 10.0.1.0/24
aws ec2 run-instances --subnet-id subnet-456 --image-id ami-789

Vấn đề:

  • VPC đã có sẵn thì sao?
  • Script fail giữa chừng thì sao?
  • Xóa sạch resources làm sao?
  • Thứ tự quan trọng (sai thứ tự = fail)

Declarative: "Muốn cái gì"

Công cụ declarative (Terraform, CloudFormation) mô tả kết quả cuối cùng mong muốn:

# Declarative (Terraform)
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

Terraform tự động tìm ra:

  • Cái nào đã có sẵn
  • Cái nào cần tạo mới
  • Cái nào cần update
  • Cái nào cần xóa
  • Thứ tự thực hiện đúng

Chạy lần đầu: Tạo resources. Chạy lại: Không làm gì (đã đúng rồi). Sửa code rồi chạy: Chỉ update phần thay đổi.

Đây gọi là idempotent: chạy nhiều lần vẫn cho cùng kết quả.

Tại sao chọn Terraform? (2025)

OK, đã hiểu IaC là gì. Nhưng sao lại là Terraform? Cùng so sánh với các đối thủ nhé.

Bức tranh toàn cảnh IaC

Công cụ riêng từng cloud:

  • AWS CloudFormation: Chỉ cho AWS, YAML/JSON, tích hợp sâu với AWS
  • Azure Resource Manager (ARM): Chỉ cho Azure, JSON templates
  • Google Cloud Deployment Manager: Chỉ cho GCP, YAML/Jinja2

Công cụ Multi-Cloud:

  • Terraform: Multi-cloud, ngôn ngữ HCL, ecosystem cực lớn
  • Pulumi: Multi-cloud, dùng ngôn ngữ lập trình thật (TypeScript, Python, Go)
  • Crossplane: Kubernetes-native, dùng Kubernetes CRDs

Configuration Management (không phải IaC thuần):

  • Ansible: Imperative, hay cho config server, không phải quản lý hạ tầng
  • Chef/Puppet: Lâu đời nhưng đang giảm, học phức tạp

Điểm mạnh của Terraform

1. Multi-Cloud ngay từ đầu

Terraform làm việc với AWS, GCP, Azure và hơn 3,000 providers khác bằng cùng một cú pháp:

# AWS
resource "aws_instance" "web" { ... }

# GCP
resource "google_compute_instance" "web" { ... }

# Azure
resource "azurerm_linux_virtual_machine" "web" { ... }

# Cùng workflow, cùng cú pháp

2. Ecosystem Provider khổng lồ

Ngoài các cloud providers, Terraform còn quản lý:

  • DNS: Cloudflare, Route53, DNSimple
  • Monitoring: Datadog, New Relic, PagerDuty
  • Databases: MongoDB Atlas, Snowflake, PostgreSQL
  • Security: Vault, Auth0, Okta
  • Cả GitHub nữa: Repos, teams, branch protection

Một công cụ, quản lý tất.

3. Ngôn ngữ HCL được thiết kế riêng cho IaC

HashiCorp Configuration Language (HCL) được tạo ra chuyên cho việc quản lý hạ tầng:

# Dễ đọc, không dài dòng như JSON
# Hỗ trợ biến, hàm, điều kiện
# Type-safe với validation

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Must be dev, staging, or prod."
  }
}

4. State Management

Terraform theo dõi trạng thái hiện tại của hạ tầng trong state file. Nhờ đó có thể:

  • Phát hiện drift (ai đó sửa thủ công resources)
  • Làm việc đồng thời an toàn với locking
  • Import hạ tầng hiện có vào quản lý

5. Ecosystem trưởng thành (2025)

Tính đến 2025, Terraform có:

  • 15+ năm chạy production
  • 100,000+ modules trên Terraform Registry
  • Hỗ trợ enterprise qua Terraform Cloud/Enterprise
  • Policy-as-code (Sentinel, OPA)
  • Testing framework đầy đủ (Terratest, tfsec)
  • Cộng đồng lớn và HashiCorp backing

Khi nào nên dùng Terraform?

✅ Dùng Terraform khi:

  • Quản lý cloud infrastructure (AWS, GCP, Azure)
  • Cần multi-cloud hoặc cloud-agnostic
  • Muốn hạ tầng declarative, idempotent
  • Cần version control cho hạ tầng
  • Xây dựng modules tái sử dụng
  • Team cần collaborate về hạ tầng

❌ Cân nhắc công cụ khác khi:

  • Chỉ dùng AWS và cần tích hợp sâu: CloudFormation đơn giản hơn
  • Kubernetes-native workflows: Crossplane hợp hơn
  • Devs muốn dùng ngôn ngữ quen: Pulumi cho phép TypeScript/Python/Go
  • Config server đơn giản: Ansible nhẹ hơn
  • Môi trường legacy: Đã đầu tư Chef/Puppet

Với hầu hết team quản lý hạ tầng cloud hiện đại, Terraform là lựa chọn mặc định.

Câu chuyện thực tế từ Production

Case Study 1: Multi-Region DR (Fintech)

Thách thức: Deploy hạ tầng y hệt nhau lên 5 AWS regions với uptime SLA 99.99%.

Giải pháp: Terraform modules viết một lần, deploy lên tất cả regions với biến khác nhau.

Kết quả:

  • Thời gian deploy: 2 giờ → 15 phút
  • Tính nhất quán: 100% (zero configuration drift)
  • Disaster recovery: Full failover test hàng quý trong 20 phút

Case Study 2: Startup Scaling (SaaS)

Thách thức: Provision nhanh môi trường khách hàng khi scale từ 10 → 1,000 khách hàng.

Giải pháp: Terraform workspace cho mỗi khách hàng, tự động hóa qua CI/CD.

Kết quả:

  • Onboard khách hàng mới: 2 ngày → 10 phút
  • Theo dõi chi phí: Resource tracking theo từng khách hàng
  • Developer productivity: Engineer tự provision hạ tầng

Case Study 3: Compliance & Audit (Healthcare)

Thách thức: Đáp ứng HIPAA với các thay đổi hạ tầng có thể audit.

Giải pháp: Terraform + Git + policy-as-code enforcement.

Kết quả:

  • Audit trail đầy đủ: Mọi thay đổi tracked trong Git
  • Compliance tự động: Pre-commit hooks enforce security policies
  • Thời gian audit: Tuần → Giờ (review Git logs)

Roadmap Series 12 Phần

Đây là Phần 1/12 của series Terraform toàn diện. Cùng xem chặng đường phía trước nhé:

Foundation (Phần 1-3)

  • Phần 1: Tại sao cần Infrastructure as Code? (Bạn đang ở đây)
  • Phần 2: Setup Terraform (Installation & Authentication)
  • Phần 3: Cloud Resource đầu tiên (Hands-on AWS)

Core Concepts (Phần 4-7)

  • Phần 4: HCL Fundamentals (Syntax, Types, Functions)
  • Phần 5: Variables, Outputs & State Management
  • Phần 6: Core Terraform Workflow (init, plan, apply, destroy)
  • Phần 7: Modules cho Organization & Reusability

Advanced Topics (Phần 8-12)

  • Phần 8: Multi-Cloud Patterns (AWS/GCP/Azure comparison)
  • Phần 9: State Management & Team Workflows
  • Phần 10: Testing & Validation (Terratest, tfsec, Policy-as-Code)
  • Phần 11: Security & Secrets Management (Vault, SOPS, OIDC)
  • Phần 12: Production Patterns & DevSecOps (CI/CD, Compliance)

Đến Phần 12, bạn sẽ deploy được hạ tầng production-grade với automated testing, security scanning và compliance enforcement.

Cần chuẩn bị gì?

Series này cần bạn có:

  • Biết sơ về cloud: Đã từng click qua AWS Console hoặc GCP UI
  • Thoải mái với terminal: Biết cd, ls và chạy lệnh cơ bản
  • Hiểu Git cơ bản: Biết git add, git commit

Không cần biết Terraform hoặc IaC trước! Mình sẽ bắt đầu từ con số 0.

Bạn sẽ build những gì?

Xuyên suốt series, bạn sẽ build:

  1. Resources đơn giản (EC2 instance, S3 bucket)
  2. VPC networks hoàn chỉnh với subnets, routing, security
  3. App multi-tier (web servers, databases, load balancers)
  4. Modules tái sử dụng publish lên Terraform Registry
  5. Multi-cloud deployment (cùng app trên AWS + GCP + Azure)
  6. Production-ready infrastructure với monitoring, compliance, DR

Toàn bộ code mẫu có sẵn trong GitHub repository.

Checkpoint: Bạn đã nắm được chưa?

Trước khi sang Phần 2, check xem bạn đã hiểu:

  1. Infrastructure as Code là gì?

    • Đáp án: Quản lý hạ tầng như code bằng cách viết declarative config files thay vì click thủ công trên console.
  2. Declarative vs Imperative khác nhau thế nào?

    • Đáp án: Declarative mô tả kết quả muốn có ("Tôi muốn 3 servers"). Imperative ra lệnh từng bước ("Tạo server 1, tạo server 2...").
  3. Sao lại chọn Terraform thay vì CloudFormation hay Pulumi?

    • Đáp án: Terraform multi-cloud, ecosystem provider khổng lồ, dùng HCL declarative và có 15+ năm battle-tested.
  4. Lợi ích chính của IaC?

    • Đáp án: Version control, consistency giữa các môi trường, documentation tự động, deploy nhanh, collaboration qua code review.

Trả lời được tự tin? Bạn đã sẵn sàng cho Phần 2!

Tiếp theo?

Phần 2: Setup Terraform, chúng ta sẽ hands-on:

  • Cài Terraform CLI lên máy bạn
  • Config AWS/GCP/Azure authentication
  • Hiểu provider concepts
  • Khởi tạo project Terraform đầu tiên
  • Chạy lệnh terraform init đầu tiên

Lý thuyết dừng ở đây. Từ Phần 2, bạn sẽ chạy Terraform commands thật và deploy cloud resources thật.

Sẵn sàng code chưa? Đến Phần 2 → (coming soon)


Tài liệu tham khảo

Muốn đọc thêm trước Phần 2? Check:

Có thắc mắc? Comment bên dưới nhé! Mình đọc từng comment và sẽ trả lời các câu hỏi hay trong phần tiếp theo.

Điều hướng series:


Bài viết này là phần của series "Terraform from Fundamentals to Production". Follow để master Infrastructure as Code với Terraform.