Artikel

Terraform dalam tim: pembagian state, radius dampak, dan plan yang direview

Cara membagi state Terraform, menjalankan plan di CI, dan hanya menerapkan yang sudah direview, agar perubahan infrastruktur menjadi rutinitas, bukan risiko.

Contoh-contohnya bersifat umum dan ilustratif. Tidak diambil dari lingkungan klien mana pun: sesuaikan ambang batas dan pengaturan dengan sistem Anda sendiri.

File state adalah batas yang sebenarnya

Setiap terraform apply bisa mengubah apa saja di dalam state yang ditanganinya. Karena itu satuan risikonya adalah state, bukan modul. Dengan satu state untuk seluruh lingkungan, salah ketik di record DNS dan perubahan pada basis data produksi melewati plan yang sama — dan plan itu butuh beberapa menit untuk dihitung.

Bagi berdasarkan siklus hidup dan radius dampak

Kelompokkan sumber daya yang berubah bersama dan gagal bersama. Pembagian yang umum memisahkan, di setiap lingkungan:

Fondasi: akun, jaringan, zona DNS — jarang berubah.
Data: basis data, bucket, antrean — diubah dengan hati-hati dan dilindungi dari penghapusan.
Komputasi dan layanan: cluster, fungsi, load balancer — sering berubah.

Setiap lapisan membaca output lapisan di bawahnya dan tidak pernah mengelola sumber dayanya. Lingkungan berbagi modul yang sama, tetapi dengan state dan kredensial terpisah, sehingga apply di staging tidak bisa menyentuh produksi.

Remote state, locking, dan versi

Simpan state di backend jarak jauh dengan locking dan versioning aktif — jangan pernah di Git, dan jangan pernah di laptop.
Commit lock file dependensi (.terraform.lock.hcl) dan kunci versi modul, agar plan hari ini dan plan bulan depan menjalankan kode yang sama.
Lindungi sumber daya stateful dengan prevent_destroy dan perlindungan penghapusan bawaan provider.

Plan di setiap pull request, apply yang sudah direview

Jalankan terraform plan di CI untuk setiap perubahan dan tampilkan hasilnya di pull request. Setelah disetujui, terapkan plan yang tersimpan alih-alih membuat plan ulang, agar produksi menerima persis apa yang dibaca reviewer; jika state berubah di antaranya, Terraform menolak plan yang sudah usang. Pipeline sebaiknya melakukan autentikasi dengan kredensial berumur pendek melalui federasi OIDC, bukan dengan kunci berumur panjang yang disimpan sebagai secret.

terraform init -input=false
terraform plan -input=false -lock-timeout=5m -out=tfplan
terraform show -no-color tfplan > plan.txt   # attach to the pull request

# after approval, applying the same saved plan:
terraform apply -input=false tfplan

Deteksi drift secara berkala

Perubahan lewat konsol tetap terjadi, biasanya saat insiden. Job terjadwal yang menjalankan terraform plan -detailed-exitcode akan menemukannya: kode keluar 0 berarti tidak ada perubahan, 2 berarti infrastruktur nyata berbeda dari kode, dan 1 berarti error. Jadikan 2 sebagai tiket, lalu masukkan perubahan itu ke kode atau kembalikan.

Kebijakan sebelum apply

Aturan seperti “tidak ada bucket publik” atau “setiap sumber daya punya tag pemilik” lebih baik diperiksa mesin daripada reviewer di akhir hari yang panjang. Alat policy-as-code seperti Open Policy Agent melalui Conftest dapat mengevaluasi bentuk JSON dari plan (terraform show -json) di CI dan memblokir merge.