Kod Olarak Altyapı (Infrastructure as Code) yıllar önce bir fark yaratıcı olmaktan çıktı; 2026'da artık asgari standart. Ekipleri hâlâ birbirinden ayıran şey, bunu ne kadar iyi işlettikleri: state'in bir yükümlülük mü yoksa sıradan bir detay mı olduğu, politikaların apply'dan önce mi zorlandığı yoksa bir olaydan sonra mı fark edildiği ve "production'da ne çalışıyor?" sorusunun Git tarafından mı yoksa bir arkeoloji seansıyla mı yanıtlandığı. Bu makale, IaC'yi sıkıcı (yani sorunsuz) tutan Terraform temellerini ve aynı disiplini Kubernetes iş yüklerine taşıyan GitOps katmanını ele alıyor.

Doğru Yapılan Terraform Temelleri

State, Hazine Odasıdır

Terraform state, kodunuzu gerçek kaynaklara eşler ve sıklıkla düz metin halinde secret'lar içerir. Yeri, kilitleme (locking) destekli, şifrelenmiş bir uzak backend'dir; erişimi de production kimlik bilgileriniz kadar sıkı kısıtlanmalıdır — asla repository'de olmamalıdır. Terraform 1.10'dan itibaren S3 backend'i yerleşik lockfile tabanlı kilitlemeyi destekliyor; dolayısıyla yeni konfigürasyonlar için ayrı bir DynamoDB tablosu artık gerekmiyor:

terraform {
  required_version = ">= 1.10"

  backend "s3" {
    bucket       = "org-terraform-state"
    key          = "network/prod/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

State'i patlama yarıçapına (blast radius) göre bölün: ortam ve bileşen başına bir state dosyası; böylece staging'deki bir modülde yapılan hata production ağını bozamaz. terraform state mv ile state cerrahisi ara sıra gereklidir; her hafta gerekiyorsa bu bir tasarım kokusudur.

Modüller: Küçük, Versiyonlu, Birleştirilebilir

İyi modüller tek bir kararı kapsüller — bir VPC yerleşimi, sıkılaştırılmış bir veritabanı instance'ı, standart bir IAM rol kümesi — ve küçük bir değişken yüzeyi sunar. Modül versiyonlarını registry kısıtlarıyla veya Git tag'leriyle sabitleyin ki upstream'deki bir değişiklik asla fark edilmeden production'a inmesin. Her şeyi saran dev "platform modülü"ne direnin: her tüketiciyi her değişikliğe bağlar ve her yükseltmeyi bir koordinasyon projesine çevirir.

Workspace'lerin İşi Dardır

Terraform workspace'leri, aynı konfigürasyonun geçici kopyaları için uygundur — önizleme ortamları, branch başına test stack'leri. Dev'i prod'dan ayırmak içinse yanlış araçtır; çünkü her workspace aynı backend konfigürasyonunu, aynı kod yolunu ve çoğu zaman aynı kimlik bilgilerini paylaşır. Gerçek ortamlar için ayrı state ve ayrı bulut hesaplarına sahip ayrı dizinleri (veya repository'leri) tercih edin ve patlama yarıçapını dizin yapısının kendisi açıkça göstersin.

Policy as Code

Kod incelemesi, bir uyumluluk mekanizması olarak ölçeklenmez. Kuralları — herkese açık okunabilir bucket yok, zorunlu maliyet etiketleri, onaylı instance aileleri, her yerde TLS 1.2 ve üzeri — OPA + Conftest, HashiCorp Sentinel veya Checkov gibi araçlarla, CI'da Terraform plan'a karşı değerlendirilen politikalar olarak kodlayın. Başarısız bir policy kontrolü, merge'ü yazarın üzerinde aksiyon alabileceği bir mesajla engeller; bu da aynı sorunu onuncu kez dile getiren bir insandan hem daha hızlı hem daha az sürtüşmelidir. Policy kontrollerinin yeri, terraform plan ile aynı pipeline'dır; o pipeline'ı kuruyorsanız, CI/CD'nin gerçekte neleri kapsadığına dair yazımız temelleri ele alıyor.

Drift Bir Sinyaldir, Baş Belası Değil

Drift, gerçeklik koddan saptığında ortaya çıkar: bir olay sırasında console'dan yapılan hotfix, "şuna bir bakayım" diyen bir operatör, işini yapan bir autoscaler. Tespiti için her state'e karşı zamanlanmış bir terraform plan çalıştırın ve boş olmayan diff'lerde alarm üretin. Sonra her bulguyu bilgi olarak ele alın — aynı yerde tekrarlayan drift genellikle kodda insanların gerçekten ihtiyaç duyduğu bir ayarın eksik olduğu anlamına gelir; çözüm o değişkeni eklemektir, ekibe nutuk çekmek değil.

ArgoCD ve Flux ile GitOps

Kubernetes iş yüklerinde GitOps, deployment modelini tersine çevirir: CI'ın manifest'leri cluster'a itmesi yerine, cluster içindeki bir controller — ArgoCD veya Flux — istenen durumu Git'ten sürekli çeker ve cluster'ı ona doğru uzlaştırır (reconcile). Kazanımlar yapısaldır. Drift düzeltme yerleşiktir; çünkü controller her sync'te Git'teki doğruyu yeniden uygular. Kimlik bilgileri iyileşir; çünkü cluster dışındaki hiçbir şeyin apply erişimine ihtiyacı kalmaz. Rollback ise git revert'tir — bunun ima ettiği eksiksiz denetim iziyle birlikte.

ArgoCD; UI, uygulama seviyesinde sağlık görünümleri ve app-of-apps kompozisyonu isteyen ekiplere uyar. Flux; Kustomize ve Helm ile birleşen, daha yalın, CRD güdümlü bir araç seti isteyen ekiplere uyar. İkisi de olgundur — seçim yetenek değil, ergonomi meselesidir. Hangisini seçerseniz seçin, production'da self-healing'li otomatik sync'i ancak alerting'iniz bir sync'in neden başarısız olduğunu söyleyebilir hale geldikten sonra açın; Gerçek hayatta Kubernetes yazımızdaki desenler burada birebir geçerlidir.

Değişiklikleri Ortamlar Arasında Terfi Ettirmek

Ortam terfisi (environment promotion), IaC ve GitOps disiplininin ya karşılığını verdiği ya da çöktüğü yerdir. Kural şu: rebuild'leri değil, artifact'leri terfi ettirin. Staging'den geçen container imajı, production'a ulaşan imajla bayt bayt aynıdır; yalnızca konfigürasyon — replica sayıları, kaynak limitleri, endpoint'ler — farklıdır ve Kustomize overlay'leri veya ortam başına Helm values olarak ifade edilir. Terfinin kendisi, ilgili ortamın dizinindeki bir imaj tag'ini veya values dosyasını güncelleyen, diğer tüm değişiklikler gibi incelenip merge edilen bir pull request'tir. Hiçbir ortam özel değildir: dev, staging ve prod veri ve ölçekte farklılaşır, mekanizmada asla.

Bunu doğru kuran ekipler, altyapı değişikliklerini uygulama koduyla aynı tempo ve güvenle yayınlar. Sizinki henüz o noktada değilse — laptop'lara dağılmış state'ler, kimsenin kaydetmediği console değişiklikleri, tek kişiye bağımlı deployment'lar — DevOps çözümleri ekibimiz, Terraform'u, policy as code'u ve GitOps'u rayına oturtmanıza yardımcı olur.

Bir taşınma mı planlıyorsunuz? AWS migrasyon hizmetlerimiz sizi 8–16 haftada Well-Architected bir temele taşır — sabit fiyat, aşamalı geçiş, yazılı rollback planı.