Terraform state'i S3 + DynamoDB locking ile nasıl güvenli yönetirim?

Kısa cevap: Local terraform.tfstate + 3 kişi = bozulma ve race condition. State’i remote backend’e taşı: dosya için S3, locking için DynamoDB — bu kombinasyon uzun süredir sektörün standardıydı, ama Terraform 1.11’den beri DynamoDB locking deprecated durumda.

Kısa cevap

Sorunun kökü tek bir paylaşılan dosyanın, kilit olmadan, üç kişi tarafından aynı anda yazılması. Kilidin nereye konacağı sorusunun veritabanı tarafını — pessimistic lock mu, Redlock mu — bakiye güncelleme kaydında tartışmıştım; burada aynı mantık altyapı state’ine uygulanıyor.

Neden

1. Kilit, ikinci apply’ı sıraya sokar. Terraform, herhangi bir apply’dan önce bir lock satırı yazar. İkinci kişi apply çalıştırınca kilit dolu olduğu için ya bekler ya da hızlıca hata verir — state’i üst üste yazıp bozmaz. Race condition tam burada biter.

2. Tek state, blast radius’u birleştirir. Prod, staging ve dev tek bir state’i paylaşırsa staging’de bir hata prod state’ini riske atar; ortamları ayırmak blast radius’u ayrı tutmanın en ucuz yolu.

3. Serileştirilmiş tek yol, paralel apply’lardan güvenlidir. Tek serileştirilmiş yol (CI), üç laptop’tan gelen paralel apply’lardan çok daha güvenli — kilit olsa bile insan sayısı arttıkça çakışma ihtimali artar.

Ne yapmalı

1. State dosyasını S3’e al — versiyonlu, şifreli, IAM ile kısıtlı. Bucket’ta versioning açık olsun ki bozuk bir state’ten kolayca geri dönebilesin; encryption açık, erişim sadece gereken role’lerde. Artık state laptop’ta değil, merkezi ve yedekli bir yerde.

2. DynamoDB ile state locking kur. Backend konfigürasyonuna lock tablosunu ekle; Terraform kilidi kendisi yönetir, senin ek bir iş yapmana gerek kalmaz.

3. Ortam başına ayrı state tut. Prod, staging ve dev’i tek bir state’te paylaşma; her ortamın kendi state’i olsun.

4. Mümkünse apply’ları sadece CI’dan çalıştır ve state’i elle düzenleme. State’e elle dokunma; düzeltmen gerekirse terraform state komutlarını kullan.

Sonuç: Ben olsam S3 (versiyonlu + şifreli) backend + DynamoDB lock tablosu + ortam başına state + CI’dan apply derdim. Not: yeni Terraform/OpenTofu sürümleri S3-native locking de yapabiliyor; DynamoDB lock tablosu hâlâ yaygın olsa da HashiCorp tarafından deprecated ilan edildi ve kaldırılması planlanıyor — yine de ekibin bugün tereddütsüz oturtabileceği şey budur. IaC’ye gerçekten geçmeye değer mi, yoksa script mi yeter sorusunu sade.dev’de ayrıca tartıştım.