OpenTofu ile Tenant Bazlı State Ayrıştırma Rehberi

IaC kullanan ekipler ilk günlerde tek bir state dosyasıyla hızlı ilerler. Ancak kurum büyüdükçe farklı tenant’lar, farklı ortamlar ve farklı sahiplik sınırları aynı state içinde sıkışmaya başlar. Sonuç olarak küçük bir değişiklik gereksiz kilitlenme, geniş erişim yetkisi ve kırılgan plan çıktıları üretir. OpenTofu ile tenant bazlı state ayrıştırma yaklaşımı, yalnızca teknik düzen değil; yönetişim, güvenlik ve operasyon ölçeği için kritik bir sınır tanımıdır.

Ne zaman tek state modelinden çıkmalısınız?

Aşağıdaki sinyaller genellikle ayrıştırma ihtiyacını gösterir:

• Farklı ekipler aynı plan kilidine takılıyorsa
• Üretim ve test ortamı aynı state kökünde yaşıyorsa
• Bir tenant değişikliği başka tenant kaynaklarını listeletiyorsa
• Erişim izinleri state düzeyinde ayrılamıyorsa

Bu durumlarda sorun çoğu zaman araç değil sınır modelidir. State yapısı, organizasyon yapısının ve güvenlik sınırlarının gerisinde kalmıştır.

Referans klasör yapısı

Sade ve okunabilir bir model şöyle olabilir:

infra/
  tenants/
    erp-prod/
      network/
      platform/
    erp-test/
      network/
      platform/
    retail-prod/
      network/
      observability/

Buradaki amaç her klasörü farklı state yapmak değil; değişiklik frekansı, sahiplik ve etki alanına göre ayrım yapmaktır. Aynı yaşam döngüsünü paylaşmayan kaynakları tek state içinde tutmamak gerekir.

Backend tanımını nasıl ayırmalı?

OpenTofu tarafında state anahtarı tenant ve bileşen bazlı ayrılmalıdır. Basit bir S3 uyumlu backend örneği:

terraform {
  backend "s3" {
    bucket = "infra-state"
    key    = "tenants/erp-prod/network/tofu.tfstate"
    region = "eu-central-1"
    encrypt = true
    dynamodb_table = "infra-state-lock"
  }
}

Burada kritik olan şey sadece key alanı değil; lock ve erişim politikasının da aynı sınırı izlemesidir. Aksi hâlde dizin ayrılmış görünür ama yetki yüzeyi ayrılmaz.

Ortak modüllerle tenant ayrımı birlikte nasıl yaşar?

Birçok ekip şu hataya düşer: modüller ortaksa state de ortak kalmalı sanılır. Bu doğru değildir. Ortak modül kullanmak ile ortak state kullanmak farklı kararlardır.

Doğru model şudur:

• Modül kodu ortak olabilir
• Değişken seti tenant’a özgü olur
• Backend ve lock alanı tenant sınırını izler
• Pipeline yetkisi yalnızca ilgili tenant state’ine erişir

Bu ayrım sayesinde platform standardı korunur ama operasyon etkisi dar tutulur.

Pipeline tasarımında nelere dikkat edilmeli?

Tenant bazlı yapı kurulduğunda CI/CD hattı da bunu takip etmelidir. Ben şu kuralları öneriyorum:

1. Her tenant-bileşen çifti için ayrı plan job
2. Değişiklik olmayan tenant’lar için koşullu çalışma
3. Plan çıktısının ilgili sahip ekibe yönlendirilmesi
4. Üretim tenant’ları için ayrı onay ve rollout adımı

Bu model hem paralellik üretir hem gereksiz kilitlenmeyi azaltır.

Geçiş nasıl yapılmalı?

Mevcut büyük state’i bir günde parçalamaya çalışmak risklidir. Daha güvenli yöntem kademeli taşımadır:

• Önce sınır matrisi çıkarılır
• En az bağımlı bileşen seçilir
• state mv veya import stratejisiyle yeni köke alınır
• İlk birkaç değişiklik gözlemlenerek lock ve yetki modeli doğrulanır

Özellikle üretim ERP veya ağ katmanlarında bağımlılık haritası çıkarılmadan yapılan ayrıştırma yeni kırılganlık doğurur.

Sonuç

OpenTofu ile tenant bazlı state ayrıştırma, yalnızca teknik temizlik değildir. Yetki alanını daraltır, plan kilitlenmesini azaltır ve değişiklik etkisini okunabilir hâle getirir. Kurumsal altyapı büyüdükçe asıl hız tek büyük state’ten değil, doğru sınırlar içinde çalışan küçük ve sahipliği net state alanlarından gelir.