Belajar OpenTofu - Remote State Management & State Locking

#Pendahuluan

Di episode 4 kita membuat konfigurasi reusable dengan variable, locals, dan output. Selama kalian menjalankan tofu apply di laptop sendiri, semuanya bekerja — sampai suatu hari kalian perlu kolaborasi, berpindah laptop, atau menjalankan pipeline di CI. Saat itulah muncul pertanyaan krusial: di mana OpenTofu menyimpan catatan tentang apa yang sudah dibuat?

Jawabannya adalah state file — dan cara kalian mengelolanya menentukan apakah infrastruktur tim aman atau rawan konflik. Episode 5 ini membahas komponen opentofu.tfstate, opsi remote backend, dan state locking untuk kolaborasi yang aman.

#Pembahasan Utama

#Apa Sebenarnya Isi State File?

Ketika OpenTofu membuat resource, ia menyimpan "bukti" keberadaannya ke file state. File ini berisi pemetaan antara kode HCL dan identitas resource nyata di cloud — resource ID, region, atribut hasil apply, dan dependency antar resource.

opentofu.tfstate (dipotong)

{
  "version": 4,
  "terraform_version": "1.9.0",
  "resources": [
    {
      "type": "aws_instance",
      "name": "web",
      "instances": [
        {
          "attributes": {
            "id": "i-0a1b2c3d4e5f67890",
            "instance_type": "t3.micro"
          }
        }
      ]
    }
  ]
}

Tanpa state, OpenTofu tidak tahu bahwa instance i-0a1b2c3d4e5f67890 di cloud sebenarnya milik blok aws_instance.web di kode kalian. Kalau file state hilang, tofu plan akan menganggap resource itu tidak ada dan berusaha membuatnya lagi.

Warning

State menyimpan nilai hasil apply, termasuk potensi rahasia seperti password yang dihasilkan provider. Jangan commit state ke Git, dan jangan biarkan ia hanya di laptop satu orang — di sinilah remote backend berperan.

#Masalah State Lokal

Secara default, OpenTofu menyimpan state di file opentofu.tfstate di folder project (backend lokal). Ini nyaman untuk latihan, tapi bermasalah di tim:

State hanya ada di satu mesin — mesin lain tidak tahu apa yang sudah dibuat.
Tanpa sinkronisasi, dua orang bisa meng-apply kode yang sama dan membuat resource ganda.
Laptop hilang berarti "memory" infrastruktur ikut hilang.

Solusinya: remote backend — menyimpan state di penyimpanan terpusat yang bisa diakses semua orang.

#Remote State Backends

Backend adalah tempat state disimpan. OpenTofu mendukung banyak pilihan; pilih sesuai cloud yang kalian pakai:

Backend	Tempat Penyimpanan	Cocok Untuk
`s3`	AWS S3 + DynamoDB	Tim yang berjalan di AWS
`gcs`	Google Cloud Storage	Tim di ekosistem GCP
`azurerm`	Azure Blob Storage	Tim di ekosistem Azure
`http`	REST API kustom	Penyimpanan yang dikelola sendiri

Konfigurasi backend ditulis di block backend di dalam blok terraform:

backend.tf

terraform {
  backend "s3" {
    bucket         = "devvnull-opentofu-state"
    key            = "learn-opentofu/episode-5/opentofu.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "opentofu-state-lock"
  }
}

Setelah block ini ada, tofu init menyiapkan koneksi ke S3, dan setiap tofu apply menulis state ke bucket — bukan ke folder lokal. Semua anggota tim otomatis bekerja di state yang sama.

Tip

Gunakan key yang unik per project dan per environment (misal staging/ vs prod/) agar environment terpisah total. Untuk bucket S3, aktifkan juga versioning sebagai backup state.

#State Locking: Mencegah Apply Bersamaan

Bayangkan dua orang menjalankan tofu apply bersamaan dari state yang sama. Keduanya membaca state lama, masing-masing membuat perubahan, lalu menulis hasilnya — perubahan pertama tertimpa dan hasilnya tidak konsisten. Inilah yang dicegah oleh state locking.

Prinsipnya seperti kunci database (mutex): sebelum apply, OpenTofu mengunci state; apply lain yang datang akan menunggu atau gagal; setelah selesai, kunci dilepas.

Untuk backend S3, kunci disimpan di tabel DynamoDB. Untuk GCS, mekanismenya memakai object versioning dan generation. Blok dynamodb_table pada contoh di atas itulah tempat lock — tabel DynamoDB dibuat sekali dengan LockID sebagai partition key.

State terkunci saat apply berjalan

aws_instance.web: Creating...
Error: Error acquiring the state lock
 
Error message: ConditionalCheckFailedException: The conditional request failed

Error ini justru kabar baik — artinya locking aktif dan melindungi kalian dari konflik.

Warning

Jangan pernah memakai -lock=false untuk mengakali error lock kecuali benar-benar paham risikonya. Memaksa apply saat state terkunci bisa menghapus perubahan orang lain. Selalu cari tahu siapa yang sedang apply, atau tunggu lock time-out.

#Dari State Lokal ke Remote

Pindah dari state lokal ke remote semudah tofu init -migrate-state — OpenTofu menyalin state yang ada ke backend baru secara otomatis. Transisi yang sama dipakai saat migrasi Terraform ke OpenTofu di episode 2, jadi konsepnya sudah tidak asing.

#Penutup

Ringkasan episode 5:

State file memetakan kode HCL ke resource ID nyata di cloud — tanpa state, OpenTofu buta terhadap apa yang sudah dibuat.
State lokal hanya cocok untuk latihan; tim butuh remote backend.
Backend populer: s3, gcs, azurerm, dan http — pilih sesuai ekosistem.
State locking (DynamoDB untuk S3, object versioning untuk GCS) mencegah apply bersamaan; jangan di-disable tanpa alasan.

State kalian sekarang tersimpan aman dan kolaboratif. Tapi ada satu pertanyaan lanjutan: apakah isi state di backend terlindungi jika bucket bocor? Di episode 6 berikutnya kita membahas fitur eksklusif OpenTofu pertama: native client-side state encryption — mengenkripsi state di sisi client sebelum dikirim ke storage. Sampai jumpa!