Quản lý Multi-Environment và Multi-Account với Terragrunt
Trong bài trước, chúng ta đã tìm hiểu cách Terragrunt xây dựng dependency graph để tự động triển khai infrastructure theo đúng thứ tự.
Tuy nhiên, khi infrastructure ngày càng lớn, một vấn đề khác nhanh chóng xuất hiện.
Làm sao quản lý nhiều môi trường và nhiều Cloud Account mà không phải copy toàn bộ repository?
Đây là một trong những lý do quan trọng nhất khiến Terragrunt được sử dụng rộng rãi trong các hệ thống production.
Một môi trường không bao giờ là đủ
Hầu hết mọi hệ thống đều có nhiều môi trường.
Ví dụ:
Development
↓
Testing
↓
Staging
↓
Production
Mỗi môi trường đều triển khai gần như cùng một infrastructure.
Ví dụ:
VPC
EKS
RDS
Redis
Monitoring
Applications
Khác biệt chủ yếu chỉ nằm ở cấu hình.
Điều gì thay đổi giữa các môi trường?
Development thường có:
- Instance nhỏ
- Database nhỏ
- Một Availability Zone
- Ít node Kubernetes
- Chi phí thấp
Trong khi Production có thể cần:
- Multi-AZ
- Auto Scaling
- Nhiều Node Group
- Database lớn
- Backup
- Monitoring đầy đủ
- High Availability
Infrastructure gần như giống nhau.
Chỉ khác giá trị cấu hình.
Giải pháp phổ biến khi chỉ dùng Terraform
Rất nhiều team ban đầu sẽ làm như sau:
terraform/
dev/
staging/
production/
Mỗi thư mục chứa:
provider.tf
backend.tf
versions.tf
variables.tf
main.tf
Sau đó copy toàn bộ từ Development sang Production.
Repository nhanh chóng trở thành:
dev/
staging/
production/
sandbox/
demo/
performance/
Mỗi lần cập nhật provider hoặc backend, bạn phải sửa ở tất cả các thư mục.
Đây chính là duplication mà chúng ta đã nhắc đến ở các bài trước.
Terragrunt tiếp cận vấn đề khác đi
Terragrunt coi mỗi Environment chỉ là:
Một tập hợp các giá trị cấu hình.
Chứ không phải một Terraform project hoàn toàn mới.
Ví dụ:
live/
development/
staging/
production/
Ba thư mục này đều sử dụng cùng một Terraform Module.
Điểm khác biệt chỉ là:
- Region
- Account
- CIDR
- Instance Size
- Replica Count
- Environment Name
Toàn bộ phần còn lại được chia sẻ.
Chia sẻ Module, thay đổi Configuration
Giả sử bạn có một module:
modules/
eks/
Development sử dụng:
cluster_size = 2
Production sử dụng:
cluster_size = 10
Terraform Module hoàn toàn giống nhau.
Không cần copy thêm một dòng code nào.
Điều thay đổi chỉ là phần input.
Đây là tư duy rất quan trọng khi thiết kế Infrastructure as Code.
Không chỉ nhiều Environment
Trong thực tế, nhiều công ty còn có nhiều AWS Account.
Ví dụ:
AWS Organization
├── Shared
├── Security
├── Networking
├── Development
├── Staging
├── Production
└── Sandbox
Hoặc:
Customer A
Customer B
Customer C
Hoặc:
US Region
EU Region
APAC Region
Mỗi Account đều có thể sử dụng cùng một module.
Điều khác biệt chỉ là cấu hình.
Repository có thể mở rộng như thế nào?
Một ví dụ phổ biến:
live/
aws/
development/
staging/
production/
Sau đó:
development/
network/
eks/
database/
monitoring/
Production cũng có cấu trúc tương tự.
Điều này mang lại một lợi ích lớn.
Developer chỉ cần nhìn vào cấu trúc thư mục là hiểu ngay infrastructure được tổ chức như thế nào.
Layer Configuration
Terragrunt khuyến khích chia cấu hình thành nhiều tầng.
Ví dụ:
Root
Chứa:
- Terraform Version
- Provider Version
- Backend
- Common Tags
AWS Account
Chứa:
- Account ID
- IAM Role
- Default Region
Environment
Chứa:
- Environment Name
- CIDR
- Common Variables
Service
Chứa:
- CPU
- Memory
- Replica
- Instance Size
Nhờ vậy, thay đổi ở một tầng sẽ tự động được áp dụng cho toàn bộ tầng bên dưới.
Thêm một Environment mới
Giả sử hôm nay công ty cần thêm:
Performance Testing
Nếu dùng Terraform thuần, bạn có thể sẽ:
- Copy Development
- Đổi tên thư mục
- Chỉnh lại Backend
- Chỉnh Provider
- Chỉnh Variables
Nếu dùng Terragrunt:
Bạn chỉ cần thêm:
performance/
Sau đó khai báo:
- Account
- Region
- Environment Name
Mọi cấu hình còn lại đều được kế thừa.
Đây chính là sức mạnh của việc chia sẻ configuration.
Multi-Account không có nghĩa là nhiều Repository
Một số tổ chức tạo:
terraform-prod
terraform-dev
terraform-stage
Ba repository khác nhau.
Điều này khiến việc đồng bộ thay đổi trở nên rất khó khăn.
Terragrunt cho phép quản lý nhiều Account trong cùng một repository.
Mỗi Account chỉ là một tầng cấu hình khác nhau.
Repository vẫn giữ được sự thống nhất.
Repository có thể phát triển trong nhiều năm
Ban đầu:
2 Environment
Sau đó:
5 Environment
Rồi:
12 AWS Accounts
Cuối cùng:
300 Terraform Projects
Nếu repository được thiết kế đúng ngay từ đầu, bạn gần như không cần thay đổi kiến trúc.
Bạn chỉ tiếp tục bổ sung:
- Environment mới
- Account mới
- Service mới
Toàn bộ quy tắc cũ vẫn hoạt động.
Đây là một trong những đặc điểm quan trọng của một production repository.
Multi-Environment không chỉ dành cho AWS
Mặc dù ví dụ trong series chủ yếu sử dụng AWS, ý tưởng này hoàn toàn áp dụng cho:
- Azure
- Google Cloud
- Kubernetes
- On-premise Infrastructure
Miễn là infrastructure có nhiều môi trường hoặc nhiều cụm triển khai, Terragrunt đều có thể giúp tổ chức repository theo cùng một tư duy.
Tổng kết
Terragrunt không tạo thêm môi trường hay Cloud Account.
Nó giúp chúng ta quản lý chúng một cách nhất quán.
Thay vì tạo nhiều Terraform project gần giống nhau, Terragrunt khuyến khích:
- Tái sử dụng Module
- Chia sẻ Configuration
- Phân tầng Environment
- Phân tầng Account
- Kế thừa cấu hình giữa các cấp
Nhờ đó, repository có thể mở rộng từ vài project lên hàng trăm project mà vẫn dễ đọc, dễ bảo trì và dễ onboarding.
Bài tiếp theo
Ở bài tiếp theo, chúng ta sẽ tìm hiểu cách quản lý Secrets và tích hợp CI/CD với Terragrunt, từ việc bảo vệ thông tin nhạy cảm đến tự động hóa quá trình triển khai infrastructure trong môi trường production.