İçeriğe geç
OpenTofu / Terraform

OpenTofu ve Terraform, altyapıyı (sunucu, ağ, IAM, veritabanı, DNS, hatta SaaS yapılandırmaları) bildirimsel kod olarak tanımlamayı sağlayan, fiili standart IaC (Infrastructure as Code) araçlarıdır. HashiCorp tarafından 2014’te başlatılan Terraform, 2023’teki BSL lisans değişikliğinin ardından Linux Foundation çatısı altında OpenTofu olarak forklanmıştır.

İkisi de aynı dili (HCL — HashiCorp Configuration Language) kullanır ve sürüm 1.5’e kadar tam uyumludur. Yeni özellikler bu noktadan sonra ayrışmaya başlamış olsa da Mono müşterilerimizin çoğu OpenTofu’ya sorunsuz geçiş yapmıştır.

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 workspace yerine 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.

Modül stratejisi

Üç katmanlı modül hiyerarşisi kullanırız:

  1. Kaynak modülleri — tek bir kaynak grubu (örn. aws-vpc, gcp-cloud-sql). Sürüm pin’li.
  2. Servis modülleri — birden fazla kaynak modülünü birleştiren yapılar (örn. web-app-stack = ALB + ASG + RDS + Route53).
  3. 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 plan cron’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-provider ve tofu plan -refresh-only ile ayrıştırın.
  • Yavaş plan: Workspace’i parçalayın; -target resource ile lokal hızlı iterasyon.
  • Secret sızıntısı: State içinde secret olmasın. Secrets Manager / Vault entegrasyonu, sensitive = true markası ve state’in kesinlikle halka açık olmaması.
  • Lisans/uyumluluk: Yeni projelerde OpenTofu, eskilerde aşamalı geçiş; Mono geçişlerde state migration’ı sıfır kesintiyle yapar.

İlgili hizmetlerimiz

Sıkça sorulan sorular

OpenTofu mu Terraform mu?
Yeni projeler için OpenTofu öneriyoruz: tamamen açık-kaynak (MPL 2.0), Linux Foundation altında, Terraform 1.5 ile geriye dönük uyumlu. Mevcut Terraform projelerinden geçiş genelde tek satır değişiklikle çalışır. Lisans riski olan kurumsal müşterilerimizin neredeyse tamamı OpenTofu’ya geçti.
State'i nerede tutmalıyız?
Asla local’de değil. Cloud için S3 + DynamoDB lock veya Mono Cloud için Garage S3 uyumlu backend. Encryption at rest, versioning ve lock üçü birden zorunludur. Hassas veriler içeren state dosyaları için ek olarak transit encryption ve sınırlı IAM erişimi.
Modülleri nasıl organize etmeliyiz?
Üç katmanlı bir hiyerarşi: kaynak modülleri (tek bir AWS resource grubu), servis modülleri (örn. web-app stack = ALB+ASG+RDS), ortam kompozisyonu (dev/staging/prod). Modüller ayrı bir repo’da sürümlendirilir; ortamlar onları version pin ile çağırır.
Plan/apply pipeline nasıl çalışmalı?
PR açıldığında otomatik 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).

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.