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 sektörün kanıtlanmış standardı.

Sorunun kökü tek bir paylaşılan dosyanın, kilit olmadan, üç kişi tarafından aynı anda yazılması.

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. 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.
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. Aksi halde staging’de bir hata prod state’ini riske atar; blast radius’u ayrı tutmanın en ucuz yolu budur.
4. Mümkünse apply’ları sadece CI’dan çalıştır ve state’i elle düzenleme. Tek serileştirilmiş yol (CI), üç laptop’tan gelen paralel apply’lardan çok daha güvenli. 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, ama DynamoDB lock tablosu yaygın ve kanıtlanmış kurulumdur — ekibin 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.