Terraform Import: Membawa Infrastruktur yang Sudah Ada ke Dalam Kode

Tim Anda telah menerapkan sumber daya cloud selama bertahun-tahun melalui klik konsol dan skrip shell. Kini Anda ingin mengadopsi Infrastructure as Code, tetapi membuat ulang semuanya dari nol terasa berat. Saya pernah berada dalam situasi ini, dan fungsionalitas import Terraform adalah solusi untuk tantangan ini.

Risiko "ClickOps" dan pengelolaan infrastruktur manual akan bertambah seiring waktu. Sumber daya menjadi tidak terdokumentasi, konfigurasi melenceng dari standar, dan pengetahuan tribal menggantikan dokumentasi yang semestinya. Saat anggota tim pergi, keputusan infrastruktur mereka ikut pergi bersama mereka. 

Inilah alasan organisasi mengadopsi Infrastructure as Code (IaC). Dalam tutorial ini, saya akan memandu Anda mengimpor infrastruktur yang sudah ada ke Terraform. 

Kita akan membandingkan perintah import berbasis CLI dengan import block deklaratif yang diperkenalkan di Terraform 1.5, mengeksplorasi alur kerja praktis untuk kedua pendekatan, dan mengatasi jebakan umum yang dapat mengubah import sederhana menjadi insiden produksi. Pada akhirnya, Anda akan percaya diri membawa infrastruktur yang sudah ada ke dalam pengelolaan berbasis kode. 

Jika Anda baru dalam IaC dan penyedia cloud, pertimbangkan untuk mengambil salah satu kursus kami, seperti AWS Concepts, Understanding Cloud Computing, atau Understanding Microsoft Azure. 

Apa Itu Terraform Import?

Saat Anda membuat infrastruktur dengan Terraform sejak awal, semuanya berjalan mulus. Anda menulis konfigurasi, menjalankan terraform plan, meninjau perubahan, lalu menerapkannya. Terraform melacak semuanya di berkas state, menciptakan peta sempurna antara kode Anda dan sumber daya cloud Anda. 

Namun bagaimana jika sumber daya sudah ada di luar pengetahuan Terraform? Mari mulai dengan memahami apa sebenarnya fungsi import dan mengapa ia ada.

Definisi inti dan tujuannya

Terraform import memetakan infrastruktur nyata yang sudah ada ke entri dalam berkas state Terraform tanpa membuat sumber daya baru. Anggap ini sebagai adopsi: Anda memberi tahu Terraform untuk mulai mengelola sumber daya yang sudah berjalan.

Ini menyelesaikan masalah "shadow IT". Organisasi mengumpulkan infrastruktur melalui berbagai cara: penerapan via konsol saat gangguan, sumber daya uji yang menjadi permanen, atau sistem lama yang sudah ada sebelum adopsi IaC. Import merekonsiliasi realitas ini dengan prinsip Infrastructure as Code.

Bagian pentingnya adalah: import utamanya merupakan operasi terhadap state. Ia tidak otomatis menulis kode konfigurasi kecuali Anda menggunakan fitur generasi pada Terraform 1.5+. Anda bertanggung jawab memastikan konfigurasi HCL mencerminkan sumber daya yang diimpor secara akurat.

Sekarang setelah kita memahami apa yang dilakukan import, mari telusuri kapan Anda sebaiknya menggunakannya dan kapan tidak.

Terraform import vs. alternatif

Saya merekomendasikan import untuk tiga skenario utama:

• Memigrasikan infrastruktur lama yang tidak bisa dibuat ulang tanpa downtime signifikan atau kehilangan data. Contohnya basis data produksi dengan data bertahun-tahun, atau load balancer yang melayani trafik langsung.
• Pemulihan dari berkas state yang hilang, yang bisa terjadi bahkan dengan backend jarak jauh jika pencadangan tidak dikonfigurasi dengan benar.
• Mengikutsertakan perubahan manual yang entah bagaimana melewati proses manajemen perubahan Anda, mungkin perbaikan darurat saat terjadi gangguan.

Namun, import tidak selalu menjadi pilihan tepat. Untuk sumber daya uji sementara atau infrastruktur dengan standardisasi buruk, saya sering menyarankan membuat ulang secara bersih. 

Memulai dari awal memungkinkan Anda menerapkan praktik terbaik saat ini, menerapkan konvensi penamaan yang tepat, dan menambahkan konfigurasi keamanan yang mungkin tidak dimiliki sumber daya lama. Upaya awal untuk membuat ulang sering kali terbayar dalam hal kemudahan pemeliharaan jangka panjang.

Penting untuk membedakan import dari data source Terraform. Data source memungkinkan Anda mereferensikan informasi read-only dari infrastruktur yang sudah ada tanpa mengelolanya. Misalnya, Anda bisa menggunakan data source untuk mencari VPC yang sudah ada yang dibuat oleh tim lain, lalu menerapkan sumber daya Anda ke dalamnya. 

Sebaliknya, import membawa sumber daya ke dalam pengelolaan penuh Terraform, termasuk kemampuan untuk memodifikasi atau menghancurkannya. Pilih import ketika Anda perlu mengelola seluruh siklus hidup sumber daya, bukan sekadar mereferensikannya.

Sebelum mulai mengimpor, ada beberapa batasan mendasar yang perlu Anda pahami.

Batasan kunci dan dasar-dasarnya

Setiap sumber daya yang diimpor memerlukan pengenal unik spesifik penyedia. Untuk AWS, ini bisa berupa i-0123456789abcdef0. Untuk Azure, berupa path sumber daya lengkap seperti /subscriptions/{id}/resourceGroups/{rg}/providers/{provider}/{resource}. Salah di sini adalah penyebab utama kegagalan import.

Operasi import secara langsung memodifikasi berkas state Anda, jadi pencadangan sangat penting. Jika menggunakan backend berversi seperti S3, pastikan versioning diaktifkan. Dengan state lokal, salin manual ke terraform.tfstate.backup.

Setelah import, Anda akan menemui "drift": ketidakcocokan antara state yang diimpor dan konfigurasi lokal. Anda akan memperbarui kode HCL secara iteratif hingga terraform plan menunjukkan nol perubahan tertunda.

Prasyarat dan Persiapan untuk Terraform Import 

Sebelum mengimpor apa pun, pastikan Anda siap untuk sukses. Saya telah melihat import gagal karena tim melewatkan langkah-langkah persiapan.

Langkah pertama Anda adalah memastikan lingkungan Terraform dikonfigurasi dengan benar.

Validasi lingkungan

Mulailah dengan memverifikasi instalasi Terraform Anda dengan terraform version. Jika Anda ingin mengakses import block deklaratif dan pembuatan kode otomatis, pastikan Anda menggunakan Terraform 1.5 atau yang lebih baru. Fitur ini sangat menyederhanakan proses import untuk sumber daya yang kompleks.

Sebelum mengimpor, verifikasi prasyarat berikut:

• Kredensial provider aktif: Untuk AWS, periksa bahwa AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY disetel, atau profil AWS CLI Anda dikonfigurasi. Uji dengan aws sts get-caller-identity.

• Workspace yang benar dipilih: Jalankan terraform workspace show untuk memastikan Anda tidak secara tidak sengaja mengimpor ke lingkungan yang salah.

• Berkas state tidak terkunci: Koordinasikan dengan anggota tim dan periksa pipeline CI/CD untuk memastikan tidak ada operasi bersamaan.

• Backend dapat diakses: Jika menggunakan state jarak jauh, verifikasi konektivitas ke S3, Azure Storage, atau Terraform Cloud.

Berkas state yang terkunci akan menyebabkan import Anda gagal seketika dengan error pengambilan kunci (lock), jadi langkah koordinasi ini krusial dalam lingkungan tim.

Dengan lingkungan tervalidasi, langkah penting berikutnya adalah menemukan pengenal tepat untuk sumber daya yang ingin Anda impor.

Menemukan ID sumber daya

ID sumber daya sangat bervariasi menurut penyedia dan jenis sumber daya, sehingga langkah ini lebih rumit dari kelihatannya. Berikut contoh dari penyedia umum:

Untuk sumber daya AWS, Anda dapat menemukan ID langsung di konsol. Buka layanan (EC2, S3, dll.), pilih sumber daya Anda, dan salin pengenal dari panel detail.

Untuk Azure, gunakan Azure CLI untuk mengambil path sumber daya lengkap:

az resource show --name myresource --resource-group mygroup

Output menyertakan ID sumber daya lengkap yang Anda perlukan untuk import.

Berikut jebakan umum yang pernah saya alami: mencoba mengimpor sumber daya dari region atau subscription yang salah. Jika konfigurasi provider Terraform Anda mengarah ke us-east-1 tetapi instans EC2 Anda berada di us-west-2, import akan gagal dengan error "resource not found" meski ID instans Anda benar. 

Selalu verifikasi cakupan sesuai dengan konfigurasi provider Anda sebelum melanjutkan. Setelah Anda memiliki ID yang benar, Anda perlu memutuskan metode import yang akan digunakan.

Memilih strategi import

Ada dua jalur: perintah CLI terraform import atau import block. Berikut perbandingannya:

Saya merekomendasikan import block untuk tim yang memerlukan code review dan rencana yang dapat direproduksi, serta CLI untuk perbaikan cepat pada versi lama.

Mengapa ini penting? Import block memperlakukan adopsi infrastruktur sebagai kode, artinya import Anda menjadi bagian dari alur kerja yang dikendalikan versi dengan ketelitian yang sama seperti perubahan infrastruktur lainnya. Ini mengurangi risiko kesalahan dan menciptakan jejak audit yang penting untuk kepatuhan dan koordinasi tim. 

Import block terintegrasi mulus dengan alur kerja Git Anda, memungkinkan rekan tim meninjau dan menyetujui import layaknya perubahan infrastruktur lainnya. CLI, meski lebih cepat untuk tugas individual, tidak meninggalkan jejak audit dan tidak mudah direproduksi lintas lingkungan.

Dengan strategi dipilih, mari selami setiap alur kerja secara detail, dimulai dengan pendekatan CLI tradisional.

Alur Kerja Inti A: Perintah CLI Terraform Import

Saya akan memandu Anda melalui proses import berbasis CLI tradisional. Meskipun import block deklaratif kini semakin disukai, memahami metode CLI tetap berharga untuk versi Terraform lama dan import cepat, sekali jalan.

Langkah pertama dalam alur kerja CLI adalah menyiapkan berkas konfigurasi Anda.

Menyiapkan destination block

Sebelum menjalankan terraform import, Anda harus mendefinisikan resource block dalam konfigurasi Anda. Ini adalah persyaratan mutlak: Terraform perlu tahu ke mana memetakan state yang diimpor. Blok tersebut boleh kosong atau diisi sebagian.

Berikut contoh untuk mengimpor bucket AWS S3:

resource "aws_s3_bucket" "legacy_data" {
  # Configuration to be filled after import
}

Jenis sumber daya (aws_s3_bucket) harus persis cocok dengan jenis infrastruktur yang Anda impor. Nama sumber daya (legacy_data) sebaiknya mengikuti konvensi penamaan proyek Anda. Gunakan nama deskriptif seperti production_data_bucket alih-alih bucket1 yang generik.

Dengan resource block siap, Anda dapat menjalankan perintah import.

Menjalankan import

Jalankan terraform import <resource_address> <resource_id>. Untuk bucket S3 kita:

terraform import aws_s3_bucket.legacy_data my-existing-bucket-name

Terraform mengambil atribut bucket saat ini dari API provider dan mencatatnya dalam state. Anda akan melihat:

aws_s3_bucket.legacy_data: Import complete! 
Imported aws_s3_bucket

State kini memuat sumber daya tersebut, tetapi konfigurasi Anda tetap kosong atau belum lengkap.

Di sinilah pekerjaan sesungguhnya dimulai: menyelaraskan kode Anda dengan state yang diimpor.

Menyelaraskan konfigurasi

Jalankan terraform plan untuk melihat perbedaan antara state dan konfigurasi. Anda akan melihat atribut yang dihitung (nilai read-only seperti cap waktu) dan kebutuhan konfigurasi eksplisit yang perlu Anda deklarasikan.

Perbarui konfigurasi Anda secara bertahap menggunakan nilai dari output plan. Jika plan mengusulkan "mengganti" sumber daya, hentikan. Ini menandakan ketidakcocokan argumen yang tidak dapat diubah, seperti region atau availability zone. Sesuaikan konfigurasi Anda agar sesuai dengan atribut tidak berubah dari sumber daya yang ada.

Alur Kerja Inti B: Terraform Import Block

Sekarang mari jelajahi pendekatan modern yang diperkenalkan di Terraform 1.5. Import block mengubah import dari perintah imperatif menjadi konfigurasi deklaratif yang hidup berdampingan dengan kode infrastruktur Anda.

Keunggulan utamanya adalah reprodusibilitas dan visibilitas tim. Dengan import melalui CLI, tidak ada rekam kode tentang apa yang diimpor. Dengan import block, setiap import didokumentasikan, diberi versi, dan dapat ditinjau melalui pull request.

Mari mulai dengan membuat import block itu sendiri.

Mendefinisikan import block

Sebuah import block memiliki dua komponen: to (alamat target) dan id (pengenal sumber daya):

import {
  to = aws_instance.web_server
  id = "i-0123456789abcdef0"
}

Ini memberikan visibilitas dalam kontrol versi. Tim dapat meninjau import block dalam pull request sebelum dieksekusi. Tempatkan import block di imports.tf untuk memudahkan pembersihan setelah import berhasil.

Namun di sinilah import block benar-benar unggul: Terraform dapat secara otomatis menghasilkan kode konfigurasi untuk Anda, menghilangkan kerja menebak yang membosankan saat menulis HCL dari nol.

Menghasilkan konfigurasi (Terraform 1.5+)

Import block memungkinkan pembuatan konfigurasi otomatis. Jalankan terraform plan -generate-config-out=generated.tf untuk merencanakan import dan sekaligus menulis HCL lengkap.

Berkas yang dihasilkan memuat setiap atribut dengan nilainya saat ini. Tinjau, hapus default yang verbos, dan gabungkan konfigurasi yang bermakna ke basis kode Anda. Ini mencegah kesalahan umum: nama atribut keliru, tipe salah, dan field wajib yang hilang. Terutama untuk sumber daya kompleks, ini sangat berharga.

Dengan konfigurasi siap, saatnya mengeksekusi import.

Menerapkan dan finalisasi

Terakhir, jalankan terraform apply untuk mengeksekusi import dan menyelaraskan state dengan konfigurasi. Terraform akan menunjukkan dengan tepat apa yang diimpor sebelum melakukan perubahan pada berkas state Anda.

Setelah berhasil, hapus import block dari konfigurasi Anda. Tugasnya sudah selesai, dan menyimpannya akan membingungkan eksekusi di masa depan. Terakhir, jalankan terraform plan sekali lagi untuk memverifikasi nol perubahan tertunda, memastikan konfigurasi dan state Anda tersinkronisasi sempurna.

Alur kerja yang telah kita bahas sejauh ini bekerja sempurna untuk sumber daya sederhana dan berdiri sendiri. Namun infrastruktur produksi jarang sesederhana itu. Mari tangani kompleksitas dunia nyata pada modul, iterasi, dan dependensi.

Terraform Import untuk Sumber Daya Kompleks dan Modul

Infrastruktur dunia nyata jarang terdiri dari sumber daya sederhana yang berdiri sendiri. Sumber daya yang dikelola modul memerlukan sintaks pengalamatan khusus, yang menjadi tantangan pertama kita.

Mengimpor ke child module

Sumber daya dalam modul memerlukan pengalamatan path penuh: module.<module_name>.<resource_type>.<resource_name>, yang bisa terlihat seperti ini:

terraform import module.network.aws_vpc.main vpc-0abcdef123456789

Untuk menemukan alamat yang benar, gunakan terraform state list setelah apply normal. Ini menunjukkan dengan tepat bagaimana Terraform mereferensikan sumber daya modul. Salah alamat akan membuat entri state duplikat, yang kemudian akan coba dibuat Terraform pada apply berikutnya.

Selain itu, saat mengimpor ke instance modul dengan count atau for_each, Anda perlu menyertakan pengenal instance dalam tanda kutip:

terraform import 'module.network[0].aws_vpc.main' vpc-0abcdef123456789

Selain pengalamatan modul, sumber daya yang menggunakan meta-argumen count atau for_each memiliki tantangan tersendiri.

Menangani count dan for_each

Ketika konfigurasi Terraform Anda menggunakan count untuk membuat beberapa instance sumber daya, Anda memerlukan sintaks array untuk import. Misalnya, jika konfigurasi Anda seperti ini:

resource "aws_instance" "server" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

Anda akan mengimpor setiap instance secara terpisah menggunakan indeksnya:

terraform import 'aws_instance.server[0]' i-0123456789abcdef0
terraform import 'aws_instance.server[1]' i-1234567890abcdef1
terraform import 'aws_instance.server[2]' i-2345678901abcdef2

Di sisi lain, sumber daya yang menggunakan for_each dalam konfigurasinya memerlukan key string. Pertimbangkan contoh berikut:

resource "aws_instance" "server" {
  for_each      = toset(["web", "api", "worker"])
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

Di sini, Anda akan mengimpor menggunakan nama key:

terraform import 'aws_instance.server["web"]' i-0123456789abcdef0
terraform import 'aws_instance.server["api"]' i-1234567890abcdef1
terraform import 'aws_instance.server["worker"]' i-2345678901abcdef2

Jika Anda menemui error "index out of range", itu berarti nilai count Anda tidak cocok dengan jumlah sumber daya yang Anda impor. Perbaikannya sederhana: tetapkan count yang benar atau tentukan key for_each yang sesuai dalam konfigurasi sebelum menjalankan import.

Selain itu, Anda perlu memikirkan bagaimana sumber daya saling terkait, terutama saat menangani arsitektur kompleks.

Mengelola dependensi dan efek samping

Beberapa sumber daya cloud tidak diimpor sebagai satu entitas. Alih-alih, mereka diimpor sebagai beberapa sumber daya Terraform: Contoh umum meliputi:

• Aturan security group
• Attachment kebijakan IAM
• Aturan Network ACL

Dalam kasus ini, selalu impor sumber daya "induk" terlebih dahulu. Misalnya, impor VPC sebelum subnet, peran IAM sebelum attachment kebijakan, dan security group sebelum aturan individual. Ini menegakkan rantai dependensi yang benar di berkas state Anda.

Setelah import, tinjau konfigurasi Anda dan deklarasikan dependensi secara eksplisit menggunakan depends_on saat provider tidak secara otomatis mendeteksinya. Ini memastikan operasi apply di masa depan dieksekusi dalam urutan yang benar, mencegah error seperti Terraform mencoba membuat subnet sebelum VPC-nya ada.

Dengan sumber daya berhasil diimpor dan dikonfigurasi dengan benar, fase berikutnya berfokus pada pemeliharaan jangka panjang dan organisasi.

Manajemen State dan Refactoring

Mengimpor sumber daya hanyalah permulaan. Keberhasilan jangka panjang memerlukan manajemen state yang tepat dan refactoring sesekali.

Keamanan harus menjadi perhatian pertama Anda saat mengimpor sumber daya produksi.

Mengamankan state yang sensitif

Berikut sesuatu yang sering mengejutkan banyak tim: mengimpor basis data atau kunci enkripsi menarik nilai sensitif, seperti kata sandi, kunci privat, dan string koneksi, ke dalam berkas state Anda sebagai teks biasa. Ini adalah pertimbangan keamanan kritis yang harus segera Anda tangani.

Solusinya adalah menggunakan backend terenkripsi. Untuk AWS, ini berarti S3 dengan opsi encrypt = true dan opsional enkripsi KMS diaktifkan. Untuk Azure, gunakan Azure Storage dengan enkripsi saat disimpan. Jika Anda menggunakan HCP Terraform / Terraform Cloud, state terenkripsi saat disimpan dan saat transit secara default, namun Anda tetap perlu memverifikasi kontrol akses.

Selain itu, setelah mengimpor sumber daya produksi dengan data sensitif, lakukan dua langkah tambahan: verifikasi bahwa kontrol akses penyimpanan state dikonfigurasi dengan benar, dan aktifkan audit logging untuk melacak siapa yang mengakses state dan kapan. Langkah ini menciptakan jejak audit keamanan yang sangat berharga untuk kepatuhan.

Seiring perkembangan infrastruktur, Anda akan ingin menata ulang dan mengganti nama sumber daya yang diimpor.

Refactoring sumber daya yang diimpor

Ada dua opsi untuk mengganti nama sumber daya: terraform state mv (imperatif) atau moved block (deklaratif). Saya lebih suka moved block karena mendokumentasikan perubahan dalam riwayat kontrol versi Anda:

moved {
  from = aws_instance.old_name
  to   = aws_instance.new_name
}

Selain mengganti nama, Anda juga sebaiknya mengganti ID yang di-hardcode dengan referensi sumber daya. Alih-alih vpc_id = "vpc-123456", gunakan vpc_id = aws_vpc.main.id. Pendekatan ini membangun grafik dependensi yang tepat yang dapat digunakan Terraform untuk menentukan urutan operasi yang benar.

Bagian terakhir dari manajemen state adalah mencegah drift di masa depan.

Memperkuat terhadap drift

Setelah import, kebijakan terpenting yang harus ditetapkan adalah: semua perubahan dilakukan melalui Terraform, bukan konsol cloud. Ini satu-satunya cara untuk mencegah drift antara kode Anda dan kenyataan.

Namun, beberapa atribut terus-menerus mengalami drift tetapi sebenarnya tidak perlu dikelola. Untuk ini, gunakan argumen lifecycle ignore_changes:

lifecycle {
  ignore_changes = [tags["LastModified"]]
}

Terakhir, tetapkan standar "clean plan" di mana terraform plan hanya menampilkan perubahan yang disengaja. Biasakan menjalankan plan secara berkala, bahkan saat Anda tidak menerapkan, untuk menangkap drift lebih awal sebelum menjadi masalah besar.

Memecahkan Masalah Umum pada Terraform Import

Terlepas dari persiapan yang matang, operasi import bisa gagal. Mari diagnosis dan selesaikan masalah paling umum yang akan Anda temui.

Ketidakcocokan alamat dan ID adalah masalah yang paling sering terjadi.

Mengatasi error alamat dan ID

Berikut error import paling umum dan solusinya:

Resource address does not exist

• Penyebab: Terraform tidak dapat menemukan resource block Anda dalam konfigurasi
• Perbaikan untuk import via CLI: Buat resource block kosong sebelum menjalankan perintah
• Perbaikan untuk import block: Periksa salah ketik pada alamat to atau path modul yang salah

Cannot import non-existent remote object

• Penyebab: Format ID salah atau region/subscription provider tidak tepat
• Perbaikan: Verifikasi konfigurasi provider mengarah ke region AWS, subscription Azure, atau proyek GCP yang benar
• Periksa juga: Format ID sumber daya di dokumentasi provider

Resource already managed

• Penyebab: Entri state duplikat. Sumber daya sudah dilacak dengan nama lain

• Perbaikan: Jalankan terraform state list untuk menemukan duplikasi, lalu gunakan terraform state rm untuk menghapus entri lama sebelum mengimpor ulang

Mencegah penggantian yang tidak disengaja

Setelah Anda berhasil mengimpor sumber daya, waspadai plan yang ingin menggantinya.

Jika terraform plan menampilkan "forces replacement" setelah import, Anda perlu mengidentifikasi argumen mana yang menyebabkan pembuatan ulang. Penyebab umum adalah argumen yang tidak dapat diubah seperti ID AMI EC2 atau availability zone. Ini tidak bisa diubah setelah sumber daya dibuat.

Perbaikannya sederhana: selaraskan konfigurasi Anda dengan kenyataan. Salin nilai aktual dari output plan ke berkas konfigurasi Anda. 

Dan ini aturan keselamatan kritis: jangan pernah melakukan konfirmasi atau apply jika ia mengusulkan untuk menghancurkan sumber daya kritis. Itu tanda peringatan bahwa ada sesuatu yang salah.

Menghadapi masalah pada provider

Terkadang masalahnya bukan pada konfigurasi Anda, melainkan pada cara provider Anda dikonfigurasi.

Error "Provider configuration depends on non-var" terjadi saat blok provider Anda menggunakan nilai yang dihitung selama import. Terraform memerlukan konfigurasi provider statis untuk menemukan sumber daya saat import.

Solusinya adalah hard-code sementara: ganti pengaturan provider dinamis dengan nilai literal, jalankan import, lalu kembalikan konfigurasi dinamis Anda setelahnya. Alternatifnya, Anda dapat menggunakan variabel lingkungan untuk autentikasi provider, yang dapat diselesaikan Terraform selama proses import.

Jika ID sumber daya Anda tampak benar tetapi import tetap gagal, periksa bagian "Import" pada dokumentasi provider untuk persyaratan format ID yang tepat. Beberapa sumber daya menggunakan ID gabungan dengan garis miring atau titik dua sebagai pemisah, dan memastikan formatnya tepat sangat penting.

Kesimpulan

Anda telah mempelajari cara membawa infrastruktur yang sudah ada ke dalam pengelolaan Terraform menggunakan perintah CLI dan import block. Sebelum setiap import, ikuti daftar periksa keselamatan berikut:

• Verifikasi ID sumber daya sesuai dengan provider Anda
• Cadangkan berkas state Anda (aktifkan versioning pada backend jarak jauh)
• Tinjau plan dengan cermat untuk penggantian yang tidak terduga
• Pastikan Anda berada di workspace/lingkungan yang benar
• Uji dengan sumber daya nonkritis terlebih dahulu

Namun, import tidak berakhir di terraform apply. Pekerjaan sesungguhnya dimulai setelah import: menetapkan kebijakan pencegahan drift, melakukan refactoring sumber daya yang diimpor agar konsisten dengan standar Anda, dan mengedukasi tim Anda untuk mengelola infrastruktur secara eksklusif melalui kode. Pergeseran budaya ini sama pentingnya dengan implementasi teknisnya.

Untuk langkah berikutnya, saya merekomendasikan mengeksplorasi manipulasi state Terraform dengan terraform state mv dan terraform state rm. Perintah ini melengkapi import dengan membantu Anda menata ulang dan melakukan refactoring berkas state saat infrastruktur Anda berkembang.

Saya juga menyarankan untuk melihat panduan kami tentang menggunakan Terraform dengan Docker, dan mempersiapkan wawancara berikutnya dengan pertanyaan wawancara Terraform teratas.