Manuel olarak tıklanarak oluşturulan sunucular, ağ kuralları ve veritabanları zamanla belirsizleşir. Kim hangi değişikliği yaptı, test ortamı üretimle neden farklı, felaket anında altyapıyı nasıl yeniden kurarız — bu soruların cevabı genellikle bir kişinin hafızasına sıkışmıştır. Infrastructure as Code (IaC), altyapı tanımlarını versiyon kontrolü altına alarak bu belirsizliği ortadan kaldırır.
IaC'nin temel faydaları
Kod olarak tanımlanan altyapı tekrarlanabilir, gözden geçirilebilir ve otomatik test edilebilir. Bir pull request'te ağ güvenlik grubuna yeni bir kural eklendiğinde, ekip üyeleri değişikliği inceleyebilir ve onaylayabilir. Bu, üretim ortamında "kimse fark etmeden açılan port" riskini azaltır.
- Tutarlılık: Aynı kod, aynı altyapıyı üretir
- Hız: Ortam oluşturma dakikalar sürer, günler değil
- Denetlenebilirlik: Git geçmişi değişiklik izini tutar
- Geri alınabilirlik: Önceki commit'e dönerek altyapı eski haline getirilebilir
Deklaratif ve emirsel yaklaşım
IaC araçları iki ana paradigma kullanır. Emirsel (imperative) yaklaşımda adım adım komutlar verilir: "şu sunucuyu oluştur, şu paketi yükle". Ansible ve eski Shell scriptleri bu kategoridedir. Deklaratif (declarative) yaklaşımda istenen son durum tanımlanır: "iki adet t3.medium instance olsun, load balancer arkasında çalışsın". Terraform, AWS CloudFormation ve Pulumi bu modeli kullanır.
Deklaratif araçlar drift tespiti konusunda avantajlıdır. Mevcut durum ile tanımlanan durum karşılaştırılır; fark varsa plan aşamasında gösterilir.
Terraform ile pratik başlangıç
Terraform, HashiCorp'un açık kaynak IaC aracıdır. HCL (HashiCorp Configuration Language) ile kaynak tanımlanır. Temel dosya yapısı:
project/
main.tf # kaynak tanımları
variables.tf # girdi parametreleri
outputs.tf # çıktı değerleri
terraform.tfvars # ortam-spesifik değerler
backend.tf # state depolama yapılandırmasıBasit bir Azure resource group örneği:
resource "azurerm_resource_group" "app" {
name = var.resource_group_name
location = var.location
tags = {
environment = var.environment
managed_by = "terraform"
}
}State yönetimi
Terraform state dosyası, oluşturulan kaynakların gerçek kimliklerini tutar. State kaybedilirse Terraform mevcut altyapıyı tanıyamaz. Üretim ortamlarında state uzak backend'de saklanmalıdır: Azure Storage, AWS S3 + DynamoDB lock, Terraform Cloud. State dosyası hassas bilgi içerebilir; erişim kısıtlanmalı ve şifrelenmelidir.
Ekip çalışmasında state lock mekanizması çakışmayı önler. İki kişi aynı anda terraform apply çalıştıramaz; lock alınır ve işlem sıraya girer.
Modülerleştirme
Tekrar eden altyapı kalıpları modül olarak çıkarılmalıdır. Bir "web-app" modülü; app service, veritabanı, key vault ve monitoring kaynaklarını bir arada tanımlayabilir. Modül parametreleri ile farklı ortamlar aynı kod tabanından beslenir:
module "web_app" {
source = "./modules/web-app"
environment = "staging"
sku = "B1"
db_size = "32GB"
}Modül sürümlemesi Git tag veya Terraform Registry ile yapılır. Üretim ortamında modül referansı sabit sürüme pinlenmelidir; main branch referansı beklenmedik değişikliklere yol açar.
Plan ve apply disiplini
Terraform iş akışı üç aşamadan oluşur:
- terraform plan: Yapılacak değişiklikleri önizler
- terraform apply: Onaylanan değişiklikleri uygular
- terraform destroy: Kaynakları siler (dikkatli kullanılmalı)
CI/CD pipeline'ında plan otomatik çalıştırılır; apply yalnızca onaylı merge sonrası tetiklenir. Plan çıktısı pull request yorumuna eklenerek değişiklik görünür kılınır.
Drift ve yapılandırma sapması
Manuel konsol değişiklikleri IaC tanımından sapmaya (drift) neden olur. Düzenli terraform plan çalıştırarak drift tespit edilir. Bazı ekipler "break-glass" prosedürü tanımlar: acil durumda manuel müdahale yapılabilir, ancak 24 saat içinde IaC kodu güncellenmelidir. Aksi halde bir sonraki apply beklenmedik kaynak silme veya yeniden oluşturma yapabilir.
GitOps ile birleşim
GitOps, Git deposunu altyapı ve uygulama durumu için tek doğruluk kaynağı (single source of truth) kabul eder. Argo CD veya Flux, Git'teki manifest değişikliklerini Kubernetes cluster'a otomatik uygular. IaC ile GitOps birlikte kullanıldığında:
- Altyapı katmanı Terraform ile (cluster, ağ, depolama)
- Uygulama katmanı GitOps ile (deployment, configmap, secret referansları)
Bu ayrım sorumlulukları netleştirir ve değişiklik hızını artırır.
Policy as Code
IaC kodu da yazılım gibi politikalara tabi tutulmalıdır. Open Policy Agent (OPA) veya HashiCorp Sentinel ile kurallar tanımlanır:
- Üretim ortamında halka açık storage bucket oluşturulamaz
- Tüm kaynaklarda
environmentetiketi zorunludur - Veritabanı şifreleme açık olmalıdır
Policy ihlali plan aşamasında engellenir; hatalı altyapı hiç oluşturulmaz.
Test stratejileri
IaC kodu test edilebilir. Katmanlar:
- Static analysis:
terraform validate, tflint, checkov güvenlik taraması - Unit test: terratest ile modül çıktılarının doğrulanması
- Integration test: Geçici ortam oluşturup kaynak varlığını kontrol etme
Maliyetli integration testler nightly pipeline'da çalıştırılır; geçici kaynaklar test sonrası destroy edilir.
Çoklu ortam yönetimi
Ortamlar arası farkları yönetmenin yaygın yöntemleri:
- Workspace: Terraform workspace ile aynı kod, farklı state
- Directory per environment: staging/, production/ klasörleri
- Variable files: staging.tfvars, production.tfvars
Üretim ve staging aynı modülleri kullanmalı; yalnızca parametreler (instance boyutu, replica sayısı) farklılaşmalıdır. Kod farkı ortamlar arası sürpriz davranışların ana nedenidir.
Yaygın hatalar
IaC yolculuğunda sık karşılaşılan tuzaklar:
- State dosyasını Git'e commit etmek (hassas veri sızıntısı)
- Modül sürümünü pinlememek
- Plan onayı olmadan doğrudan apply
- Import edilmemiş mevcut kaynakları görmezden gelmek
- Secrets'ı düz metin tfvars dosyasında tutmak
Secret yönetimi için environment variable, Vault veya cloud provider secret manager kullanılmalıdır.
Özet
Brownfield: mevcut altyapıyı içe aktarma
Çoğu ekip sıfırdan başlamaz; mevcut manuel oluşturulmuş kaynakları IaC'ye taşır. Terraform import komutu mevcut kaynağı state'e bağlar. Import sonrası kod ile gerçek durum eşleşene kadar iterasyon yapılır. Bu süreç ağır görünse de, import edilmemiş kaynakların bir sonraki apply'da silinme riski çok daha maliyetlidir.
Import stratejisi: önce düşük riskli kaynaklar (resource group, tag), ardından bağımlılık sırasına göre ağ, compute, veritabanı. Her import sonrası terraform plan ile "no changes" hedeflenir.
Maliyet ve kaynak etiketleme
IaC kodunda zorunlu etiketler (environment, team, cost-center) tanımlanır. Etiketsiz kaynak oluşturulması policy ile engellenir. FinOps raporları bu etiketlere dayanır; IaC disiplini maliyet görünürlüğünü de artırır. Kullanılmayan kaynakları tespit etmek için aylık terraform plan drift raporu ile cloud provider cost explorer birlikte değerlendirilir.
Alternatif IaC araçları
Terraform dışında değerlendirilebilecek araçlar:
- Pulumi: TypeScript, Python veya C# ile altyapı tanımı; geliştirici dostu
- AWS CDK: CloudFormation üzerinde programatik abstraction
- Crossplane: Kubernetes CRD ile altyapı yönetimi, GitOps-native
- Bicep: Azure'a özel, ARM template'den sade sözdizimi
Araç seçimi ekip yetkinliği ve cloud provider kapsamına göre yapılır. Multi-cloud hedefinde Terraform veya Pulumi öne çıkar; tek cloud'da native araç (CDK, Bicep) daha iyi entegrasyon sunabilir.
Rollback ve felaket kurtarma
IaC ile altyapı rollback, Git revert + terraform apply ile yapılır. Ancak veritabanı gibi stateful kaynaklarda dikkatli olunmalıdır; destroy ve recreate veri kaybına yol açabilir. lifecycle { prevent_destroy = true } kritik kaynaklarda etkinleştirilir. Felaket kurtarma tatbikatında altyapının sıfırdan kod ile yeniden oluşturulması test edilir; RTO hedefi bu tatbikatla doğrulanır.
Infrastructure as Code, modern DevOps pratiğinin temel taşlarından biridir. Terraform veya eşdeğer bir araçla başlamak, state yönetimini doğru kurmak ve CI/CD entegrasyonu sağlamak uzun vadeli operasyonel verimlilik getirir. Altyapıyı kod olarak yönetmek, hız ve güvenilirlik arasında sağlıklı bir denge kurar.
