Belajar Terraform - State Management (Local vs Remote State)

#Pendahuluan

Setelah di episode 4 sebelumnya kita membahas bagaimana input variables membuat konfigurasi fleksibel antar environment, local values menghilangkan pengulangan ekspresi, dan output values membagikan hasil kerja — pada episode kali ini kita akan membahas topik yang paling sering disalahpahami namun paling menentukan kestabilan tim: state management.

Semua contoh di episode-episode sebelumnya, tanpa kalian sadari, sedang membangun sebuah file bernama terraform.tfstate setiap kali terraform apply berjalan. File inilah yang membuat Terraform tahu bahwa instance i-0abcd1234efgh5678 di AWS "milik" resource aws_instance.web dalam kode kalian. Tanpa file ini, Terraform akan bingung: apakah harus membuat instance baru? atau instance yang sudah ada ini sudah terkelola?

Kenapa topik ini krusial di dunia kerja nyata? Karena mayoritas insiden IaC terjadi bukan karena sintaks salah, melainkan karena state: file state hilang sehingga tim terpaksa membangun ulang seluruh infrastruktur; file state bentrok karena dua orang menjalankan terraform apply bersamaan; atau file state bocor karena ter-commit ke Git bersama password database di dalamnya. Memahami state — apa isinya, bagaimana mengamankannya, dan bagaimana menyimpannya secara remote — adalah syarat mutlak sebelum kalian menyentuh infrastruktur tim mana pun.

#Pembahasan Utama

#Mengapa Terraform Membutuhkan State File?

Terraform bersifat declarative: kalian menulis kondisi akhir yang diinginkan, dan Terraform menentukan langkah untuk sampai ke sana. Tapi untuk itu, Terraform harus tahu kondisi saat ini. Sumber pengetahuan itulah state file.

Bayangkan state seperti buku besar (ledger) akuntansi atau kuitansi pembelian. Kode HCL kalian adalah "rencana belanja", sedangkan state adalah bukti "sudah dibeli apa saja, dengan ID transaksi berapa". Jika kalian membeli barang yang sama dua kali tanpa mencatat, hasilnya duplikat dan boros. Persis seperti itu: tanpa state, setiap terraform apply akan membuat EC2 instance baru lagi — karena Terraform tidak tahu bahwa instance yang dimaksud sudah pernah dibuat.

Secara teknis, state menyimpan mapping antara kode HCL dan ID riil resource di cloud:

Mapping ini adalah alasan Terraform bisa melakukan tiga hal penting: detect drift (membandingkan kondisi cloud vs state), plan yang akurat (hanya mengubah resource yang berubah), dan destroy yang tepat sasaran (menghapus resource yang benar, bukan menebak).

#Struktur File State (JSON)

File terraform.tfstate berformat JSON. Kalian tidak perlu membaca manual untuk bekerja sehari-hari, tapi memahami strukturnya membantu menghilangkan "rasa takut" terhadap file ini:

{
  "version": 4,
  "terraform_version": "1.9.5",
  "resources": [
    {
      "module": "",
      "mode": "managed",
      "type": "aws_instance",
      "name": "web",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "schema_version": 1,
          "attributes": {
            "id": "i-0abcd1234efgh5678",
            "ami": "ami-0c55b159cbfafe1f0",
            "instance_type": "t3.micro",
            "tags": {
              "Name": "web-server"
            }
          }
        }
      ]
    }
  ]
}

Perhatikan korespondensinya dengan kode HCL: blok "type": "aws_instance" + "name": "web" persis mencerminkan resource "aws_instance" "web", dan "id" adalah jembatan menuju objek nyata di AWS. File ini juga menyimpan seluruh atribut resource — termasuk yang mungkin sensitif.

#Bahaya Local State bagi Tim Engineering

Saat kalian bekerja sendirian, state lokal di folder proyek terasa nyaman. Namun begitu tim mulai berkolaborasi, terraform.tfstate lokal menjadi bom waktu. Ada tiga masalah utama:

Mari kita bedah masalah ketiga lebih dalam dengan sebuah skenario nyata:

Itulah mengapa tim engineering profesional tidak pernah menyimpan state secara lokal. Solusinya adalah remote state backend.

#Remote State Backend & State Locking

Backend adalah tempat Terraform menyimpan state secara terpusat. Dengan backend, state tinggal di satu lokasi bersama (misal S3 bucket), sehingga semua anggota tim membaca state yang sama — dan lebih penting lagi, konsisten.

Namun menyimpan state di satu tempat saja belum cukup. Masih ada celah: dua orang bisa membaca state yang sama lalu meng-apply bersamaan. Untuk itu ada state locking — mekanisme kunci yang memastikan hanya satu terraform apply/plan yang memegang akses state dalam satu waktu.

Bayangkan seperti toilet umum yang dikunci: orang kedua yang mencoba masuk saat masih ada yang di dalam akan menunggu (atau langsung ditolak dengan pesan error), bukan masuk dan mengacak-acak. Tanpa kunci, dua orang bisa masuk bersamaan dan membuat kekacauan.

#Backend AWS S3 + DynamoDB Locking

Konfigurasi backend paling populer di ekosistem AWS adalah kombinasi S3 (untuk menyimpan state) + DynamoDB (untuk state lock):

terraform {
  backend "s3" {
    bucket         = "myapp-tfstate-bucket"
    key            = "production/network/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "myapp-tfstate-lock"
  }
}

Penjelasan atribut:

• bucket + key — lokasi objek state. Pola key yang rapi memisahkan environment dan komponen, misal production/network/ vs staging/app/.
• encrypt = true — memaksa enkripsi server-side pada S3 (satu lapis pengaman tambahan untuk data sensitif di state).
• dynamodb_table — nama tabel DynamoDB yang berfungsi sebagai lock table. Terraform membuat lock item di tabel ini saat operasi berjalan dan menghapusnya setelah selesai.

#Backend Google Cloud Storage (GCS)

Untuk tim yang berada di ekosistem Google Cloud, backend GCS adalah pilihan utamanya:

terraform {
  backend "gcs" {
    bucket = "myapp-tfstate-bucket"
    prefix = "production/network"
  }
}

GCS menangani state locking secara native melalui object versioning — tidak perlu tabel DynamoDB terpisah seperti di AWS. Cukup aktifkan Object Versioning pada bucket, dan Terraform memanfaatkan preconditions GCS sebagai mekanisme kunci.

#Backend Lain yang Sering Dipakai

#Local State vs Remote State

Berikut perbandingan ringkas untuk memperkuat keputusan arsitektur:

#Menginspeksi State: state list dan state show

Meski state file sebaiknya tidak dibaca manual, Terraform menyediakan perintah untuk mengintrospeksinya dengan aman:

terraform state list

aws_instance.web
aws_s3_bucket.artifacts
data.aws_ami.ubuntu

terraform state show aws_instance.web

# aws_instance.web:
resource "aws_instance" "web" {
  ami                                  = "ami-0c55b159cbfafe1f0"
  arn                                  = "arn:aws:ec2:ap-southeast-1:123456789012:instance/i-0abcd1234efgh5678"
  id                                   = "i-0abcd1234efgh5678"
  instance_type                        = "t3.micro"
  tags                                 = {
    "Name" = "web-server"
  }
  ...
}

Kedua perintah ini sangat berguna saat memverifikasi bahwa mapping di state memang benar sebelum melakukan operasi seperti terraform destroy atau refactoring (akan dibahas lebih lanjut di episode 8).

#Aturan Emas: Jangan Pernah Commit State ke Git

Karena state berisi data sensitif dan bersifat machine-specific, aturannya sederhana: jangan pernah meng-commit terraform.tfstate, terraform.tfstate.backup, ataupun *.tfstate ke Git. Tambahkan ke .gitignore:

# Terraform state (local, karena remote backend sudah dipakai)
*.tfstate
*.tfstate.backup
*.tfstate.lock.info
 
# Secret yang sering tertukar dengan state
*.tfvars

#Kesalahan Umum dalam State Management

#Penutup

Pada episode 5 ini kita telah membahas state management secara menyeluruh: mengapa Terraform membutuhkan file terraform.tfstate sebagai mapping antara kode HCL dan ID riil di cloud, struktur JSON di baliknya, tiga bahaya utama state lokal (kebocoran data, kehilangan file, dan state conflict), serta bagaimana remote backend dengan state locking (S3+DynamoDB, GCS, Azure Blob) mengatasi semua bahaya tersebut.

Inti dari episode ini adalah satu keyakinan: state adalah aset paling berharga dalam proyek Terraform tim. Ia lebih berharga daripada kode — karena kode bisa ditulis ulang, sedangkan mapping antara kode dan resource yang sudah dibayar tidak bisa di-tebak ulang.

Di episode 6 selanjutnya, kita akan melengkapi gudang senjata ekspresi kalian dengan Advanced Expressions, Functions & Loops — mengenal built-in functions, conditional expression, serta meta-arguments count dan for_each untuk membuat banyak resource dari satu blok kode. Pastikan tetap semangat!