Locking #
State locking adalah mekanisme yang mencegah dua proses Terraform berjalan secara bersamaan pada state yang sama. Tanpa locking, dua orang yang menjalankan terraform apply secara bersamaan bisa menghasilkan state yang corrupt — keduanya membaca state lama, keduanya membuat perubahan, dan salah satu akan menimpa pekerjaan yang lain. Ini bukan edge case yang jarang terjadi; di tim yang aktif, race condition ini sangat mungkin terjadi.
Mengapa Locking Krusial #
SKENARIO TANPA LOCKING:
Developer A (menjalankan terraform apply):
t=0s: Baca state (serial: 5)
t=2s: Buat aws_vpc.main → state serial: 6
t=4s: Buat aws_subnet.public → state serial: 7
Developer B (menjalankan terraform apply di waktu yang sama):
t=1s: Baca state (serial: 5) ← baca state LAMA sebelum A selesai
t=3s: Buat aws_vpc.main → GAGAL (sudah ada, dibuat A)
t=5s: Tulis state (serial: 6) ← OVERWRITE state A yang serial: 7!
Hasil:
- aws_vpc.main ada di cloud, tapi state B tidak mencatatnya
- aws_subnet.public ada di cloud (dibuat A), tapi tidak ada di state B
- State sekarang tidak mencerminkan realita → drift permanen
Cara Locking Bekerja #
Ketika terraform apply atau terraform plan dimulai, Terraform mencoba mengambil lock sebelum melakukan apapun.
PROSES LOCKING:
terraform apply dimulai
│
▼
Coba acquire lock
│
┌───┴───┐
│ │
Berhasil Gagal (lock sudah dipegang)
│ │
▼ ▼
Lanjut Error: "Error acquiring the state lock"
eksekusi Tampilkan info siapa yang memegang lock
│
▼
Eksekusi selesai
│
▼
Release lock
Locking di Berbagai Backend #
# S3 Backend — butuh DynamoDB untuk locking
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "production/terraform.tfstate"
region = "ap-southeast-1"
dynamodb_table = "terraform-state-lock" # Wajib untuk locking
encrypt = true
}
}
# Lock entry di DynamoDB saat apply sedang berjalan:
# LockID: "my-terraform-state/production/terraform.tfstate"
# Info: {"ID":"abc123", "Operation":"OperationTypeApply",
# "Who":"user@hostname", "Created":"2024-01-15T10:30:00Z"}
# GCS Backend — locking built-in, tidak perlu resource tambahan
terraform {
backend "gcs" {
bucket = "my-terraform-state"
prefix = "production"
# Locking menggunakan GCS object versioning — otomatis
}
}
# Terraform Cloud — locking built-in, dikelola platform
terraform {
cloud {
organization = "my-org"
workspaces {
name = "production"
}
}
}
Pesan Error Lock dan Artinya #
# Error yang muncul saat lock sedang dipegang:
$ terraform apply
╷
│ Error: Error acquiring the state lock
│
│ Error message: ConditionalCheckFailedException: ...
│ Lock Info:
│ ID: abc123def456
│ Path: my-terraform-state/production/terraform.tfstate
│ Operation: OperationTypeApply
│ Who: [email protected]
│ Version: 1.6.3
│ Created: 2024-01-15 10:30:00.123456789 +0000 UTC
│ Info:
╵
# Informasi penting dari error ini:
# - ID: digunakan untuk force-unlock jika diperlukan
# - Who: siapa yang memegang lock saat ini
# - Created: kapan lock diambil (jika sudah lama, mungkin stuck)
Menangani Stuck Lock #
Terkadang lock tidak terlepas otomatis — misalnya jika proses Terraform terpotong paksa (Ctrl+C, crash, network timeout di CI/CD).
# Cek apakah ada lock aktif
terraform plan
# Jika ada lock, error message akan menampilkan Lock ID
# Force unlock — gunakan Lock ID dari error message
terraform force-unlock abc123def456
# PENTING: Pastikan tidak ada proses Terraform lain yang sedang berjalan
# sebelum melakukan force-unlock. Force unlock pada apply yang masih
# berjalan bisa menyebabkan state corrupt.
SEBELUM FORCE UNLOCK, VERIFIKASI:
□ Tidak ada proses terraform yang berjalan di mesin lain
□ Tidak ada CI/CD job yang masih aktif
□ Lock memang stuck (created time sudah lama, misalnya > 30 menit)
□ Kamu tahu siapa yang memegang lock dan sudah konfirmasi mereka
Setelah force unlock:
□ Jalankan terraform plan untuk memverifikasi state konsisten
□ Baru lanjutkan dengan terraform apply jika plan bersih
Locking di CI/CD Pipeline #
Di CI/CD pipeline, lock bisa menjadi masalah jika beberapa pipeline dijalankan bersamaan. Ada beberapa strategi untuk mengelolanya.
# Strategi 1: Serialized pipeline
# Pastikan hanya satu pipeline apply yang bisa berjalan bersamaan
# (konfigurasi di CI/CD tool — GitHub Actions concurrency, GitLab resource groups)
# GitHub Actions: concurrency group
name: Terraform Apply
concurrency:
group: terraform-production # Hanya satu workflow dengan group ini boleh jalan
cancel-in-progress: false # Jangan cancel yang sedang jalan, antrikan
jobs:
apply:
runs-on: ubuntu-latest
steps:
- name: Terraform Apply
run: terraform apply -auto-approve tfplan
# Strategi 2: Timeout yang masuk akal
# Jika pipeline stuck dan lock tidak terlepas setelah timeout,
# pipeline bisa dianggap failed dan alert dikirim
terraform apply -lock-timeout=5m # Tunggu maksimal 5 menit untuk acquire lock
# Jika tidak berhasil dalam 5 menit, error dan gagal
Disable Locking (Hanya untuk Keadaan Darurat) #
# ANTI-PATTERN: Disable locking secara permanen
terraform apply -lock=false # ✗ Sangat berbahaya di lingkungan tim
# BENAR: Disable locking hanya jika benar-benar terpaksa
# dan kamu yakin tidak ada proses lain yang berjalan
terraform plan -lock=false # Misalnya: hanya untuk inspeksi darurat
Ringkasan #
- Locking mencegah state corrupt akibat dua proses apply yang berjalan bersamaan — ini bukan fitur opsional tapi kebutuhan di lingkungan tim.
- S3 butuh DynamoDB untuk locking — konfigurasi
dynamodb_tabledi backend S3 adalah wajib, bukan opsional.- GCS dan Terraform Cloud sudah built-in locking tanpa konfigurasi tambahan.
- Lock error berisi Lock ID — simpan ini jika perlu force-unlock, tapi verifikasi dulu tidak ada proses aktif sebelum melakukannya.
- Force unlock hanya saat lock benar-benar stuck — force unlock pada apply yang masih berjalan bisa menyebabkan state corrupt.
- Serialized CI/CD pipeline adalah cara terbaik mencegah lock conflict — gunakan concurrency groups atau resource locks di CI/CD tool.