1. GİRİŞ

Terraform, Infrastructure as Code (IaC) ekosisteminin en yaygın kullanılan araçlarından biridir. Sağlayıcı‑agnostik yapısı ve zengin modül ekosistemi sayesinde hem startup'lar hem de büyük kurumsal organizasyonlar tarafından tercih edilir. Ancak Terraform'un gücünü güvenli, sürdürülebilir ve ölçeklenebilir hale getirmek dikkatli bir mimari, operasyonel disiplin ve iyi tanımlanmış süreçler gerektirir.

Neden bugün önemli?

• Bulut altyapıları hızla büyüyor; manuel operasyonlar sürdürülemez hâle geliyor.
• Multi‑account, multi‑region ve multi‑cloud stratejileri yönetilebilir araçlar olmadan karmaşıklaşıyor.
• Regülasyon, audit ve güvenlik gereksinimleri altyapının versiyonlanmasını zorunlu kılıyor.

Kimler için önemli?

• Platform mühendisleri, DevOps ve SRE ekipleri
• Bulut mimarları ve altyapı yöneticileri
• Yazılım ekipleri — altyapıya yakın çalışan backend ve platform geliştiricileri

Hangi problemleri çözüyor?

• Tekrarlanabilir altyapı kurulumları
• Çevreler arası tutarsızlıkların (drift) azaltılması
• Değişikliklerin izlenebilirliği ve hızlı geri alınması

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• State: Terraform'un mevcut altyapı durumunu tuttuğu veri; doğru yönetilmediğinde çakışmalar ve veri kaybı riskleri oluşturur.
• Module: Tekrar kullanılabilir, sınırları belirlenmiş altyapı bileşeni. İyi tasarlanmış modüller güvenlik ve tekrar kullanım getirir.
• Provider: Bulut servisiyle etkileşimi sağlayan eklenti (AWS, Azure, GCP, Kubernetes vb.).
• Workspace / Backend: State'in saklandığı, paylaşıldığı ve kilitlendiği altyapı bileşeni.

2.2 Mimari bileşenler

1. Konfigürasyon kodu (HCL)
2. Remote state backend (S3 + DynamoDB, Azure Blob, Terraform Cloud)
3. CI/CD pipeline (plan → review → apply)
4. Policy as Code (Sentinel, OPA)
5. Secrets management (Vault, KMS)

2.3 Terminoloji

• Plan: Terraform'un uygulanacak değişiklikleri hesaplama aşaması.
• Apply: Planlanan değişikliklerin provider API'leriyle uygulanması.
• Drift: Terraform konfigürasyonuyla gerçek altyapı arasındaki farklar.

3. NASIL ÇALIŞIR? — Pratik Akış ve Entegre Mimariler

3.1 Tipik workflow

1. Developer kodu feature branch'te yazar ve PR açar.
2. CI pipeline 'terraform fmt', 'terraform validate', 'terraform plan' çalıştırır ve planı PR'a ekler.
3. Policy as Code kuralları (ör. OPA) PR aşamasında kontrol edilir; uygunsuzsa reddedilir.
4. İnceleme sonrası merge; merge tetikleyicisi apply job'u (manuel onaylı veya otomatik) çalıştırır.
5. Apply başarılı ise state güncellenir; hataysa rollback veya remediation senaryosu devreye girer.

3.2 Remote state ve locking

Remote state kullanımı ekip çalışması için zorunludur. State locking (ör. DynamoDB ile S3 backend) aynı anda iki apply işleminin çakışmasını engeller. State'e erişim IAM politikalarıyla sınırlandırılmalıdır.

3.3 Environment ve workspace stratejileri

• Her environment (dev/stage/prod) için ayrı backend veya workspace kullanın: state izolasyonu ve yetki kontrolü açısından kritik.
• Stack/stackset kavramlarıyla hesap/account/region bazlı ayırma yapın.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Repeatability ve Guardrail'lar

Netflix ölçeğinde altyapı, modüler Terraform kodu ve otomatik bootstrap süreçleriyle yönetilir. Guardrail'lar (policy as code) ile yanlış konfigurasyonların production'a gitmesi engellenir.

Uber — Multi‑account ve Ağ Topolojileri

Uber tipi organizasyonlarda VPC, peering, routing ve account provisioning otomatikleştirilir; modüller standardize edilip region/account bazlı parametrelerle özelleştirilir.

Amazon — Policy ve Compliance

AWS tabanlı büyük kuruluşlar Terraform'u IAM, SCP ve policy as code ile entegre ederek compliance sağlar; plan çıktıları otomatik politikalarla taranır.

OpenAI — MLOps ve Ephemeral Environments

MLOps için ephemeral infra (GPU instance, training cluster) Terraform ile kurulup yıkılır; reproducibility ve maliyet kontrolü sağlanır.

Stripe — Finansal Sistemler ve Audit

Fintech süreçlerinde Terraform plan/apply geçmişi audit ve uyumluluk gereksinimleri açısından kritik veri sağlar; değişiklik onay süreçleri sıkıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Versiyonlanabilir altyapı ve süreçlerin tekrar üretilebilir olması
• Otomasyon ile hata yüzdesinin azalması ve hızlanmış provisioning
• Modüller sayesinde tekrar kullanılabilir şablonlar

Sınırlamalar

• State yönetiminin karmaşıklığı ve güvenlik riskleri
• Provider sürümleri ve resource semantics farklılıkları
• Drift kaynaklı beklenmeyen durumlar

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Production kullanımı

• Remote state kullanın ve state backend'ini şifreleyip erişimi IAM rolleriyle sınırlandırın.
• Plan → Review → Apply şeklinde PR tabanlı iş akışı kurun; plan çıktısını PR'a otomatik ekleyin.
• Apply adımını otomatikleştirmeden önce manuel onay mekanizması uygulayarak insan gözetimini sağlayın (özellikle prod için).
• Module'ları registry veya git tag'leri ile versiyonlayın; breaking değişiklikleri semantik versiyonlama ile yönetin.

7.2 Performans optimizasyonu

• Dependency graph'ı göz önünde bulundurarak paralelizm parametresini ayarlayın (terraform apply -parallelism).
• Large state'lerde sharding stratejisi kullanın: account/region/service bazlı state'ler performansı artırır.
• Targeted apply kullanımı dikkat gerektirir; sadece acil/izole değişikliklerde tercih edin ve sonuçları doğrulayın.

7.3 Güvenlik

• Secrets'ı konfigürasyon ve state içinde saklamayın; secrets manager referansları kullanın (Vault, AWS Secrets Manager, Azure Key Vault).
• State encryption ve access control uygulayın; state snapshot'larına erişimi kısıtlayın.
• Policy as Code ile plan aşamasında güvenlik ve uyumluluk kontrollerini zorunlu hale getirin (OPA/Sentinel).

7.4 Ölçeklenebilirlik

• Repo organizasyonunu domain‑driven olarak tasarlayın: küçük, bağımsız modüller ve stack'ler kullanın.
• Automated bootstrap pipeline'ları ile yeni account/cluster provisioning sürecini standartlaştırın.
• Module governance: ortak modüller için review, API contract, changelog ve deprecation politikaları belirleyin.

8. SIK YAPILAN HATALAR

• Local state kullanmak: Ekip ortamında çakışma ve veri kaybına sebep olur.
• Secrets'ı düz metin olarak repo veya state içinde bırakmak: ciddi güvenlik açıkları oluşturur.
• Plan adımını atlayıp doğrudan apply yapmak: beklenmeyen kaynak değişiklikleri ve maliyet artışları getirebilir.
• Module'ları overfit etmek: her ekip kendi modülünü yazarak tekrar ve karmaşıklık yaratır.
• Drift'i göz ardı etmek: zamanla production altyapısı konfigürasyondan sapar ve sorunlar zor tespit edilir.

9. GELECEK TRENDLER

1. Policy as Code integrasyonu: Compliance ve güvenlik kontrollerinin plan aşamasında otomatik uygulanması daha yaygın olacak.
2. GitOps + Terraform kombinasyonları: Altyapı ve uygulama manifest'lerinin aynı GitOps pipeline'larında uyumlu yönetimi artacak.
3. AI destekli IaC: Resource sizing, cost optimization ve drift detection için ML tabanlı öneri sistemleri ortaya çıkacak.
4. Infrastructure as Software: Altyapı geliştirme pratikleri (code review, unit testing, CI) daha da standartlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Terraform state'i nerede saklamalıyım?

   Production'da remote, şifrelenmiş ve locking destekli backend kullanın (örn. S3 + DynamoDB, Azure Blob + storage lease, Terraform Cloud).

2. Module'ları nasıl versiyonlamalıyım?

   Git tag veya Terraform Registry versiyonlama kullanın; semantik versiyonlamayı (MAJOR.MINOR.PATCH) takip edin.

3. Secrets'ı nasıl yönetmeliyim?

   Secrets'ı Git veya state içinde tutmayın. Vault, AWS Secrets Manager veya Azure Key Vault gibi çözümlerle referanslayın.

4. Plan çıktısını PR'a nasıl otomatik eklerim?

   CI pipeline'da 'terraform plan -out' çalıştırıp plan özetini PR yorumuna veya artifact'a yazdırabilirsiniz; GitHub Actions/GitLab CI entegrasyonları yaygın yöntemlerdir.

5. Drift'i nasıl tespit ederim?

   Periyodik 'terraform plan' veya drift detection job'ları çalıştırın; beklenmeyen değişiklikler için Slack/Alert sistemlerine bildirim gönderin.

6. Apply işlemlerini otomatikleştirirken nelere dikkat etmeliyim?

   Production apply'leri için insan onayı, canary planları ve plan incelemesi şarttır. Otomatik apply yalnızca düşük riskli veya non‑prod ortamlar için uygundur.

7. Terraform ile test nasıl yapılır?

   Terratest, kitchen‑terraform veya Pulumi test framework'leriyle unit ve integration test'ler oluşturun; ephemeral environment'lar kullanarak integration test'leri çalıştırın.

8. Terraform Cloud/Enterprise kullanmalı mıyım?

   Büyük ekiplerde governance, remote state, policy enforcement ve iş akışı yönetimi için Terraform Cloud/Enterprise ciddi fayda sağlar. Küçük projelerde self‑managed backend yeterli olabilir.

Anahtar Kavramlar

State

Terraform'un kaynak durumunu tuttuğu veri — paylaşılmalı, kilitlenmeli ve şifrelenmelidir.

Module

Tekrar kullanılabilir altyapı parçası; versiyonlanmalı ve sınırları net olmalıdır.

Plan

Terraform'un uygulayacağı değişikliklerin hesaplandığı aşama; PR sürecine entegre edilmelidir.

Policy as Code

Uyumluluk ve güvenlik kurallarının kod şeklinde tanımlanması ve CI veya runtime aşamasında doğrulanması.

Drift

Konfigürasyon ile gerçek altyapı arasındaki uyumsuzluk — düzenli olarak tespit edilip yönetilmelidir.

Öğrenme Yol Haritası

1. 0–1 ay: Terraform temel komutları, HCL, küçük bir resource (örn. S3 veya storage) oluşturma.
2. 1–3 ay: Module yazımı, remote state backend, workspace yönetimi ve basit CI entegrasyonu.
3. 3–6 ay: Terratest, policy as code (OPA/Sentinel), secrets pattern'leri ve module governance.
4. 6–12 ay: Multi‑account/multi‑region yapılandırmaları, automated bootstrap, drift remediation ve Terraform Cloud/Enterprise özelliklerinde deneyim.