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:

```bash
# 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:

```hcl
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:

```hcl
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:

| Backend                                | Kim için                | Notlar                                                 |
| -------------------------------------- | ----------------------- | ------------------------------------------------------ |
| `s3` (Garage / R2)                     | Self-hosted ekipler     | `dynamodb_table` yerine `lockfile = true` (Tofu 1.10+) |
| `gitlab`                               | GitLab kullanan ekipler | Yerleşik, ekstra altyapı yok                           |
| `tfcloud` (Tofu için: scalr/spacelift) | Yönetimi dışlayanlar    | Lisans bedeli                                          |

### 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ü](/hizmetler/kod-olarak-altyapi-iac-donusumu/) hizmetimiz kapsamında 2 haftalık bir hızlandırıcı veriyoruz.