Bir sysadmin ekibi her yeni ortam için aynı adımları tekrar ediyor: konsoldan sunucu açıyor, ağ ayarlarını giriyor, güvenlik gruplarını elle yapılandırıyor. İki hafta sonra staging ile production arasında neden farklı davrandığını kimse bilmiyor. Infrastructure as Code bu “kimin nereye ne dokunduğu belli olmaz” kaosunu ortadan kaldırır. Ve Terraform bu yaklaşımın en yaygın kullanılan aracı haline gelmiştir.
Terraform Neden Öne Çıkıyor
AWS CloudFormation, Azure ARM Templates veya Google Deployment Manager kendi bulut sağlayıcılarına sıkı sıkıya bağlıdır. Terraform ise provider agnostiktir: aynı araçla AWS EC2 instance’ı, Cloudflare DNS kaydı ve GitHub repository ayarını tek bir kod tabanında yönetebilirsiniz. Bu çoklu-sağlayıcı desteği, şirketlerin gerçek altyapılarını tek bir yerden tanımlamasına olanak tanır. HashiCorp’un 2023’te BSL lisansına geçmesinin ardından topluluk OpenTofu’yu çatalladı; iki araç büyük ölçüde uyumlu çalışır ve kod tabanları arasında geçiş yapmak genellikle sorunsuz olur.
State Dosyası: Terraform’un Hafızası
Terraform her çalıştırmada neyin mevcut olduğunu bir state dosyasında saklar. Bu dosya olmadan Terraform hangi kaynakları yönettiğini bilemez ve her apply’da yeni kaynaklar oluşturur. State’in yerel diskte tutulması ekip çalışmasını imkânsız kılar; iki kişinin aynı anda apply çalıştırması state’i bozar. Çözüm remote state kullanmaktır: S3 bucket + DynamoDB tablosu (AWS için) state dosyasını bulutta şifreli tutar ve DynamoDB kilitleme mekanizmasıyla eşzamanlı değişikliği engeller. Terraform Cloud ücretsiz planı da küçük ekipler için yeterli bir alternatiftir.
Plan → Apply Döngüsü ve Neden Önemli
terraform plan çalıştırıldığında Terraform, mevcut state ile hedef konfigürasyonu karşılaştırır ve ne yapacağını listeler: “3 kaynak oluşturulacak, 1 değiştirilecek, 0 silinecek” gibi. Bu çıktı bir pull request incelemesi gibi ele alınabilir ve bir ekip üyesi tarafından onaylanabilir. terraform apply ancak plan onaylandıktan sonra çalıştırılır. Otomatik onay seçeneği (-auto-approve) CI/CD’de dikkatli kullanılmalı, production ortamında kesinlikle tercih edilmemelidir. Hatalı bir apply geri alınamayabilir; plan adımı bu riski minimize eder.
Modül Yapısıyla Tekrarı Ortadan Kaldırmak
Her ortam için (dev, staging, prod) ayrı Terraform dosyaları yazmak anti-pattern’dir. Aynı değişiklik üç yerde yapılmak zorunda kalınır ve biri atlanır. Bunun yerine modüller kullanılır: bir “web_cluster” modülü instance tipi, minimum-maksimum kapasitesi ve hedef grup ayarlarını parametre olarak alır. Farklı ortamlar bu modülü farklı değerlerle çağırır. Modülde bir güvenlik yaması uygulandığında tek bir değişiklik tüm ortamlara yansır. Terraform Registry’deki resmi modüller (örneğin terraform-aws-modules/vpc/aws) üretim kalitesinde başlangıç noktası sunar.
Terraform ile Drift Tespiti
Ekipten biri konsola girip bir güvenlik grubu kuralını elle değiştirdi. Kod ile gerçek altyapı arasındaki bu farka “drift” denir ve elle yapılan her değişiklik bir sonraki apply’da silinir ya da üzerine yazılır. terraform plan çalıştırıldığında Terraform mevcut durumu sorgular ve bu farkı raporlar: “aws_security_group_rule.allow_https silinecek.” CI/CD pipeline’da her gece otomatik plan çalıştırıp çıktıyı Slack kanalına göndermek, drift’i üretim sorununa dönüşmeden yakalar.
Gizli Bilgiler Terraform Kodunda Olmaz
Terraform konfigürasyonuna veritabanı şifresi veya API anahtarı yazmak ciddi bir hatadır; bu değerler state dosyasında plain-text olarak saklanır ve git geçmişine sızar. Doğru yöntemler:
- AWS Secrets Manager veya HashiCorp Vault’tan runtime’da değer çekilir; Terraform provider’lar bu servisleri destekler.
- Gizli değişkenler
sensitive = trueile işaretlenir; plan çıktısında ve logda görünmez. - State dosyası S3’te SSE-KMS ile şifreli tutulur; bucket versiyonlama ve erişim loglaması aktif olmalıdır.
.terraform.lock.hclgit’e dahil edilir (provider versiyonlarını kilitler), ancak.tfstateve.tfvarsdosyaları.gitignore‘a eklenir.
Test Edilemeyen Altyapı Güvenilmez Altyapıdır
Terraform konfigürasyonları da test edilmelidir. terraform validate sözdizimi doğrular; terraform fmt biçimlendirmeyi otomatik düzeltir. Daha kapsamlı testler için Terratest (Go tabanlı) Terraform’u gerçek bulut ortamında çalıştırır, kaynakların doğru oluşturulduğunu API çağrılarıyla doğrular ve ardından temizler. Minimal bir test bile olmadan büyük altyapı değişiklikleri production’a uygulanan bir sürpriz haline gelir. CI pipeline’da en azından validate ve plan adımları her pull request’te otomatik çalışmalıdır.
İlk Terraform Projesi: Döngüyü Tamamlamak
Öğrenmek için en hızlı yol küçük ve gerçek bir şeyle başlamaktır. AWS’de aws_instance ve aws_security_group kaynaklarını tanımlayın, terraform init ile provider’ı indirin, plan çıktısını dikkatlice okuyun, apply ile deploy edin, ardından terraform destroy ile silin. Bu döngüyü tamamladıktan sonra remote state ve modül yapısına geçin. Çoğu ekip bu temeli atlamadan doğrudan karmaşık modüller veya CI entegrasyonu yazmaya çalışır; o yüzden ilk projeleri kaosa dönüşür. Başlangıç için AWS free tier yeterlidir; toplam maliyet birkaç sent seviyesinde kalır.