Terraform’un lisans modeli değiştikten sonra birçok ekip aynı soruyu sormaya başladı: mevcut altyapı kodunu Terraform ile sürdürmek mi, OpenTofu’ya geçmek mi daha doğru? Bu sayfa iki aracın farkını ve geçişin gerçek maliyetini anlatır.
OpenTofu ve Terraform, altyapıyı (sunucu, ağ, IAM, veritabanı, DNS, hatta SaaS yapılandırmaları) bildirimsel kod olarak tanımlamayı sağlayan IaC araçlarıdır. Terraform’un modern dağıtımı BSL lisansındadır; OpenTofu ise MPL 2.0 ile topluluk alternatifi olarak gelişir.
İkisi de HCL tabanlıdır; fakat uyumluluk her sürüm ve provider için aynı değildir. Geçiş planında state yedeği almak, hedef sürümde plan/apply testleri yapmak ve provider breaking change’lerini kontrol etmek gerekir.
Modül stratejisi
Üç katmanlı modül hiyerarşisi kullanırız:
- Kaynak modülleri - tek bir kaynak grubu (örn.
aws-vpc,gcp-cloud-sql). Sürüm pin’li. - Servis modülleri - birden fazla kaynak modülünü birleştiren yapılar (örn.
web-app-stack= ALB + ASG + RDS + Route53). - Ortam kompozisyonu - modüllere değer geçen ince katman (
environments/prod/web/main.tf).
Modüller ayrı Git repo’sunda; ortamlar source = "git::ssh://...?ref=v1.4.0" ile sürüme sabitlenir.
Yaygın sorunlar ve çözümler
- State drift: Manuel değişiklikleri tespit etmek için haftalık
tofu plancron’u. Drift varsa Slack/Teams uyarısı. - Plan’da binlerce satır değişiklik: Genelde provider sürüm yükseltmesi sebebiyledir.
tofu state replace-providervetofu plan -refresh-onlyile ayrıştırın. - Yavaş plan: State’i/domain’i parçalayın; gerekirse
-targetyalnızca dar kapsamlı analiz ve geçici hata ayıklama için kullanılsın, kalıcı üretim akışı olmasın. - Secret sızıntısı: State içinde secret olmasın. Secrets Manager / Vault entegrasyonu,
sensitive = truemarkası ve state’in kesinlikle halka açık olmaması. - Lisans/uyumluluk: Yeni projelerde OpenTofu, eskilerde aşamalı geçiş; Mono geçişlerde state yedeği, sürüm/provider testi ve geri dönüş planını birlikte hazırlar.
Kim için uygun, kim için değil
- Uygun: yeni bir altyapı-kod standardı belirleyen ekipler
- Uygun: lisans ve tedarik riskini azaltmak isteyen kurumlar
- Uygun değil: mevcut Terraform ortamını test etmeden doğrudan üretimde değiştirmek isteyenler
- Uygun değil: state ve provider uyumluluğunu göz ardı eden, tek adımda tamamlanacak göç beklentisi
Maliyet kalemleri
- State deposu, kilitleme ve yedekleme işletimi
- Provider sürüm takibi ile plan/apply testleri
- Modül sürümleme ve ortam ayrıştırma bakımı
- Göç sırasında paralel koşum ve geri dönüş hazırlığı
Resmi kaynaklar
Mono’nun yaklaşımı
Hangi aracın kullanılacağı tek başına bir karar değil; organizasyon yapısı ve state yönetimi çok daha önemli. Mono’nun standart kurulumu:
- Tek state yerine modüler state’ler: Her ortam (dev/staging/prod) ve her domain (network, data, compute) ayrı state. Blast-radius minimum.
- Remote backend: AWS S3 + DynamoDB veya Mono Cloud üzerinde Garage S3. Locking + versioning + encryption.
- Workspace yerine ortam dizinleri:
terraform workspaceyerine fiziksel klasör ayrımı (daha şeffaf). - Atlantis veya Spacelift: PR otomasyonu için. Manuel
applyüretimde mutlaka approval gerektirir. - Policy as code: OPA/Conftest ile “asla public S3 bucket açma”, “production’da
*resource yasak” gibi kuralları PR aşamasında zorunlu kıl.
Sıkça sorulan sorular
OpenTofu mu Terraform mu?
State'i nerede tutmalıyız?
Modülleri nasıl organize etmeliyiz?
Plan/apply pipeline nasıl çalışmalı?
tofu plan, çıktı PR yorumuna eklenir. Plan onaylandıktan sonra manuel approval ile apply. Üretim için ek olarak drift detection (haftalık tofu plan cron’u) ve policy as code (OPA/Conftest).