Terraform: khi "mỗi khách một stack" gói lại thành một module dùng chung

Cái bẫy đầu tiên khi dựng hạ tầng cho khách hàng thứ hai nằm ngay trong tài liệu chính thức của Terraform. Workspace cho phép một cấu hình gắn với nhiều state, nghe rất giống “mỗi khách một bản”. Nhưng cũng chính HashiCorp viết rõ: workspace không phù hợp cho các deployment cần credential và kiểm soát truy cập riêng biệt.

Mà credential riêng biệt gần như là định nghĩa của công việc FDE. Bạn mang cùng một sản phẩm vào môi trường của khách A, rồi khách B, rồi khách C, mỗi nơi một tài khoản cloud, một bộ quyền, một yêu cầu bảo mật. Câu hỏi không phải là có dùng Terraform hay không, mà là xếp nó thế nào để lần deployment thứ năm vẫn giống lần đầu.

Một workflow cho mọi nền tảng khách đang dùng

Theo tài liệu của HashiCorp, Terraform là công cụ infrastructure-as-code để xây, thay đổi và version các tài nguyên cloud lẫn on-prem, mô tả trong file cấu hình có thể chia sẻ được. Điểm mấu chốt là cấu hình mang tính khai báo: bạn mô tả trạng thái đích, Terraform tự tính ra các bước.

Với FDE, cái lợi nằm ở chỗ bản thiết kế hạ tầng sống trong git, review được, diff được, thay vì nằm trong trí nhớ của người từng cài cho khách đầu tiên.

Provider là thứ giúp Terraform theo kịp môi trường đa dạng của khách hàng. HashiCorp mô tả provider cho phép Terraform làm việc với gần như mọi nền tảng hoặc dịch vụ có API truy cập được. Khách này chạy cloud, khách kia on-prem, khách thứ ba còn muốn nối thêm vài SaaS; một workflow, nhiều provider, cùng một cách plan và apply.

Module là đơn vị lặp lại, không phải copy-paste

HashiCorp nói thẳng trong tài liệu về module: với hạ tầng bạn provision lặp đi lặp lại, hãy viết module tái sử dụng để codify chúng. Họ cũng lập luận rằng module hóa và chia sẻ cấu hình giúp chuẩn hóa cách provision, để các team có tài nguyên nhanh và dự đoán được. Đó chính xác là bài toán của FDE: một stack chuẩn, nhiều lần dựng.

Thử hình dung bạn có module customer_stack nhận vào tên khách, region và kích cỡ. Cách gọi nó quen thuộc nhất là một map và một dòng for_each:

module "customer" {
  for_each = var.customers   # map: tên khách -> cấu hình
  source   = "./modules/customer_stack"
  name     = each.key
  region   = each.value.region
}

Theo tài liệu, meta-argument for_each nhận một map hoặc set chuỗi và tạo một instance cho mỗi phần tử. Thêm khách mới là thêm một entry vào map; sửa stack chuẩn là sửa một chỗ trong module.

Nhưng hãy nhìn kỹ: for_each sống trong một cấu hình, và theo tài liệu về state, một cấu hình gắn với một state trừ khi dùng workspace. Suy ra một lần apply chạm vào hạ tầng của mọi khách trong map, và nếu bạn không chủ động tách credential theo từng khách ngay trong cấu hình đó, tất cả đi qua cùng một bộ credential.

Cách này hợp khi mọi thứ nằm trong một ranh giới tin cậy, chẳng hạn nhiều môi trường cho cùng một khách, hoặc nhiều khách bạn host chung trên tài khoản của mình.

Với khách đòi credential riêng, đúng trường hợp HashiCorp nhắc tới khi cảnh báo về workspace, cách hợp lý hơn là mỗi khách một thư mục root, một backend, cùng gọi về một module. Khác biệt giữa các khách khi đó chỉ còn vài dòng biến trong thư mục của họ; stack chuẩn vẫn nằm ở một chỗ.

Workspace không phải là cách tách khách hàng

Đến đây mới chạm tới state. State là thứ ánh xạ cấu hình sang tài nguyên thật; HashiCorp khuyến nghị lưu nó ở HCP Terraform hoặc một remote backend để lưu trữ an toàn và cộng tác, đồng thời cảnh báo về backend không có khóa hoặc kiểm soát truy cập. Với dữ liệu hạ tầng của khách, đây không phải tùy chọn.

Và đây là lúc nhiều người với tay tới workspace. Tài liệu xác nhận một số backend hỗ trợ nhiều workspace có tên, cho phép nhiều state gắn với một cấu hình. Nhưng cùng trang đó ghi rõ workspace không phù hợp để phân rã hệ thống hay cho deployment cần credential và kiểm soát truy cập riêng.

Khách hàng doanh nghiệp hiếm khi chấp nhận credential dùng chung với khách khác.

Ghép hai cảnh báo đó lại, cách làm an toàn rút ra khá rõ: lặp cấu hình bằng module, nhưng tách state và credential ở tầng backend, mỗi khách một state remote có khóa và quyền riêng. Workspace vẫn có chỗ khi mọi bản đều chạy trên cùng một bộ credential; còn ranh giới giữa hai công ty thì, theo chính HashiCorp, không phải chỗ cho nó.

Giấy phép là câu hỏi khách sẽ hỏi

Có một chi tiết ngoài kỹ thuật mà FDE nên thuộc. Ngày 10/8/2023, HashiCorp chuyển Terraform và các sản phẩm lõi khác từ MPL 2.0 sang Business Source License, trong khi vẫn giữ API, SDK và phần lớn thư viện dưới MPL 2.0.

Ngày 25/8/2023, cộng đồng công bố OpenTofu, một fork của Terraform, với tuyên bố đã hoàn tất hồ sơ gia nhập Linux Foundation và mục tiêu tiến tới Cloud Native Computing Foundation.

Nếu khách hàng có chính sách chỉ dùng phần mềm open source, OpenTofu là phương án chính để bạn đưa ra. Bạn nên có sẵn hai mốc ngày đó và một quan điểm rõ ràng về việc chọn công cụ nào, trước khi khách đặt câu hỏi trong buổi review kiến trúc.

Học gì trước, và ghi gì vào CV

Thứ tự hợp lý là tư duy khai báo trước, rồi provider, rồi module, rồi state. Nhiều developer giỏi nhưng vẫn nghĩ theo kiểu script tuần tự, và Terraform sẽ làm họ bực mình cho đến khi họ chấp nhận chỉ mô tả trạng thái đích.

Sau đó, hãy tự ép mình viết một module cho stack của sản phẩm đang làm và gọi nó từ hai thư mục root cho hai khách giả định; đó là bài tập nhỏ nhưng chạm đúng vào việc FDE làm hằng ngày.

Trên CV, đừng viết “biết Terraform”; hãy viết bạn đã đóng gói một stack thành module tái sử dụng, dựng cho N khách bằng root config riêng, với state remote tách riêng và có khóa. Câu đó nói với người tuyển rằng bạn đã đi qua đúng cái bẫy mà tài liệu cảnh báo.

Khách hàng thứ hai luôn là bài kiểm tra thật sự. Nếu dựng cho họ chỉ là một thư mục mới gọi lại module cũ và một backend mới, bạn đã có thứ HashiCorp gọi là provisioning chuẩn hóa và dự đoán được.