Terraform Import: Đưa Hạ Tầng Hiện Có Vào Quản Lý Bằng Mã

Đội ngũ của bạn đã triển khai tài nguyên đám mây trong nhiều năm bằng các cú nhấp trên console và script shell. Giờ bạn muốn áp dụng Hạ tầng như Mã, nhưng việc tạo lại mọi thứ từ đầu có vẻ quá tải. Tôi đã từng ở tình huống này, và tính năng import của Terraform chính là lời giải cho thách thức đó.

Rủi ro của "ClickOps" và quản trị hạ tầng thủ công sẽ tích tụ theo thời gian. Tài nguyên bị thiếu tài liệu, cấu hình lệch khỏi tiêu chuẩn, và “kiến thức truyền miệng” thay thế cho tài liệu chuẩn. Khi thành viên rời đi, các quyết định hạ tầng của họ cũng đi theo. 

Đây là lý do các tổ chức áp dụng Hạ tầng như Mã (IaC). Trong hướng dẫn này, tôi sẽ đưa bạn qua quy trình import hạ tầng hiện có vào Terraform. 

Chúng ta sẽ so sánh lệnh import dựa trên CLI với import block mang tính khai báo được giới thiệu trong Terraform 1.5, khám phá quy trình thực tiễn cho cả hai cách tiếp cận, và xử lý các cạm bẫy phổ biến có thể biến một lần import đơn giản thành sự cố sản xuất. Kết thúc, bạn sẽ tự tin đưa hạ tầng hiện có vào quản lý bằng mã. 

Nếu bạn mới làm quen IaC và nhà cung cấp đám mây, hãy cân nhắc tham gia các khóa học của chúng tôi như AWS Concepts, Understanding Cloud Computing, hoặc Understanding Microsoft Azure. 

Terraform Import Là Gì?

Khi bạn tạo hạ tầng với Terraform từ đầu, mọi thứ diễn ra mượt mà. Bạn viết cấu hình, chạy terraform plan, xem xét thay đổi, rồi áp dụng. Terraform theo dõi mọi thứ trong tệp state, tạo bản đồ hoàn hảo giữa mã và tài nguyên đám mây của bạn. 

Nhưng điều gì xảy ra khi tài nguyên đã tồn tại ngoài tầm biết của Terraform? Hãy bắt đầu bằng cách hiểu chính xác import làm gì và vì sao nó tồn tại.

Định nghĩa cốt lõi và mục đích

Terraform import ánh xạ hạ tầng thực tế hiện có vào các mục trong tệp state của Terraform mà không tạo tài nguyên mới. Hãy coi đó như việc nhận nuôi: bạn đang nói với Terraform bắt đầu quản lý một tài nguyên vốn đã chạy.

Điều này giải quyết vấn đề "shadow IT". Tổ chức tích lũy hạ tầng qua nhiều cách: triển khai qua console trong thời gian sự cố, tài nguyên thử nghiệm rồi thành vĩnh viễn, hoặc hệ thống kế thừa trước khi áp dụng IaC. Import hòa giải thực tế đó với các nguyên tắc Hạ tầng như Mã.

Điểm mấu chốt: import chủ yếu là một thao tác trên state. Nó không tự động viết mã cấu hình trừ khi bạn dùng tính năng sinh mã trong Terraform 1.5+. Bạn chịu trách nhiệm đảm bảo cấu hình HCL phản ánh chính xác tài nguyên đã import.

Giờ khi đã hiểu import làm gì, hãy xem khi nào nên và không nên dùng nó.

Terraform import so với các lựa chọn khác

Tôi khuyến nghị import cho ba kịch bản chính:

• Di chuyển hạ tầng kế thừa không thể tạo lại mà không có thời gian ngừng hoặc mất dữ liệu đáng kể. Ví dụ: cơ sở dữ liệu sản xuất với dữ liệu nhiều năm, hoặc load balancer đang phục vụ lưu lượng sống.
• Khôi phục từ tệp state bị mất, điều có thể xảy ra ngay cả khi dùng backend từ xa nếu không cấu hình sao lưu đúng cách.
• Đưa các thay đổi thủ công đã vượt qua quy trình quản lý thay đổi của bạn vào quản lý, có lẽ là các bản vá khẩn cấp trong thời gian sự cố.

Tuy nhiên, import không phải lúc nào cũng là lựa chọn đúng. Với tài nguyên thử nghiệm tạm thời hoặc hạ tầng tiêu chuẩn hóa kém, tôi thường đề xuất tạo mới sạch sẽ thay thế. 

Bắt đầu mới cho phép bạn áp dụng thực hành tốt hiện tại, triển khai quy ước đặt tên chuẩn, và bổ sung cấu hình bảo mật mà tài nguyên kế thừa có thể thiếu. Công sức ban đầu thường mang lại lợi ích về khả năng bảo trì lâu dài.

Điều tối quan trọng là phân biệt import với data source của Terraform. Data source cho phép bạn tham chiếu thông tin chỉ đọc từ hạ tầng hiện có mà không quản lý nó. Ví dụ, bạn có thể dùng data source để tra cứu một VPC hiện có do nhóm khác tạo, sau đó triển khai tài nguyên của bạn vào đó. 

Ngược lại, import đưa tài nguyên vào quản lý đầy đủ của Terraform, bao gồm khả năng sửa đổi hoặc hủy. Chọn import khi bạn cần quản lý toàn bộ vòng đời tài nguyên, không chỉ tham chiếu.

Trước khi bắt đầu import, có một số ràng buộc nền tảng bạn cần hiểu.

Các ràng buộc và nền tảng then chốt

Mỗi tài nguyên được import yêu cầu một định danh duy nhất phụ thuộc nhà cung cấp. Với AWS, có thể là i-0123456789abcdef0. Với Azure, là đường dẫn tài nguyên đầy đủ như /subscriptions/{id}/resourceGroups/{rg}/providers/{provider}/{resource}. Nhầm lẫn ở đây là nguyên nhân hàng đầu khiến import thất bại.

Thao tác import sửa đổi trực tiếp tệp state, nên sao lưu là thiết yếu. Nếu dùng backend có phiên bản như S3, hãy xác minh đã bật versioning. Với state cục bộ, sao chép thủ công sang terraform.tfstate.backup.

Sau khi import, bạn sẽ gặp "drift": sự lệch giữa state đã import và cấu hình cục bộ. Bạn sẽ cập nhật mã HCL theo từng bước cho đến khi terraform plan hiển thị không còn thay đổi chờ xử lý.

Điều Kiện Tiên Quyết và Chuẩn Bị cho Terraform Import 

Trước khi import bất cứ thứ gì, hãy đảm bảo bạn đã sẵn sàng để thành công. Tôi đã thấy các ca import thất bại vì đội ngũ bỏ qua bước chuẩn bị.

Bước đầu tiên là đảm bảo môi trường Terraform của bạn được cấu hình đúng.

Xác thực môi trường

Bắt đầu bằng việc xác minh cài đặt Terraform với terraform version. Nếu bạn muốn dùng import block mang tính khai báo và sinh mã tự động, hãy đảm bảo đang ở Terraform 1.5 hoặc mới hơn. Những tính năng này đơn giản hóa đáng kể quy trình import cho tài nguyên phức tạp.

Trước khi import, hãy xác minh các điều kiện tiên quyết sau:

• Thông tin xác thực provider đang hoạt động: Với AWS, kiểm tra AWS_ACCESS_KEY_ID và AWS_SECRET_ACCESS_KEY đã được đặt, hoặc profile AWS CLI của bạn đã cấu hình. Thử với aws sts get-caller-identity.

• Workspace đúng đã được chọn: Chạy terraform workspace show để chắc chắn bạn không lỡ import vào sai môi trường.

• Tệp state không bị khóa: Phối hợp với thành viên khác và kiểm tra pipeline CI/CD để đảm bảo không có thao tác đồng thời.

• Backend có thể truy cập: Nếu dùng state từ xa, xác minh kết nối tới S3, Azure Storage, hoặc Terraform Cloud.

Một tệp state bị khóa sẽ khiến import thất bại ngay với lỗi không lấy được khóa, nên bước phối hợp này rất quan trọng trong môi trường làm việc nhóm.

Khi môi trường đã được xác thực, bước quan trọng tiếp theo là tìm đúng định danh cho tài nguyên bạn muốn import.

Xác định ID tài nguyên

ID tài nguyên khác nhau đáng kể theo nhà cung cấp và loại tài nguyên, khiến bước này khó hơn bạn nghĩ. Dưới đây là ví dụ của các nhà cung cấp phổ biến:

Với tài nguyên AWS, bạn có thể tìm ID trực tiếp trong console. Điều hướng đến dịch vụ (EC2, S3, v.v.), chọn tài nguyên của bạn và sao chép định danh từ khung chi tiết.

Với Azure, hãy dùng Azure CLI để lấy đường dẫn tài nguyên đầy đủ:

az resource show --name myresource --resource-group mygroupĐược hỗ trợ bởi

Kết quả trả về bao gồm ID tài nguyên đầy đủ mà bạn cần cho import.

Đây là chiếc bẫy phổ biến tôi từng mắc: cố gắng import tài nguyên ở sai vùng hoặc subscription. Nếu cấu hình provider Terraform của bạn trỏ đến us-east-1 nhưng phiên bản EC2 của bạn nằm ở us-west-2, import sẽ thất bại với lỗi "resource not found" dù ID instance là đúng. 

Luôn xác minh phạm vi khớp với cấu hình provider trước khi tiếp tục. Khi đã có ID đúng, bạn cần quyết định phương pháp import sẽ dùng.

Chọn chiến lược import

Bạn có hai con đường: lệnh CLI terraform import hoặc các block import. So sánh như sau:

Tôi khuyến nghị import block cho các nhóm cần rà soát mã và kế hoạch có thể tái lập, còn CLI cho sửa lỗi nhanh trên phiên bản cũ.

Tại sao điều này quan trọng? Import block xem việc “nhận nuôi” hạ tầng là mã, nghĩa là các bước import trở thành một phần của quy trình kiểm soát phiên bản với cùng mức nghiêm ngặt như bất kỳ thay đổi hạ tầng nào khác. Điều này giảm rủi ro sai sót và tạo vết kiểm toán thiết yếu cho tuân thủ và phối hợp nhóm. 

Import block tích hợp mượt với quy trình Git hiện có, cho phép đồng đội xem xét và phê duyệt import như mọi thay đổi hạ tầng khác. CLI, dù nhanh cho tác vụ cá nhân, không để lại vết kiểm toán và khó tái hiện trên nhiều môi trường.

Khi đã chọn chiến lược, hãy đi sâu vào từng quy trình, bắt đầu với cách tiếp cận CLI truyền thống.

Quy Trình Cốt Lõi A: Lệnh Terraform Import CLI

Tôi sẽ hướng dẫn bạn quy trình import dựa trên CLI truyền thống. Dù import block khai báo đang dần được ưa chuộng, hiểu phương pháp CLI vẫn hữu ích cho phiên bản Terraform cũ và các import nhanh, đơn lẻ.

Bước đầu trong quy trình CLI là thiết lập tệp cấu hình của bạn.

Chuẩn bị destination block

Trước khi chạy terraform import, bạn phải định nghĩa một resource block trong cấu hình. Đây là yêu cầu bắt buộc: Terraform cần biết ánh xạ state import vào đâu. Block có thể để trống hoặc điền một phần.

Ví dụ import một AWS S3 bucket:

resource "aws_s3_bucket" "legacy_data" {
  # Configuration to be filled after import
}Được hỗ trợ bởi

Loại tài nguyên (aws_s3_bucket) phải khớp chính xác với loại hạ tầng bạn đang import. Tên tài nguyên (legacy_data) nên theo quy ước đặt tên của dự án. Dùng tên mô tả như production_data_bucket thay vì bucket1 chung chung.

Khi resource block đã sẵn sàng, bạn có thể chạy lệnh import.

Thực thi import

Chạy terraform import <resource_address> <resource_id>. Với S3 bucket của chúng ta:

terraform import aws_s3_bucket.legacy_data my-existing-bucket-nameĐược hỗ trợ bởi

Terraform truy xuất thuộc tính hiện tại của bucket từ API provider và ghi chúng vào state. Bạn sẽ thấy:

aws_s3_bucket.legacy_data: Import complete! 
Imported aws_s3_bucketĐược hỗ trợ bởi

State giờ đã có tài nguyên, nhưng cấu hình của bạn vẫn trống hoặc chưa hoàn chỉnh.

Đây là lúc công việc thực sự bắt đầu: đồng bộ mã với state đã import.

Hòa giải cấu hình

Chạy terraform plan để xem khác biệt giữa state và cấu hình. Bạn sẽ thấy thuộc tính tính toán (giá trị chỉ đọc như timestamp) và các yêu cầu cấu hình rõ ràng bạn cần khai báo.

Cập nhật cấu hình dần dần bằng cách dùng giá trị từ đầu ra plan. Nếu plan đề xuất "thay thế" tài nguyên, hãy dừng lại. Điều đó cho thấy không khớp các tham số bất biến, như vùng hoặc AZ. Điều chỉnh cấu hình để khớp các thuộc tính bất biến của tài nguyên hiện có.

Quy Trình Cốt Lõi B: Import Block của Terraform

Giờ hãy khám phá cách tiếp cận hiện đại được giới thiệu trong Terraform 1.5. Import block biến import từ lệnh theo kiểu mệnh lệnh thành cấu hình khai báo nằm cạnh mã hạ tầng của bạn.

Lợi thế then chốt là khả năng tái lập và minh bạch cho nhóm. Với CLI, không có bản ghi mã về những gì đã import. Với import block, mọi import đều được ghi chép, quản lý phiên bản, và có thể rà soát qua pull request.

Hãy bắt đầu bằng việc tạo chính import block.

Định nghĩa import block

Một import block có hai thành phần: to (địa chỉ đích) và id (định danh tài nguyên):

import {
  to = aws_instance.web_server
  id = "i-0123456789abcdef0"
}Được hỗ trợ bởi

Điều này mang lại khả năng hiển thị trong kiểm soát phiên bản. Nhóm có thể rà soát import block trong pull request trước khi thực thi. Đặt các import block trong imports.tf để dễ dọn dẹp sau khi import thành công.

Và đây là nơi import block thực sự tỏa sáng: Terraform có thể tự động sinh mã cấu hình cho bạn, loại bỏ việc đoán mò tẻ nhạt khi viết HCL từ đầu.

Sinh cấu hình (Terraform 1.5+)

Import block cho phép sinh cấu hình tự động. Chạy terraform plan -generate-config-out=generated.tf để lập kế hoạch import và đồng thời ghi toàn bộ mã HCL.

Tệp được sinh chứa mọi thuộc tính với giá trị hiện tại. Hãy rà soát, loại bỏ các mặc định dài dòng, và trộn phần cấu hình có ý nghĩa vào codebase. Điều này ngăn lỗi phổ biến: sai tên thuộc tính, sai kiểu, và thiếu trường bắt buộc. Đặc biệt với tài nguyên phức tạp, điều này rất giá trị.

Khi cấu hình đã sẵn sàng, đến lúc thực thi import.

Áp dụng và hoàn tất

Cuối cùng, chạy terraform apply để thực thi import và đồng bộ state với cấu hình. Terraform sẽ hiển thị chính xác những gì được import trước khi sửa đổi tệp state.

Sau khi áp dụng thành công, hãy xóa các import block khỏi cấu hình. Chúng đã hoàn thành nhiệm vụ, và giữ lại sẽ gây nhầm lẫn cho các lần chạy sau. Cuối cùng, chạy terraform plan thêm lần nữa để xác nhận không còn thay đổi, bảo đảm cấu hình và state đã đồng bộ hoàn hảo.

Các quy trình trên hoạt động hoàn hảo cho tài nguyên đơn giản, độc lập. Nhưng hạ tầng sản xuất hiếm khi đơn giản như vậy. Hãy xử lý độ phức tạp thực tế của module, vòng lặp, và phụ thuộc.

Terraform Import cho Tài Nguyên Phức Tạp và Module

Hạ tầng thực tế hiếm khi gồm những tài nguyên đơn lẻ, đơn giản. Tài nguyên do module quản lý yêu cầu cú pháp địa chỉ đặc biệt, đây là thách thức đầu tiên của chúng ta.

Import vào module con

Tài nguyên trong module yêu cầu địa chỉ đường dẫn đầy đủ: module.<module_name>.<resource_type>.<resource_name>, ví dụ như sau:

terraform import module.network.aws_vpc.main vpc-0abcdef123456789Được hỗ trợ bởi

Để tìm địa chỉ đúng, dùng terraform state list sau một lần apply bình thường. Lệnh này cho bạn thấy chính xác Terraform tham chiếu tài nguyên module như thế nào. Địa chỉ sai sẽ tạo mục state trùng lặp, và Terraform sẽ cố tạo lại ở lần apply tiếp theo.

Ngoài ra, khi import vào instance module có count hoặc for_each, bạn cần bao gồm định danh instance trong dấu nháy:

terraform import 'module.network[0].aws_vpc.main' vpc-0abcdef123456789Được hỗ trợ bởi

Ngoài địa chỉ module, các tài nguyên dùng meta-argument count hoặc for_each cũng có thách thức riêng.

Xử lý count và for_each

Khi cấu hình Terraform dùng count để tạo nhiều instance của một tài nguyên, bạn sẽ cần cú pháp mảng cho import. Ví dụ, nếu cấu hình như sau:

resource "aws_instance" "server" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}Được hỗ trợ bởi

Bạn sẽ import từng instance theo chỉ số:

terraform import 'aws_instance.server[0]' i-0123456789abcdef0
terraform import 'aws_instance.server[1]' i-1234567890abcdef1
terraform import 'aws_instance.server[2]' i-2345678901abcdef2Được hỗ trợ bởi

Ngược lại, tài nguyên dùng for_each trong cấu hình yêu cầu khóa dạng chuỗi. Xem ví dụ sau:

resource "aws_instance" "server" {
  for_each      = toset(["web", "api", "worker"])
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}Được hỗ trợ bởi

Ở đây, bạn sẽ import theo tên khóa:

terraform import 'aws_instance.server["web"]' i-0123456789abcdef0
terraform import 'aws_instance.server["api"]' i-1234567890abcdef1
terraform import 'aws_instance.server["worker"]' i-2345678901abcdef2Được hỗ trợ bởi

Nếu gặp lỗi "index out of range", nghĩa là giá trị count của bạn không khớp số lượng tài nguyên đang import. Cách khắc phục rất đơn giản: đặt đúng count hoặc định nghĩa khóa for_each phù hợp trong cấu hình trước khi chạy import.

Hơn nữa, bạn cần suy nghĩ về mối quan hệ giữa các tài nguyên, đặc biệt khi kiến trúc phức tạp.

Quản lý phụ thuộc và tác dụng phụ

Một số tài nguyên đám mây không import dưới dạng thực thể đơn lẻ. Thay vào đó, chúng import thành nhiều tài nguyên Terraform: Ví dụ phổ biến gồm:

• Quy tắc security group
• Gắn chính sách IAM
• Quy tắc Network ACL

Trong các trường hợp này, luôn import tài nguyên “cha” trước. Chẳng hạn, import VPC trước subnet, IAM role trước policy attachment, và security group trước các quy tắc riêng lẻ. Điều này thiết lập chuỗi phụ thuộc đúng trong tệp state.

Sau khi import, hãy rà soát cấu hình và khai báo phụ thuộc rõ ràng bằng depends_on nơi provider không tự nhận biết. Điều này đảm bảo các lần apply sau thực thi theo thứ tự đúng, tránh lỗi như Terraform cố tạo subnet trước khi VPC tồn tại.

Khi tài nguyên đã import thành công và cấu hình đúng, giai đoạn tiếp theo tập trung vào bảo trì dài hạn và tổ chức.

Quản Lý State và Tái Cấu Trúc

Import tài nguyên chỉ là điểm khởi đầu. Thành công dài hạn đòi hỏi quản lý state đúng cách và đôi khi phải tái cấu trúc.

Bảo mật nên là mối quan tâm đầu tiên khi import tài nguyên sản xuất.

Bảo vệ state nhạy cảm

Đây là điều khiến nhiều đội ngũ bất ngờ: import cơ sở dữ liệu hoặc khóa mã hóa sẽ kéo các giá trị nhạy cảm, như mật khẩu, khóa riêng, và chuỗi kết nối, vào tệp state ở dạng văn bản thuần. Đây là cân nhắc bảo mật quan trọng bạn phải xử lý ngay.

Giải pháp là dùng backend từ xa mã hóa. Với AWS, nghĩa là S3 với tùy chọn encrypt = true và tùy chọn bật KMS. Với Azure, dùng Azure Storage với mã hóa khi lưu trữ. Nếu dùng HCP Terraform / Terraform Cloud, state được mã hóa khi lưu và khi truyền theo mặc định, nhưng bạn vẫn nên xác minh kiểm soát truy cập.

Thêm nữa, sau khi import tài nguyên sản xuất có dữ liệu nhạy cảm, thực hiện hai bước bổ sung: xác minh kiểm soát truy cập nơi lưu state được cấu hình đúng, và bật nhật ký kiểm toán để theo dõi ai truy cập state và khi nào. Những biện pháp này tạo vết kiểm toán bảo mật vô giá cho tuân thủ.

Khi hạ tầng phát triển, bạn sẽ muốn tổ chức lại và đổi tên tài nguyên đã import.

Tái cấu trúc tài nguyên đã import

Bạn có hai lựa chọn để đổi tên tài nguyên: terraform state mv (mệnh lệnh) hoặc block moved (khai báo). Tôi ưu tiên block moved vì chúng ghi chép thay đổi trong lịch sử kiểm soát phiên bản:

moved {
  from = aws_instance.old_name
  to   = aws_instance.new_name
}Được hỗ trợ bởi

Ngoài đổi tên, bạn cũng nên thay thế ID hard-code bằng tham chiếu tài nguyên. Thay vì vpc_id = "vpc-123456", hãy dùng vpc_id = aws_vpc.main.id. Cách tiếp cận này xây dựng đồ thị phụ thuộc đúng để Terraform xác định thứ tự thao tác.

Mảnh ghép cuối cùng của quản lý state là ngăn ngừa drift trong tương lai.

Gia cố chống drift

Sau khi import, chính sách quan trọng nhất cần thiết lập là: mọi thay đổi phải qua Terraform, không qua console đám mây. Đây là cách duy nhất ngăn drift giữa mã và thực tế.

Tuy nhiên, một số thuộc tính trôi dạt liên tục nhưng không cần quản lý. Với những thuộc tính đó, dùng tham số vòng đời ignore_changes:

lifecycle {
  ignore_changes = [tags["LastModified"]]
}Được hỗ trợ bởi

Cuối cùng, thiết lập tiêu chuẩn "kế hoạch sạch" nơi terraform plan chỉ hiển thị các thay đổi có chủ đích. Hãy tạo thói quen chạy plan thường xuyên, ngay cả khi bạn không triển khai, để phát hiện drift sớm trước khi thành vấn đề lớn.

Khắc Phục Sự Cố Lỗi Terraform Import Phổ Biến

Dù đã chuẩn bị kỹ, thao tác import vẫn có thể thất bại. Hãy chẩn đoán và giải quyết những vấn đề thường gặp nhất.

Sai địa chỉ và sai ID là vấn đề thường gặp nhất.

Giải quyết lỗi địa chỉ và ID

Dưới đây là những lỗi import phổ biến và cách khắc phục:

Resource address does not exist

• Nguyên nhân: Terraform không tìm thấy resource block trong cấu hình
• Cách khắc phục cho import bằng CLI: Tạo một resource block trống trước khi chạy lệnh
• Cách khắc phục cho import block: Kiểm tra lỗi chính tả ở địa chỉ to hoặc đường dẫn module không đúng

Cannot import non-existent remote object

• Nguyên nhân: Sai định dạng ID hoặc sai vùng/subscription của provider
• Khắc phục: Xác minh cấu hình provider trỏ đến đúng vùng AWS, subscription Azure, hoặc dự án GCP
• Cũng cần kiểm tra: Định dạng ID tài nguyên trong tài liệu của provider

Resource already managed

• Nguyên nhân: Mục state trùng lặp. Tài nguyên đã được theo dõi dưới tên khác

• Khắc phục: Chạy terraform state list để tìm bản trùng, sau đó dùng terraform state rm để xóa mục cũ trước khi import lại

Ngăn thay thế ngoài ý muốn

Sau khi import thành công, hãy cảnh giác với các plan muốn thay thế tài nguyên.

Nếu terraform plan hiển thị "forces replacement" sau import, bạn cần xác định tham số nào gây tái tạo. Nguyên nhân thường gặp là tham số bất biến như AMI ID của EC2 hoặc availability zone. Những tham số này không thể đổi sau khi tạo tài nguyên.

Cách khắc phục rất rõ ràng: căn chỉnh cấu hình để khớp thực tế. Sao chép giá trị thực tế từ đầu ra plan vào tệp cấu hình của bạn. 

Và đây là quy tắc an toàn trọng yếu: không bao giờ xác nhận hoặc áp dụng nếu plan đề xuất hủy tài nguyên quan trọng. Đó là dấu hiệu cảnh báo có điều gì đó sai.

Xử lý vấn đề từ provider

Đôi khi vấn đề không nằm ở cấu hình của bạn, mà ở cách các provider được cấu hình.

Lỗi "Provider configuration depends on non-var" xảy ra khi provider của bạn chặn việc dùng giá trị tính toán trong quá trình import. Terraform cần cấu hình provider tĩnh để định vị tài nguyên cần import.

Giải pháp tạm thời là hard-code: thay thiết lập provider động bằng giá trị literal, chạy import, rồi khôi phục cấu hình động sau đó. Hoặc, bạn có thể dùng biến môi trường cho xác thực provider, thứ mà Terraform có thể giải quyết trong quá trình import.

Nếu ID tài nguyên có vẻ đúng nhưng import vẫn thất bại, hãy kiểm tra mục "Import" trong tài liệu provider để biết yêu cầu định dạng ID chính xác. Một số tài nguyên dùng ID phức hợp với dấu gạch chéo hoặc hai chấm làm ký tự phân tách, và nhập đúng định dạng là tối quan trọng.

Kết Luận

Bạn đã học cách đưa hạ tầng hiện có vào quản lý bởi Terraform bằng cả lệnh CLI và import block. Trước mỗi lần import, hãy theo danh sách kiểm tra an toàn này:

• Xác minh ID tài nguyên đúng theo provider của bạn
• Sao lưu tệp state (bật versioning trên backend từ xa)
• Rà soát plan cẩn thận để phát hiện thay thế ngoài ý muốn
• Đảm bảo bạn đang ở đúng workspace/môi trường
• Thử nghiệm với tài nguyên không quan trọng trước

Tuy nhiên, import không kết thúc ở terraform apply. Công việc thực sự bắt đầu sau đó: thiết lập chính sách ngăn drift, tái cấu trúc tài nguyên đã import để nhất quán với tiêu chuẩn của bạn, và đào tạo đội ngũ về việc quản lý hạ tầng chỉ qua mã. Sự chuyển đổi văn hóa này quan trọng không kém phần triển khai kỹ thuật.

Bước tiếp theo, tôi khuyến nghị khám phá thao tác state của Terraform với terraform state mv và terraform state rm. Những lệnh này bổ trợ cho import bằng cách giúp bạn tổ chức lại và tái cấu trúc tệp state khi hạ tầng phát triển.

Tôi cũng khuyến nghị xem hướng dẫn về sử dụng Terraform với Docker, và chuẩn bị cho buổi phỏng vấn tiếp theo với các câu hỏi phỏng vấn Terraform hàng đầu.