Terraform ve Kod Olarak Altyapı (IaC)

Bulut bilişim (Cloud Computing) devriminin ilk yıllarında sistem yöneticileri ve DevOps mühendisleri; sanal sunucuları (EC2, Compute Engine), sanal özel ağları (VPC), yük dengeleyicileri (Load Balancers), yönetilen veritabanlarını (RDS, Cloud SQL) ve güvenlik duvarı kurallarını AWS, Google Cloud veya Microsoft Azure web konsollarına girip fareyle tıklayarak oluşturuyordu. Sektörde "ClickOps" olarak adlandırılan bu manuel yönetim biçimi, birkaç sunucudan oluşan küçük projelerde hızlı bir başlangıç sağlasa da kurumsal ölçekte felakete davetiye çıkarır. Test ortamı (Staging) ile canlı ortamın (Production) birbirinden tamamen farklılaşması, kimin hangi güvenlik portunu neden açtığının bilinmemesi ve olası bir veri merkezi felaketinde altyapıyı sıfırdan ayağa kaldırmanın günler sürmesi, modern yazılım mühendisliğini Infrastructure as Code (IaC - Kod Olarak Altyapı) paradigmasına taşımıştır. Uygulama ve yazılım mimarileri dünyasında bulut otomasyonunun tartışmasız omurgasını oluşturan IaC kavramını; Terraform, OpenTofu, Pulumi ve Ansible ekosistemlerini, bildirimsel (declarative) ve buyurgan (imperative) yaklaşımları, Remote State (Uzak Durum) kilitleme mekanizmalarını ve Policy-as-Code güvenlik standartlarını tüm teknik derinliğiyle inceliyoruz.

1. ClickOps'un Çöküşü ve Infrastructure as Code (IaC) Devrimi

Geleneksel veri merkezi yönetiminde ve erken dönem bulut kullanımında sunucular birer "evcil hayvan" (Pets) gibi görülürdü. Her sunucuya özel bir isim verilir, içine SSH ile bağlanılıp paketler elle kurulur, yapılandırma dosyaları (nginx.conf, sysctl.conf) sunucu üzerinde manuel olarak düzenlenir ve o sunucu bozulduğunda düzeltmek için saatlerce uğraşılırdı. Yıllar içinde üzerinde yüzlerce kez dokümante edilmemiş manuel değişiklik yapılan bu tür sunuculara yazılım mühendisliğinde "Snowflake Server" (Kar Tanesi Sunucu) adı verilir; çünkü tıpkı doğadaki kar taneleri gibi dünyada o sunucunun birebir eşi olan ikinci bir sunucu daha yoktur ve yeniden üretilmesi (reproducibility) imkansıza yakındır.

Infrastructure as Code (IaC) ise sunucuları ve tüm bulut kaynaklarını "evcil hayvan" yerine numaralandırılmış "sürü" (Cattle) elemanları olarak ele alır. Ağ topolojisi, alt ağlar (Subnets), yönlendirme tabloları (Route Tables), Kubernetes kümeleri (EKS, GKE, AKS), S3 depolama kovaları, IAM (Kimlik ve Erişim Yönetimi) rolleri ve DNS kayıtları insan tarafından okunabilir, Git versiyon kontrol sisteminde saklanan kaynak kod dosyaları olarak tanımlanır. Bir sunucuda veya ortamda sorun çıktığında içine girip tamir edilmeye çalışılmaz; mevcut kaynak yok edilir ve koddan saniyeler içinde birebir aynı özelliklerde yenisi oluşturulur (Immutable Infrastructure - Değiştirilemez Altyapı).

Özellikle bulut teknolojisi ve SaaS dönüşümü yaşayan kurumsal yapılarda IaC kullanımı dört stratejik kazanım sağlar:

• Ortam Eşitliği (Environment Parity): Geliştirme (Dev), Test (Staging) ve Canlı (Production) ortamları aynı Terraform modülünden, yalnızca sunucu boyutu ve kopya sayısı gibi parametreler (terraform.tfvars) değiştirilerek üretilir. "Test ortamında çalışıyordu ama canlıda patladı" sorunu mimari düzeyde çözülür.
• Denetlenebilirlik ve Versiyon Kontrolü: Tıpkı uygulama kodunda olduğu gibi, bir güvenlik grubu kuralı veya veritabanı parametresi değiştirileceğinde Git üzerinden Pull Request açılır, ekip arkadaşları değişikliği inceler (Code Review) ve kimin, ne zaman, hangi iş gereksinimiyle altyapıyı değiştirdiği kalıcı olarak kayıt altına alınır.
• Hız ve Maliyet Optimizasyonu (Ephemeral Environments): Her yeni Pull Request açıldığında IaC otomasyonu sayesinde o PR'a özel, sıfırdan izole bir test ortamı 5 dakikada ayağa kaldırılır; PR birleştirildiğinde ise tek bir komutla (terraform destroy) tüm kaynaklar silinerek bulut faturasının gereksiz şişmesi önlenir.
• Felaket Kurtarma (Disaster Recovery - DR): Birincil bulut bölgesinde (örneğin eu-central-1 Frankfurt) bölgesel bir kesinti yaşandığında, tüm şirket altyapısı bölge parametresi değiştirilerek (örneğin eu-west-1 İrlanda) dakikalar içinde başka bir veri merkezinde ayağa kaldırılabilir.

2. Bildirimsel (Declarative) vs. Buyurgan (Imperative) Yaklaşım

Kod olarak altyapı araçları, altyapıyı tanımlama felsefelerine göre iki ana kategoriye ayrılır: Bildirimsel (Declarative) ve Buyurgan / Yordamsal (Imperative / Procedural). Bu ayrımı anlamak, doğru aracı doğru katmanda konumlandırmak için hayati önem taşır.

2.1. Buyurgan (Imperative) Yaklaşım: "Nasıl" Yapılacağını Tarif Etmek

Buyurgan yaklaşımda mühendis, hedef duruma ulaşmak için çalıştırılması gereken komutları adım adım sıralar (AWS CLI betikleri, Bash script'leri veya klasik yapılandırma araçlarının bazı modları). Örneğin: "1. Adım: Bir VPC oluştur. 2. Adım: Bu VPC içinde 3 adet EC2 sunucusu başlat. 3. Adım: Bunları yük dengeleyiciye bağla."

Buyurgan yaklaşımın en büyük sorunu İdempotentlik (Idempotency - Eşgüçlülük) eksikliğidir. Aynı Bash betiğini yanlışlıkla ikinci kez çalıştırırsanız, sistemde zaten 3 sunucu olduğunu anlamaz ve 3 sunucu daha oluşturarak toplam sunucu sayısını 6'ya çıkarır veya "Aynı isimde VPC zaten var" diyerek hata verip yarıda kesilir. Ayrıca sunucu sayısını 3'ten 2'ye düşürmek istediğinizde, mevcut betiği değiştirmek yetmez; 3. sunucuyu silecek ayrı bir silme (teardown) betiği yazmanız gerekir.

2.2. Bildirimsel (Declarative) Yaklaşım: "Ne" İstenildiğini Tarif Etmek

Terraform, OpenTofu ve CloudFormation gibi bildirimsel araçlarda ise sisteme adım adım komut vermezsiniz; yalnızca nihai hedef durumu (Desired State) tanımlarsınız. Örneğin: "Sistemde 10.0.0.0/16 bloklu bir VPC ve içinde 3 adet uygulama sunucusu bulunmalıdır."

Bildirimsel motor mevcut durumu (Current State) kontrol eder; eğer hiç sunucu yoksa 3 tane oluşturur. Aynı kodu 100 kez üst üste çalıştırsanız bile sistemde zaten 3 sunucu olduğunu görür ve No changes. Your infrastructure matches the configuration. mesajını dönerek hiçbir işlem yapmaz (Tam İdempotentlik). Kod içindeki count = 3 değerini count = 2 olarak değiştirip tekrar çalıştırdığınızda ise nasıl sileceğinizi tarif etmenize gerek kalmadan fazladan olan 1 sunucuyu kendisi tespit edip güvenli şekilde sonlandırır.

3. Terraform ve OpenTofu Mimarisi: HCL, Yaşam Döngüsü ve State Yönetimi

HashiCorp tarafından geliştirilen Terraform ve onun Linux Foundation çatısı altında açık kaynaklı olarak çatallanan (fork) topluluk sürümü OpenTofu, bulut-agnostik (Cloud-Agnostic) IaC dünyasının altın standardıdır. HCL (HashiCorp Configuration Language) adı verilen hem insan hem makine tarafından kolayca ayrıştırılabilen bildirimsel bir dil kullanır.

3.1. Terraform Yaşam Döngüsü: Init, Plan, Apply, Destroy

Güvenilir bir altyapı boru hattı dört temel aşamadan geçer:

1. terraform init: Çalışma dizinini başlatır, kullanılan sağlayıcı eklentilerini (AWS Provider, Cloudflare Provider, Kubernetes Provider vb.) indirir ve uzak durum (Remote State) arka uç bağlantısını kurar.
2. terraform plan: IaC dünyasının en güçlü güvenlik ağıdır. Terraform; yazdığınız HCL kodunu, durum dosyasını (State) ve gerçek bulut ortamındaki canlı kaynakları API üzerinden karşılaştırır. Hiçbir kaynağı değiştirmeden önce size nelerin ekleneceğini (+ create), nelerin yerinde güncelleneceğini (~ update in-place) ve nelerin silinip yeniden oluşturulacağını (-/+ destroy and recreate) gösteren deterministik bir yürütme planı sunar. Örneğin bir RDS veritabanının şifreleme parametresini değiştirdiğinizde bunun veritabanını silip yeniden oluşturacağını plan çıktısında önceden görerek olası bir veri kaybını engellersiniz.
3. terraform apply: Onaylanan yürütme planını kaynaklar arasındaki bağımlılık grafiğine (Directed Acyclic Graph - DAG) göre paralel olarak bulut sağlayıcı API'lerine uygular. Örneğin önce VPC'yi, ardından alt ağları, en son bu alt ağlara bağlı sunucuları doğru sırayla oluşturur.
4. terraform destroy: Bağımlılık grafiğini tersine işletir; önce sunucuları, sonra alt ağları, en son VPC'yi temizleyerek yetim (orphaned) bulut kaynağı bırakmadan ortamı tamamen kapatır.

3.2. Terraform State (`terraform.tfstate`) ve Uzak Kilitleme (State Locking)

Terraform'un hangi kod bloğunun gerçek dünyadaki hangi bulut kaynağına (örneğin aws_instance.web kaynağının AWS'deki i-0a1b2c3d4e5f6g7h8 ID'li sunucuya) karşılık geldiğini bilmesi için State (Durum) adı verilen bir JSON haritası tutması gerekir. Bu durum dosyası mimarinin kalbidir ve yönetiminde üç altın kural geçerlidir:

• State Dosyası Asla Git'e Konulmaz: terraform.tfstate dosyası hem sürekli değişen dinamik çalışma zamanı verilerini hem de veritabanı başlangıç şifreleri, özel sertifikalar gibi hassas verileri düz metin (plaintext) olarak barındırabilir. Bu nedenle .gitignore dosyasına mutlaka eklenmelidir.
• Remote State (Uzak Durum Depolama): Ekip halinde çalışabilmek için State dosyası geliştiricinin yerel bilgisayarında değil; şifrelenmiş bir merkezi depoda (AWS S3, Google Cloud Storage, Azure Blob Storage veya Terraform Cloud / Spacelift / Env0) tutulmalıdır.
• State Locking (Durum Kilitleme): İki DevOps mühendisi aynı anda aynı ortam için terraform apply çalıştırırsa State dosyası bozulur (race condition) ve bulutta mükerrer veya yarım kalmış kaynaklar oluşur. Bunu önlemek için DynamoDB (AWS S3 ile birlikte) veya GCS yerel kilitleme mekanizmaları kullanılır. Bir işlem başladığında durum dosyası kilitlenir; ikinci işlem kilit açılana kadar bekletilir veya reddedilir.

4. Configuration Drift (Yapılandırma Kayması) Önleme ve Modüler Altyapı

Kurumsal bulut mimarilerinde en sık karşılaşılan operasyonel sorunlardan biri Configuration Drift (Yapılandırma Kayması) problemidir. Altyapı başlangıçta Terraform ile kusursuz biçimde kurulur; ancak haftalar sonra bir mühendis acil bir entegrasyon testi için AWS konsoluna girip bir Security Group üzerinde 8080 portunu dünyaya (0.0.0.0/0) manuel olarak açar ve işi bitince kapatmayı unutur. Artık gerçek bulut ortamı, Git deposundaki Terraform kodundan sapmıştır.

Bu sinsi riski ortadan kaldırmak için modern platform mühendisliği ekipleri Scheduled Drift Detection (Zamanlanmış Kayma Tespiti) uygular. CI/CD sistemi (veya Atlantis, Spacelift, Terrateam gibi GitOps tabanlı IaC orkestratörleri) her gece veya her saat başı tüm ortamlarda terraform plan -detailed-exitcode komutunu arka planda çalıştırır. Eğer çıkış kodu 2 dönerse (yani Git'te hiçbir commit olmamasına rağmen bulutta bir değişiklik tespit edilirse), sistem Slack veya PagerDuty üzerinden güvenlik ekibine anında alarm gönderir ve bir sonraki apply işleminde bu yetkisiz değişikliği ezerek altyapıyı tekrar kodda tanımlanan güvenli duruma döndürür.

4.1. DRY İlkesi: Yeniden Kullanılabilir Modüller ve Terragrunt

Yüzlerce mikroservisin ve onlarca farklı ortamın bulunduğu büyük organizasyonlarda her proje için VPC, EKS kümesi ve RDS veritabanı kodlarını kopyala-yapıştır yapmak bakımı imkansız hale getirir. Bunun yerine Terraform Modules (Modüller) kullanılır. Platform ekibi; şirket içi şifreleme standartlarını, yedekleme politikalarını, maliyet etiketlerini (CostCenter, Environment, Owner tags) ve ağ kurallarını barındıran merkezi, sürümlendirilmiş (versioned) iç modüller yazar. Uygulama ekipleri 500 satırlık karmaşık AWS kaynağı tanımlamak yerine sadece 15 satırlık bir module "postgres_db" bloğu çağırarak saniyeler içinde şirket standartlarına %100 uyumlu bir veritabanı talep edebilir. Çoklu ortam ve çoklu hesap (Multi-Account AWS Organizations) yönetiminde kod tekrarını sıfıra indirmek için ise Terragrunt sarmalayıcısı yaygın olarak tercih edilir.

5. Ekosistem Karşılaştırması: Terraform / OpenTofu vs. Pulumi vs. Ansible

Altyapı otomasyonunda tek bir araç her sorunu çözmez. Altyapı sağlama (Provisioning) ile sunucu içi yapılandırma yönetimi (Configuration Management) farklı disiplinlerdir. Ayrıca son yıllarda HCL gibi alan-özel diller (DSL) yerine doğrudan TypeScript, Python veya Go gibi genel amaçlı programlama dilleriyle altyapı yazmayı sağlayan Pulumi ve AWS CDK güçlü birer alternatif olarak yükselmiştir.

Karşılaştırma Kriteri	Terraform / OpenTofu	Pulumi	Ansible
Temel Kategori	Altyapı Sağlama (Infrastructure Provisioning)	Altyapı Sağlama (Infrastructure Provisioning)	Yapılandırma Yönetimi (Configuration Management)
Mimari Yaklaşım	Bildirimsel (Declarative)	Bildirimsel (Genel amaçlı dil gücüyle)	Hibrit / Yordamsal (Procedural - YAML Playbooks)
Kullanılan Dil	HCL (HashiCorp Configuration Language)	TypeScript, Python, Go, C#, Java	YAML (Jinja2 şablon desteği ile)
Durum (State) Yönetimi	State Dosyası Zorunlu (.tfstate)	State Dosyası Zorunlu (Pulumi Cloud / S3)	Durumsuz (Stateless - SSH üzerinden anlık kontrol)
En Güçlü Olduğu Alan	Bulut kaynakları (VPC, K8s, RDS, IAM, DNS) oluşturma ve yaşam döngüsü yönetimi	Karmaşık döngüler, soyutlamalar ve uygulama geliştiricilerin kendi dilinde IaC yazması	Var olan sanal/fiziksel sunucuların içine paket kurma, OS yamalama, servis başlatma
Değiştirilemezlik (Immutability)	Değiştirilemez (Immutable) altyapı odaklı	Değiştirilemez (Immutable) altyapı odaklı	Değiştirilebilir (Mutable - sunucu içi güncelleme) odaklı

Terraform ve Ansible Birlikte Nasıl Kullanılır? Modern hibrit mimarilerde bu iki araç rakip değil tamamlayıcıdır. Önce Packer ve Ansible kullanılarak işletim sistemi güvenlik sıkılaştırmaları (CIS Hardening) ve gerekli ajanları önceden kurulmuş bir "Altın İmaj" (Golden Image / AMI) üretilir. Ardından Terraform devreye girerek bu hazır imajı kullanan Auto Scaling gruplarını, ağ topolojisini ve yük dengeleyicileri bulut üzerinde saniyeler içinde ayağa kaldırır.

6. Policy-as-Code (Kod Olarak Politika), FinOps ve Güvenlik Otomasyonu

Altyapı tamamen kodlaştığında, siber güvenlik ve maliyet kontrolü de canlıya çıkmadan önce (Shift-Left Security) PR aşamasında otomatik olarak denetlenebilir. Yapay zeka ve tersine mühendislik teknikleriyle siber saldırıların otomatikleştiği günümüzde, yanlış yapılandırılmış tek bir açık S3 kovası veya şifrelenmemiş bir veritabanı diski milyonlarca dolarlık veri ihlaline yol açabilir.

• Statik IaC Güvenlik Taraması (tfsec / Trivy / Checkov): Geliştirici daha kodu canlıya uygulamadan önce HCL dosyalarını tarar; örneğin 0.0.0.0/0 dünyaya açık bir SSH (22) portu, şifrelemesi (KMS) kapalı bir EBS diski veya herkese açık (public-read) bir depolama kovası görürse PR'ı otomatik olarak reddeder.
• Open Policy Agent (OPA / Rego) ve Sentinel: Kurumsal yönetişim kurallarını kod olarak tanımlar. Örneğin: "Üretim ortamında yalnızca eu-central-1 bölgesinde kaynak açılabilir" veya "Etiketi (Tag) olmayan hiçbir bulut kaynağı oluşturulamaz" kuralları terraform plan JSON çıktısı üzerinde otomatik olarak işletilir.
• Infracost ile FinOps Entegrasyonu: Bir geliştirici Terraform kodunda sunucu tipini t3.medium yerine m5.8xlarge olarak değiştirdiğinde, Infracost aracı PR altına otomatik bir yorum bırakır: "Bu değişiklik aylık bulut faturanızı +$1,420.00 (%38) artıracaktır." Böylece mühendislik kararlarının finansal etkisi kod birleştirilmeden önce şeffaf biçimde görülür.

Bu otomasyon disiplini; Web3 ve merkezsiz blokzincir altyapılarındaki yüksek erişilebilirlikli düğüm kümelerinden, kodsuz B2B bayi portallarını barındıran çok bölgeli bulut mimarilerine kadar her ölçekte sıfır hata payı ile büyümeyi mümkün kılar.

7. Sıkça Sorulan Sorular (SSS)

1. Terraform ile OpenTofu arasındaki fark nedir, hangisini seçmeliyiz?

HashiCorp Ağustos 2023'te Terraform'un lisansını açık kaynaklı MPL 2.0'dan, rakip ticari ürün geliştirmeyi kısıtlayan BSL (Business Source License) lisansına değiştirdi. Bunun üzerine geniş bir endüstri koalisyonu Linux Foundation çatısı altında Terraform 1.5.x sürümünü çatallayarak %100 açık kaynaklı OpenTofu projesini başlattı. Teknik olarak her ikisi de aynı HCL sözdizimini ve sağlayıcıları (Providers) kullanır; OpenTofu ayrıca durum dosyası şifreleme (client-side state encryption) gibi topluluk tarafından uzun süredir istenen ek özellikler sunmaktadır. Tam açık kaynak güvencesi arayan kurumlar OpenTofu'yu, HashiCorp'un kurumsal bulut ekosistemini (HCP Terraform) kullananlar ise Terraform'u tercih edebilir.

2. Halihazırda konsoldan elle (ClickOps ile) kurulmuş büyük bir bulut altyapımız var, bunu kesintisiz olarak Terraform'a nasıl taşırız?

Canlı çalışan kaynakları silip baştan kurmanıza gerek yoktur. Terraform 1.5 ve sonrasında gelen bildirimsel import blokları (veya Google tarafından geliştirilen Terraformer gibi tersine mühendislik araçları) sayesinde mevcut canlı kaynakların ID'lerini belirterek hem durum dosyasına (State) aktarabilir hem deterraform plan -generate-config-out=generated.tf komutuyla mevcut altyapınızın HCL kodunu otomatik olarak üretebilirsiniz. Böylece sıfır kesintiyle (zero-downtime) mevcut altyapınızı IaC yönetimine alabilirsiniz.

3. Tek bir devasa State dosyası (Monolithic State) neden tehlikelidir ve nasıl bölünmelidir?

Tüm şirketin ağ, veritabanı, Kubernetes ve uygulama katmanlarını tek bir Terraform State dosyasında tutmak üç ciddi soruna yol açar: terraform plan işlemi binlerce kaynağı API üzerinden sorguladığı için 20-30 dakikaya kadar yavaşlar, küçük bir değişiklik yaparken yanlışlıkla kritik bir veritabanını etkileme riski (Blast Radius - Patlama Çapı) büyür ve durum kilitlemesi (State Lock) yüzünden tüm ekip birbirini bekler. En iyi pratik; durum dosyalarını katmanlara (01-network, 02-database, 03-kubernetes, 04-apps) ve ortamlara (dev, staging, prod) göre bölmek, katmanlar arası veri paylaşımını ise terraform_remote_state veri kaynağı veya SSM Parameter Store üzerinden yapmaktır.

4. Terraform gerçekten "Bir kez yaz, her bulutta çalıştır" (Cloud-Agnostic) sağlar mı?

Bu yaygın bir yanılgıdır. Terraform'un iş akışı, dili (HCL) ve yönetim modeli bulut-agnostiktir; ancak yazdığınız kaynak kodları bulut sağlayıcısına özeldir. AWS için yazdığınız aws_instance ve aws_vpc kodunu olduğu gibi Google Cloud'da çalıştıramazsınız; Google Cloud için google_compute_instance yazmanız gerekir. Ancak tüm bulut sağlayıcılarını, Cloudflare'i, Datadog'u, GitHub'ı ve PostgreSQL'i tek bir dil (HCL) ve tek bir durum yönetimi altında birleştirmesi Terraform'un asıl süper gücüdür.

5. Kubernetes içindeki Deployment ve Service nesnelerini de Terraform ile mi yönetmeliyiz?

Mimari sınır (Separation of Concerns) olarak önerilen en iyi pratik şudur: Bulut altyapısını, VPC ağlarını, IAM rollerini, yönetilen veritabanlarını ve Kubernetes kümesinin kendisini (EKS/GKE/AKS) Terraform ile oluşturun. Küme ayağa kalktıktan sonra, küme içine ArgoCD veya Flux kurulumunu da Terraform ile yapın; ancak küme içindeki uygulama dağıtımlarını (Deployment, Service, Ingress, HPA) Terraform ile değil, GitOps (ArgoCD / Flux) ile yönetin. Böylece altyapı yaşam döngüsü ile günlük uygulama sürümleri birbirinden temiz bir şekilde ayrılır.