Quản lý Secrets và CI/CD với Terragrunt

Qua các bài trước, chúng ta đã xây dựng gần như đầy đủ một repository Terragrunt production:

• Repository Structure
• DRY Configuration
• Dependency Management
• Multi-Environment
• Multi-Account

Đến đây, chúng ta đã có thể quản lý hàng trăm Terraform project.

Nhưng vẫn còn một câu hỏi rất quan trọng.

Làm thế nào để triển khai Infrastructure một cách tự động mà vẫn đảm bảo an toàn?

Đó là lúc CI/CD và Secrets Management trở thành một phần không thể thiếu.

Infrastructure cũng cần CI/CD

Nhiều người chỉ nghĩ CI/CD dành cho ứng dụng.

Ví dụ:

Developer

↓

Git Push

↓

Build

↓

Deploy

Thực tế, Infrastructure cũng cần một quy trình tương tự.

Developer

↓

Git Push

↓

Terraform Plan

↓

Review

↓

Terraform Apply

Thay vì deploy application, pipeline sẽ deploy infrastructure.

Tại sao không chạy trên máy cá nhân?

Trong giai đoạn đầu, rất nhiều team thường chạy:

terragrunt apply

ngay trên máy của mình.

Điều này hoạt động.

Nhưng khi team phát triển, nó bắt đầu xuất hiện nhiều vấn đề.

Ví dụ:

• Không biết ai vừa deploy.
• Không có lịch sử thay đổi.
• Không có bước review.
• Mỗi người dùng một phiên bản Terraform khác nhau.
• Nguy cơ thao tác nhầm vào Production.

Infrastructure production không nên phụ thuộc vào laptop của bất kỳ ai.

CI/CD trở thành nơi triển khai duy nhất

Một mô hình phổ biến là:

Developer

↓

Pull Request

↓

CI

↓

Terraform Plan

↓

Code Review

↓

Merge

↓

CD

↓

Terragrunt Apply

Developer không còn trực tiếp chạy apply trên Production.

Thay vào đó, toàn bộ quá trình đều được tự động hóa.

Điều này giúp mọi thay đổi đều có thể kiểm tra và truy vết.

Terraform Plan trong Pull Request

Một workflow rất phổ biến là:

Git Push

↓

Pipeline

↓

terragrunt plan

↓

Comment vào Pull Request

Reviewer sẽ nhìn thấy:

+ Create 2 Resources

~ Update 1 Resource

- Destroy 0 Resource

Toàn bộ thay đổi được hiển thị trước khi merge.

Điều này giúp giảm đáng kể rủi ro khi triển khai.

Apply chỉ diễn ra sau khi Merge

Một nguyên tắc được nhiều tổ chức áp dụng là:

Pull Request

↓

Review

↓

Approved

↓

Merge

↓

Production Apply

Điều này đảm bảo:

Không ai có thể vô tình triển khai infrastructure chưa được review.

Đây cũng là lý do nhiều doanh nghiệp yêu cầu mọi thay đổi Infrastructure đều phải thông qua Pull Request.

Secrets không nên nằm trong Repository

Một sai lầm rất phổ biến là:

terraform.tfvars

chứa:

db_password

api_key

access_key

secret_key

Sau đó commit lên Git.

Đây là một trong những lỗi bảo mật nghiêm trọng nhất.

Repository nên được coi là nơi chứa mã nguồn, không phải nơi lưu trữ thông tin nhạy cảm.

Terragrunt không quản lý Secrets

Đây là điều cần phân biệt.

Terragrunt không phải là Secret Manager.

Nó không mã hóa mật khẩu.

Nó không lưu trữ API Key.

Nó chỉ giúp kết nối Infrastructure với hệ thống quản lý Secrets.

Ví dụ:

• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager
• HashiCorp Vault
• Doppler
• Infisical
• 1Password Secrets Automation

Terragrunt đóng vai trò cầu nối, không phải nơi lưu trữ.

Tách Secrets khỏi Configuration

Một repository tốt thường chia rõ:

Infrastructure Configuration

và

Sensitive Data

Ví dụ:

Infrastructure

↓

Terragrunt

↓

Secret Manager

Pipeline sẽ lấy Secret từ Secret Manager trong quá trình chạy.

Repository hoàn toàn không chứa mật khẩu.

Credentials của Cloud Provider

Một câu hỏi phổ biến là:

AWS Access Key nên để ở đâu?

Câu trả lời là:

Không nên nằm trong repository.

Thông thường, CI/CD sẽ sử dụng:

• IAM Role
• OIDC
• Workload Identity
• Service Principal

để xác thực với Cloud Provider.

Điều này giúp loại bỏ hoàn toàn Access Key tĩnh.

Ngày nay, OIDC đang dần trở thành lựa chọn mặc định trên GitHub Actions và nhiều nền tảng CI/CD khác.

Promotion giữa các Environment

Một pipeline production thường không deploy thẳng lên Production.

Ví dụ:

Development

↓

Testing

↓

Staging

↓

Production

Infrastructure cũng nên đi theo quy trình này.

Điều này giúp phát hiện lỗi sớm trước khi ảnh hưởng đến môi trường Production.

Repository chỉ có một nguồn sự thật

Một nguyên tắc quan trọng của GitOps là:

Git là nguồn sự thật duy nhất.

Mọi thay đổi Infrastructure đều bắt đầu từ Git.

Không chỉnh trực tiếp trên Cloud Console.

Không chạy script thủ công.

Không thay đổi tài nguyên ngoài quy trình.

Repository luôn phản ánh trạng thái mong muốn của hệ thống.

Rollback dễ dàng hơn

Nếu một thay đổi gây ra sự cố:

Bạn chỉ cần:

Git Revert

↓

Pipeline

↓

Terragrunt Apply

Infrastructure sẽ được đưa về trạng thái mong muốn trước đó.

Không cần ghi nhớ từng thao tác thủ công.

Đó là một trong những lợi ích lớn nhất của Infrastructure as Code.

Một Production Pipeline điển hình

Một pipeline hoàn chỉnh thường có dạng:

Git Push

↓

Static Checks

↓

Terragrunt Format Check

↓

Terraform Validate

↓

Terragrunt Plan

↓

Security Scan

↓

Manual Approval

↓

Terragrunt Apply

Tùy quy mô tổ chức, pipeline có thể bổ sung:

• Cost Estimation
• Policy as Code
• Compliance Checks
• Drift Detection

Nhưng ý tưởng cốt lõi vẫn không thay đổi:

Mọi thay đổi đều phải được kiểm tra trước khi triển khai.

Những điều nên tránh

Khi triển khai Terragrunt trong production, nên tránh:

• Chạy apply trực tiếp trên Production.
• Commit secrets vào Git.
• Dùng Access Key tĩnh trong pipeline.
• Bỏ qua bước plan.
• Cho phép deploy không cần review.
• Chỉnh sửa infrastructure trực tiếp trên Cloud Console.

Đây đều là những nguyên nhân phổ biến dẫn đến sự cố trong các hệ thống lớn.

Tổng kết

Terragrunt không thay thế hệ thống CI/CD hay Secret Manager.

Thay vào đó, nó kết hợp rất tốt với các công cụ này để tạo nên một quy trình triển khai Infrastructure hiện đại.

Một quy trình production tốt thường có các đặc điểm:

• Mọi thay đổi bắt đầu từ Git.
• Secrets được lưu trong Secret Manager.
• CI tự động chạy plan.
• apply chỉ diễn ra sau khi được phê duyệt.
• Toàn bộ lịch sử thay đổi đều có thể truy vết.

Khi kết hợp Terragrunt với GitOps và CI/CD, Infrastructure không còn là tập hợp các thao tác thủ công, mà trở thành một quy trình tự động, nhất quán và đáng tin cậy.

Chúc mừng!

Đến đây, chúng ta đã hoàn thành toàn bộ series Terraform & Terragrunt.

Từ những khái niệm cơ bản nhất về Infrastructure as Code cho đến việc xây dựng và vận hành hạ tầng trong môi trường production, chúng ta đã cùng nhau đi qua hơn 20 bài viết với những chủ đề như:

Terraform Fundamentals

• Infrastructure as Code và tư duy quản lý hạ tầng hiện đại.
• Cách Terraform hoạt động và quy trình Plan → Apply.
• Terraform State và vai trò của Remote State.
• Variables, Outputs và Data Sources.
• Những tính năng Terraform được sử dụng hằng ngày như for_each, count, locals, dynamic, depends_on và lifecycle.
• Thiết kế repository, import hạ tầng hiện có và những sai lầm phổ biến khi làm việc với Terraform.

Terragrunt for Production

• Vì sao Terraform thôi là chưa đủ đối với những hệ thống có quy mô lớn.
• Cách tổ chức repository cho nhiều environment và nhiều cloud account.
• Áp dụng nguyên tắc DRY với include, generate và read_terragrunt_config.
• Quản lý dependency giữa các thành phần hạ tầng.
• Quản lý secrets và xây dựng quy trình triển khai Infrastructure as Code thông qua CI/CD.

Hy vọng sau toàn bộ series này, bạn không chỉ biết cách sử dụng Terraform và Terragrunt, mà còn hiểu được tư duy thiết kế, tổ chức và vận hành Infrastructure as Code cho những hệ thống thực tế.

Nếu chỉ có một điều mình muốn bạn nhớ sau tất cả bài viết, thì đó là:

Infrastructure as Code không chỉ là viết file .tf hay terragrunt.hcl, mà là xây dựng một quy trình quản lý hạ tầng có thể cộng tác, kiểm soát, tự động hóa và phát triển bền vững theo thời gian.

Terraform giúp chúng ta định nghĩa infrastructure.

Terragrunt giúp chúng ta quản lý infrastructure ở quy mô lớn.

Git giúp chúng ta kiểm soát mọi thay đổi.

CI/CD giúp chúng ta triển khai hạ tầng một cách an toàn và nhất quán.

Khi những mảnh ghép này kết hợp với nhau, Infrastructure as Code không còn chỉ là một công cụ, mà trở thành một nền tảng giúp các team xây dựng và vận hành hệ thống một cách hiệu quả trong nhiều năm.

Cảm ơn bạn đã đồng hành cùng mình trong suốt series Terraform & Terragrunt. Hy vọng những kiến thức và kinh nghiệm được chia sẻ sẽ giúp bạn tự tin hơn khi áp dụng Infrastructure as Code vào các dự án thực tế.

Hẹn gặp lại bạn trong những series tiếp theo về Cloud, DevOps và Software Engineering!