OpenTofu ile altyapı kod olarak: pratik rehber

Terraform’un BSL lisansına geçişiyle 2024’te başlayan tartışma, 2025’te netleşti: OpenTofu Linux Foundation çatısında, gerçek bir açık-kaynak alternatif. Mono müşterilerinin %90’ı son 12 ayda Terraform’dan OpenTofu’ya geçti.

Geçiş gerçekten zor mu?

Hayır. Tofu ekibi 1.6.x sürümünde Terraform 1.5.x ile bire-bir uyumlu olmaya özen gösterdi. Çoğu kurulumda:

# Terraform'u kaldır
brew uninstall terraform

# Tofu kur
brew install opentofu

# Komutu değiştir
alias terraform=tofu  # veya doğrudan tofu komutunu kullan

State formatı aynı; provider’lar aynı registry’lerden çekiliyor (Tofu kendi registry’sini de açtı).

Modül tasarım prensipleri

Saha tecrübemizden bu prensipler en çok geri-dönüş aldı:

1. Tek sorumluluk

Bir modül bir alt sistemi kurmalı. network modülü VPC + subnet + NAT yapsın; ama IAM rolleri ayrı modülde olsun.

2. Esneklik > tam zaptedilmişlik

Module’a 30 input verip “her şeyi konfigüre edebilirsin” yapmak çekici görünür; ama kullanıcı eğitimi zorlaşır. 6-8 input + güvenli varsayılan tercih edin.

3. for_each > count

count ile yönetilen kaynaklarda sıra değiştiğinde state silme/yeniden oluşturma olur. for_each map’i sırayı dert etmez:

resource "aws_iam_user" "team" {
  for_each = toset(local.team_members)
  name     = each.value
}

4. Versiyonla

Ortak modülleri kendi git repo’nuzdan referans verin ve tag ile sabitleyin:

module "rds" {
  source = "git::https://gitlab.mono.local/iac/modules.git//rds?ref=v1.4.2"
}

main branch’a referans veren her modül, bir gün size sorun çıkarır.

State yönetimi

Backend seçimi

Mono için 3 ana seçenek:

Workspace mi, klasör mi?

Klasör tercih edin. Workspace’ler ortam izolasyonu için yetersiz; prod ile dev aynı state’te tutulduğunda yanlış-alan değişikliği riski yüksek.

infra/
  envs/
    dev/
      main.tf
      backend.tf  # bucket: mono-tfstate-dev
    staging/
    prod/
  modules/

Her ortam ayrı state, ayrı bucket / prefix.

CI/CD ile akış

Standart akışımız:

1. PR açılır → CI tofu plan çalıştırır, çıktıyı PR yorumuna yapıştırır.
2. Plan onaylanır → maintainer review eder.
3. Merge → CI tofu apply çalıştırır (otomatik veya manuel onay).
4. Drift detection → günlük cron ile tofu plan -refresh-only; fark varsa Slack’e bildir.

Drift detection en çok atlanan adım; ama “biri konsolda elle değiştirmiş” durumunu yakalayan tek mekanizma.

Yaygın tuzaklar

• local-exec bağımlılığı. Provider yoksa local-exec ile script çağırmak; başlangıçta hızlı, uzun vadede kaynak takibi imkansız.
• State bölmeden büyütmek. 2000+ kaynaklı tek state; her plan 5 dk. Domain bazında böl.
• Şifre/secret state’te. State dosyası terraform.tfstate.backup ile her yerde. SOPS veya Vault kullanın.
• apply -auto-approve PR sürecinde kabul edilebilir; üretim ortamında insan onayı ile akar.

Migration checklist

Terraform → OpenTofu geçiş için minimum kontrol listesi:

• Tofu 1.6+ ile mevcut state üzerinde tofu plan (no-op olmalı).
• Provider’ların Tofu registry’sinde mevcudiyetinin kontrolü.
• CI/CD pipeline’larında terraform → tofu değişikliği.
• Pre-commit hook’larında tflint + tfsec (artık Trivy) güncellemesi.
• Ekibe Tofu spesifik değişikliklerin (variable validation, encryption blokları) sunumu.

Sıradaki adımlar

IaC dönüşümünüzü hızlandırmak için, Kod olarak altyapı (IaC) dönüşümü hizmetimiz kapsamında 2 haftalık bir hızlandırıcı veriyoruz.