Impor Infrastruktur yang Sudah Ada ke Terraform Tanpa Menulis HCL Manual

Hampir setiap pekerjaan infrastruktur yang saya ambil dimulai dengan masalah yang sama: sesuatu sudah ada. Load balancer yang dibuat lewat konsol dua tahun lalu, database yang dibuat saat insiden, zona DNS yang tidak ada yang ingat pernah menyentuhnya. Terraform paling senang dengan greenfield, tapi kenyataan hidup adalah brownfield. Pertanyaannya bukan apakah harus membawa infrastruktur yang sudah ada ke Terraform — tapi berapa banyak rasa sakit yang dibebankan migrasi itu.

Selama bertahun-tahun jawabannya adalah: banyak. Perintah CLI terraform import lama hanya menulis resource ke dalam state — tidak pernah menghasilkan konfigurasi yang cocok. Anda mengimpor resource, lalu menulis HCL manual, lalu menjalankan plan dan berdoa diff kembali kosong. Untuk apa pun yang lebih dari segelintir resource, loop itu melelahkan dan rawan kesalahan. Sejak Terraform 1.5, import block plus flag -generate-config-out mengubah bentuk pekerjaan itu sepenuhnya.

Cara lama dan mengapa itu menyakitkan

Impor CLI klasik bersifat imperatif: Anda menjalankan perintah, ia langsung memutasi state, dan tidak meninggalkan jejak di konfigurasi atau pull request Anda. Dua masalah muncul dari situ. Pertama, tidak ada yang bisa direview — rekan tim tidak bisa melihat di diff apa yang Anda impor. Kedua, Anda tetap harus menulis sendiri setiap argumen resource, mencocokkan apa pun yang sebenarnya dimiliki penyedia cloud, atau plan berikutnya menampilkan perubahan destruktif.

# The old imperative way — state changes instantly, no config generated
terraform import aws_instance.web i-0abc123def456

# Now you STILL have to hand-write this block to match reality:
resource "aws_instance" "web" {
  # ...guess every argument, or the next plan wants to destroy it
}

Import block: impor yang config-driven

Import block adalah blok Terraform biasa yang Anda commit ke file .tf. Ia menamai alamat resource tempat objek yang diimpor akan berada (argumen to) dan ID spesifik-penyedia dari objek yang sudah ada (argumen id). Karena ia berada di konfigurasi Anda, ia muncul di terraform plan, melewati code review, dan tidak ada yang menyentuh state sampai terraform apply. Itulah keseluruhan pergeserannya: impor menjadi deklaratif dan bisa direview alih-alih perintah konsol sekali pakai.

# imports.tf — declarative, reviewable, applied on `terraform apply`
import {
  to = aws_instance.web
  id = "i-0abc123def456"
}

import {
  to = aws_s3_bucket.assets
  id = "my-company-assets"
}

-generate-config-out: berhenti menulis HCL manual

Import block sendirian masih mengasumsikan blok resource yang cocok sudah ada. Keajaibannya adalah flag -generate-config-out, diperkenalkan bersama import block di Terraform 1.5 dan masih berlabel eksperimental. Arahkan terraform plan ke path file baru dan Terraform membaca objek live untuk setiap import block yang belum punya resource cocok, lalu menulis HCL dengan tebakan terbaiknya untuk tiap argumen. Anda mendapat scaffold, bukan modul jadi — tapi scaffold lebih baik daripada file kosong.

# Point at a NEW file path — Terraform errors if the file already exists
terraform plan -generate-config-out="generated.tf"

# Terraform reads each imported object and writes something like:
resource "aws_instance" "web" {
  ami                    = "ami-0abc1234"
  instance_type          = "t3.medium"
  availability_zone      = "ap-southeast-1a"
  vpc_security_group_ids = ["sg-0123456789"]
  subnet_id              = "subnet-0abc123"
  # ...every discoverable argument, filled in for you
}

1. Tulis import block untuk resource yang Anda inginkan, dengan alamat to dan id yang benar.
2. Jalankan terraform plan -generate-config-out=generated.tf terhadap path file yang baru.
3. Baca HCL yang dihasilkan, hapus argumen read-only dan default, lalu refactor nama.
4. Jalankan terraform plan lagi sampai diff kosong — tanpa create, tanpa destroy.
5. terraform apply untuk meng-commit objek ke state, lalu hapus import block.

HCL yang dihasilkan adalah draf, bukan hasil akhir

Jangan commit output -generate-config-out tanpa disentuh. Terraform cenderung ke arah kelengkapan, jadi ia memancarkan atribut read-only, nilai computed, dan default yang mengacaukan file atau justru merusak plan. Dokumentasinya menyebut contoh konkret: ia bisa menghasilkan baik ipv6_address_count maupun ipv6_addresses pada sebuah instance meski kedua argumen itu berkonflik, menghasilkan HCL yang tidak akan lolos validasi. Perlakukan file itu sebagai draf pertama yang Anda bersihkan.

• Hapus argumen yang ditandai penyedia sebagai read-only atau computed (ID, ARN, timestamp).
• Hapus default yang menambah kebisingan, agar konfigurasi menyatakan maksud, bukan tiap tombol.
• Ganti ID hard-coded dengan referensi ke resource lain atau variabel jika memungkinkan.
• Ganti label resource ke konvensi Anda — nama yang dihasilkan hanyalah alamat to.

Alur kerja yang menskala melampaui segelintir resource

Pada migrasi baru-baru ini saya punya beberapa lusin objek untuk dibawa masuk lintas satu penyedia. Pola yang berhasil: enumerasi ID nyata dengan CLI penyedia, buat template satu import block per ID ke imports.tf, lalu jalankan satu pass generate. Anda mereview file yang dihasilkan dalam satu duduk, membersihkannya, dan mendaratkannya sebagai satu PR yang bisa direview — jauh lebih baik daripada loop shell dari perintah terraform import yang tidak bisa diaudit siapa pun setelahnya.

# Enumerate real IDs, then template import blocks (AWS S3 buckets example)
aws s3api list-buckets --query 'Buckets[].Name' --output text \
  | tr '\t' '\n' \
  | while read -r b; do
      printf 'import {\n  to = aws_s3_bucket.%s\n  id = "%s"\n}\n\n' \
        "$(echo "$b" | tr '.-' '__')" "$b"
    done > imports.tf

terraform plan -generate-config-out=generated.tf

Jebakan yang terus saya temui

• Path output harus baru. Terraform error alih-alih menimpa file yang ada — hapus generated.tf antar-run.
• Mendapatkan id yang benar bersifat spesifik-penyedia. Bucket S3 pakai namanya, instance EC2 pakai instance ID-nya, record route53 pakai string komposit — cek dokumen impor resource tersebut.
• Generasi config masih eksperimental; format HCL persisnya bisa berubah antar-versi minor, jadi review ulang setelah upgrade.
• Impor ke modul atau instance for_each? Generate terhadap alamat top-level dulu, lalu pindahkan HCL yang sudah dibersihkan ke modul secara manual.