State #

State adalah konsep yang paling krusial — sekaligus paling sering disalahpahami — di Terraform. Semua hal yang berjalan baik atau buruk dalam workflow Terraform bermuara pada state. Tanpa pemahaman yang tepat tentang state, kamu akan kesulitan men-debug masalah, takut menjalankan apply, dan tidak tahu harus mulai dari mana saat ada yang salah.

Apa itu State #

State adalah file JSON yang menyimpan pemetaan antara resource yang kamu definisikan di konfigurasi Terraform dan resource yang benar-benar ada di cloud provider. File ini bernama terraform.tfstate dan secara default disimpan di direktori yang sama dengan konfigurasimu.

// terraform.tfstate — contoh potongan isinya
{
  "version": 4,
  "terraform_version": "1.6.0",
  "resources": [
    {
      "type": "aws_instance",
      "name": "web",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "attributes": {
            "id": "i-0abcdef1234567890",
            "ami": "ami-0abcdef1234567890",
            "instance_type": "t3.micro",
            "public_ip": "54.123.45.67",
            "private_ip": "10.0.1.42",
            "tags": {
              "Name": "web-server"
            }
          }
        }
      ]
    }
  ]
}

State menyimpan semua atribut resource — termasuk atribut yang baru tersedia setelah resource dibuat (seperti public_ip dan id yang digenerate AWS).

Mengapa State Dibutuhkan #

Tanpa state, Terraform tidak punya cara untuk mengetahui resource mana yang sudah ada, apa konfigurasinya saat ini, dan apa yang perlu diubah.

TANPA STATE — Terraform tidak bisa menjawab:

  Pertanyaan: "Apakah aws_instance.web sudah ada?"
  → Tidak tahu. Harus query AWS setiap saat untuk semua resource.
  → Lambat untuk infrastruktur besar (ratusan resource).
  → Tidak tahu atribut mana yang kamu set vs yang AWS set secara default.

DENGAN STATE — Terraform tahu:

  "aws_instance.web ada dengan ID i-0abcdef1234567890,
   instance_type t3.micro, public_ip 54.123.45.67"

  → Plan lebih cepat (tidak perlu query semua resource ke API)
  → Tahu persis apa yang berubah
  → Bisa menghitung dependency graph dengan akurat

Local State vs Remote State #

Secara default, state disimpan secara lokal di terraform.tfstate. Ini cukup untuk eksperimen, tapi tidak untuk kolaborasi tim.

# LOCAL STATE — default, tidak perlu konfigurasi tambahan
# File terraform.tfstate ada di direktori yang sama dengan .tf files
# MASALAH:
# - Tidak aman untuk di-commit ke Git (bisa mengandung secret)
# - Tidak bisa diakses oleh anggota tim lain
# - Tidak ada locking — dua orang apply sekaligus = konflik

# REMOTE STATE — S3 sebagai contoh
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"  # Untuk state locking
  }
}

Dengan remote state, semua anggota tim membaca dan menulis state yang sama. DynamoDB table digunakan sebagai mekanisme locking — mencegah dua orang menjalankan apply secara bersamaan yang bisa menyebabkan state corrupt.

State Bukan untuk Diedit Manual #

State adalah file yang dikelola sepenuhnya oleh Terraform. Mengeditnya secara manual hampir selalu berakhir buruk.

# ANTI-PATTERN: Edit terraform.tfstate langsung dengan text editor
# Ini bisa menyebabkan:
# - State corrupt yang tidak bisa di-recover
# - Resource orphan (ada di cloud, tidak ada di state)
# - Dependency yang rusak

# BENAR: Gunakan perintah Terraform untuk manipulasi state
terraform state list                    # Lihat semua resource di state
terraform state show aws_instance.web  # Lihat detail satu resource
terraform state rm aws_instance.web    # Hapus resource dari state (tanpa destroy)
terraform state mv aws_instance.web aws_instance.new_name  # Rename resource di state

Risiko Kehilangan State #

Kehilangan state file adalah salah satu skenario paling berbahaya di Terraform. Jika state hilang, Terraform tidak tahu resource apa yang sudah dibuat — ia akan mencoba membuat semua resource dari awal.

SKENARIO KEHILANGAN STATE:

State hilang →
  terraform plan menampilkan: "akan membuat 47 resource"
  (padahal semua sudah ada di AWS)
  
  terraform apply →
  ERROR: resource sudah ada, tidak bisa dibuat ulang
  (atau worse: berhasil, tapi sekarang ada resource duplikat)

PENCEGAHAN:
  ✓ Gunakan remote backend (S3, GCS, Terraform Cloud)
  ✓ Enable versioning di S3 bucket yang menyimpan state
  ✓ Jangan hapus state file kecuali kamu tahu persis apa akibatnya
  ✓ Backup state sebelum operasi berisiko (terraform state pull > backup.tfstate)

Ringkasan #

• State adalah peta antara konfigurasi dan realita — Terraform membandingkan state dengan konfigurasi untuk menentukan apa yang perlu berubah.
• Tanpa state, Terraform buta — ia tidak bisa tahu resource apa yang sudah ada tanpa query ke semua API provider, yang sangat lambat untuk infrastruktur besar.
• Local state cukup untuk eksperimen — tapi remote state (S3, GCS, Terraform Cloud) adalah keharusan untuk tim dan production.
• Jangan edit state manual — gunakan terraform state subcommand untuk semua manipulasi state.
• State locking penting untuk mencegah konflik saat beberapa orang menjalankan Terraform secara bersamaan.
• Kehilangan state adalah darurat — lindungi dengan remote backend yang ter-versioning dan backup rutin.

← Sebelumnya: Resource   Berikutnya: Instalasi →