Altyapı yönetimi uzun yıllar boyunca paneller, SSH oturumları ve tek tek yapılan sunucu ayarlarıyla yürütüldü. İlk kurulumlar çoğu zaman hızlı görünür; asıl sorun ise 2 ay sonra ortaya çıkar. Test ortamı üretimle birebir aynı olmaz, yeni sunucu açılırken bir ayar atlanır, hangi değişikliğin ne zaman yapıldığı da net biçimde izlenemez. İşte tam bu noktada infrastructure as code yaklaşımı devreye girer.

Infrastructure as Code, sunucu ve bulut altyapısının elle değil, kod dosyalarıyla tanımlanması yöntemidir. Sanal makine, ağ, güvenlik grubu, veritabanı, yük dengeleyici, container cluster ya da DNS kaydı gibi bileşenler metin tabanlı tanımlar üzerinden oluşturulur. Aynı tanım dosyası yalnızca 1 kez değil, 10 kez çalıştırılsa da beklenen durum korunur. Bu yaklaşım ekiplere sadece hız kazandırmaz; aynı zamanda standartlaşma, denetlenebilirlik ve geri alınabilir değişiklik yönetimi de sunar.

Kurumsal projelerde bunun etkisi oldukça somuttur. Örneğin 6 sunuculuk bir test ortamını manuel kurulumla hazırlamak saatler sürebilir. IaC ile aynı ortam, önceden tanımlanmış dosyalar kullanılarak dakikalar içinde yeniden üretilebilir. Üstelik mesele yalnızca süre değildir. Asıl kritik nokta, her seferinde aynı sonucun elde edilmesidir.

Infrastructure as Code tam olarak neyi kapsar?

IaC yalnızca “sunucu açma” işi değildir. Çoğu projede kapsam, ilk bakışta düşünüldüğünden daha geniştir. Bir bulut hesabındaki VPC ağı, alt ağlar, route table kayıtları, güvenlik kuralları, Kubernetes cluster tanımları, object storage bucket’ları ve monitoring alarmları bu yaklaşımın parçası olabilir.

Basit bir örnek verelim. AWS üzerinde çalışan bir uygulamada şu bileşenler kodla tanımlanabilir:

  • 2 adet application server
  • 1 yönetilen PostgreSQL veritabanı
  • 443 portu için yük dengeleyici
  • Özel ağ segmentleri ve güvenlik grupları
  • Log toplama ve alarm kuralları

Bu tanımlar Git deposunda sürüm kontrollü şekilde tutulur. Kim, hangi satırı, hangi tarihte değiştirdi sorusunun yanıtı artık commit geçmişindedir. Üretim ortamında 14 Mart tarihli bir değişiklikten sonra sorun başladıysa, yalnızca uygulama koduna değil, altyapı tanımına da dönüp bakılabilir.

Konfigürasyon yönetiminden farkı nedir?

Burada sık karşılaşılan bir karışıklık vardır. Konfigürasyon yönetimi araçları çoğu zaman mevcut makinelerin iç ayarlarını yönetir. Örneğin bir Linux sunucusuna Nginx kurulması, bir servis dosyasının düzenlenmesi ya da belirli bir paketin 1.24 sürümünde tutulması bu kapsama girer. IaC ise daha üst seviyede çalışır ve kaynağın kendisini de oluşturabilir. Kısacası biri “makinenin içi”ne, diğeri ise “makine ve çevresi”ne odaklanır. Modern yapılarda bu iki yaklaşım birlikte kullanılır.

IaC neden standartlaştırma sağlar?

Manuel işlemlerde bilgi çoğu zaman kişiye bağlıdır. Bir sistem yöneticisi güvenlik grubunda neden 8080 portunu açtığını biliyor olabilir; ekip değiştiğinde ise bu bilgi kaybolur. Kod tabanlı altyapı, bu kararları görünür hale getirir. Dosya içindeki açıklamalar, değişiklik geçmişi ve code review süreci standardı kişiden bağımsızlaştırır.

Özellikle birden fazla ortam yöneten ekiplerde fark daha belirgindir. Geliştirme, test, staging ve üretim gibi 4 ayrı ortam düşünün. Elle kurulum yapıldığında bu ortamlar zaman içinde birbirinden uzaklaşır. IaC ile aynı modül, farklı değişkenlerle tekrar kullanılabilir. Örneğin test ortamında 2 CPU ve 4 GB RAM tanımlanırken, üretimde 8 CPU ve 16 GB RAM kullanılabilir; yapısal kurgu ise aynı kalır.

Standartlaşmanın güvenlik tarafında da önemli bir etkisi vardır. Yanlışlıkla herkese açık bir veritabanı açılması gibi hatalar genellikle aceleyle yapılan manuel işlemlerde ortaya çıkar. Kod incelemesi, otomatik politika kontrolleri ve ön izleme çıktıları bu riski azaltır. Özellikle finans, sağlık, lojistik veya B2B SaaS projelerinde bu disiplin ciddi avantaj sağlar.

Infrastructure as Code nasıl çalışır?

Temel işleyiş oldukça basittir: İstenen altyapı durumu dosyalarla tanımlanır, araç bu tanımı mevcut durumla karşılaştırır ve aradaki farkı uygular. Bu uygulama sırasında yeni kaynaklar oluşturabilir, mevcut kaynakları güncelleyebilir ya da artık gerekmeyen kaynakları kaldırabilir.

Örnek bir Terraform tanımı şu kadar kısa olabilir:

resource "aws_s3_bucket" "logs" {
  bucket = "proje-log-arsivi"
}

Gerçek projeler elbette çok daha kapsamlıdır. Ancak mantık değişmez: Altyapı, okunabilir ve tekrar çalıştırılabilir metin dosyalarıyla yönetilir. Çoğu ekipte süreç şu akışla ilerler:

  1. Geliştirici veya DevOps mühendisi değişikliği kod olarak yazar
  2. Pull request açılır ve teknik inceleme yapılır
  3. Plan çıktısı alınır; hangi kaynakların değişeceği görülür
  4. Onay sonrasında değişiklik test ya da üretim ortamına uygulanır

Bu modelde “önce panelden değiştir, sonra not düşeriz” yaklaşımı yerini kontrollü değişiklik yönetimine bırakır. Etkisi küçük ekiplerde bile hissedilir. 3 kişilik bir ekipte bir altyapı kararı sözlü olarak paylaşılabilir; ancak 15 kişilik bir yapıda bu yöntem sürdürülebilir değildir.

Yaygın IaC araçları ve kullanım senaryoları

Piyasada farklı ihtiyaçlara yanıt veren çeşitli araçlar bulunur. En bilinen seçeneklerden biri Terraform’dur. Birden fazla bulut sağlayıcısıyla çalışabilmesi ve modüler yapısı nedeniyle sıkça tercih edilir. AWS CloudFormation ise doğrudan AWS ekosisteminde kalmak isteyen ekipler için doğal bir seçenektir. Kubernetes tarafında Helm ve Kustomize, uygulama bileşenlerinin kümeye dağıtımında önemli rol oynar.

Burada araç seçimi kadar tasarım kararı da önem taşır. Örneğin tek bölgede çalışan, 8 mikro servisten oluşan bir SaaS platformunda ağ, veritabanı, cache, worker node’ları ve gözlemlenebilirlik bileşenleri ayrı modüller halinde kurgulanabilir. Bu yapı bakım sırasında avantaj sağlar. Bir veritabanı değişikliği ile ağ katmanı değişikliği aynı dosya bloklarında birbirine karışmaz.

Mutable ve immutable yaklaşım

IaC konuşulurken mutable ve immutable kavramları da sıkça gündeme gelir. Mutable modelde mevcut sunucu üzerinde değişiklik yapılır. Immutable modelde ise sunucu yerinde yamalanmak yerine yeni imajla yeniden oluşturulur. Özellikle container tabanlı platformlarda immutable yaklaşım daha güvenli ve öngörülebilir kabul edilir. Her proje için tek bir doğru yoktur; ancak kritik ortamlarda yeniden üretilebilirlik seviyesi ne kadar yüksekse operasyon riski de o kadar azalır.

İşletmeler için somut faydalar

IaC’nin değeri yalnızca teknik ekiple sınırlı değildir. Operasyon maliyeti, teslim süresi ve denetim hazırlığı gibi alanlarda da doğrudan sonuç üretir. Bir e-ticaret şirketi kampanya öncesinde ek kapasiteye ihtiyaç duyduğunda, yeni sunucu açma ve ağ kurallarını elle hazırlama süreci ciddi bir darboğaz yaratabilir. Kodlanmış altyapı sayesinde aynı işlem daha öngörülebilir hale gelir.

  • Daha hızlı ortam kurulumu: Yeni test ortamı 1 iş günü yerine 20-30 dakika içinde hazırlanabilir.
  • Daha az yapılandırma farkı: “Bende çalışıyor” sorununun bir kısmı ortam uyumsuzluğundan kaynaklanır.
  • Denetlenebilir değişiklik geçmişi: Regülasyon ve iç denetim süreçlerinde ciddi kolaylık sağlar.
  • Felaket kurtarma hazırlığı: Başka bir bölgede aynı altyapıyı yeniden ayağa kaldırmak kolaylaşır.

Burada bir noktayı abartmamak gerekir. IaC tek başına kusursuz bir sistem kurmaz. Kötü tasarlanmış bir ağ topolojisi kodla tanımlandığında yine kötü bir tasarım olarak kalır. Fark şudur: Hata görünür, tekrar üretilebilir ve düzeltilebilir hale gelir.

Geçiş sürecinde karşılaşılan zorluklar

IaC’ye geçiş her zaman sorunsuz ilerlemez. İlk direnç genellikle alışkanlıklardan kaynaklanır. Yıllardır panel üzerinden işlem yapan ekipler için her değişikliği repository üzerinden geçirmek ilk etapta yavaşlatıcı görünebilir. İlk 2-3 sprintte gerçekten ek yük hissedilebilir. Zamanla süreç oturur.

Bir diğer zorluk da mevcut altyapının dağınık olmasıdır. Özellikle 5 yıldır büyüyen sistemlerde hangi kaynağın neden açıldığını bulmak bile zaman alabilir. Böyle durumlarda “big bang” dönüşüm yerine kademeli geçiş daha sağlıklıdır. Önce yeni kurulan ortamlar IaC ile yönetilir. Ardından kritik bileşenler modül modül taşınır.

State yönetimi de dikkat gerektirir. Terraform gibi araçlarda state dosyası, altyapının mevcut durumunu temsil eder. Bu dosyanın güvenli biçimde saklanması, kilitlenmesi ve ekip içinde kontrollü kullanılması gerekir. Aksi halde aynı kaynağa eşzamanlı müdahale riski doğar. Kurumsal projelerde uzaktaki state backend, erişim politikaları ve CI/CD entegrasyonu standart başlangıç gereklilikleri arasında yer alır.

IaC, CI/CD ve güvenlik birlikte nasıl ele alınmalı?

En sağlıklı yapı, IaC’nin yazılım teslim sürecine bağlanmasıdır. Örneğin main dala birleşen bir değişiklik önce plan üretir, ardından onay mekanizmasıyla staging ortamına uygulanır. Üretim için ise ek onay istenir. Böylece altyapı değişikliği de uygulama dağıtımı kadar disiplinli hale gelir.

Güvenlik tarafında secret yönetimi kritik bir başlıktır. Erişim anahtarlarını doğrudan kod dosyasına yazmak ciddi bir hatadır. Bunun yerine secret manager servisleri, kısa ömürlü kimlik bilgileri ve rol tabanlı erişim tercih edilmelidir. Ayrıca politika denetimi yapan araçlarla açık erişim, şifrelenmemiş storage veya geniş yetkili IAM rolleri gibi riskler apply öncesinde tespit edilebilir.

Pratik bir senaryo düşünelim: Bir B2B sipariş platformu için üretim ortamında yalnızca 443 portu dış dünyaya açık olmalıdır. IaC politikası, 0.0.0.0/0 kaynağından 22 portunu açan bir değişikliği pipeline aşamasında reddedebilir. Bu, manuel kontrole kıyasla daha tutarlı bir güvenlik katmanı sağlar.

Hangi projeler için önceliklidir?

Tek bir VPS üzerinde çalışan küçük bir tanıtım sitesi için kapsamlı bir IaC kurulumu şart olmayabilir. Buna karşılık birden fazla ortamı olan, düzenli sürüm çıkaran, ölçeklenme ihtiyacı bulunan projelerde bu yaklaşım erken aşamada düşünülmelidir. Özellikle şu tür yapılarda öncelik yüksektir:

  • SaaS ürünleri
  • Mikro servis mimarileri
  • ERP/CRM entegrasyonları içeren kurumsal platformlar
  • Çok müşterili B2B sistemler
  • Regülasyon veya denetim baskısı yüksek uygulamalar

2 geliştiriciyle başlayan bir ürün, 12 ay içinde 5 ortama ve onlarca bulut kaynağına ulaşabilir. Bu büyüme gerçekleşmeden önce altyapı disiplinini kurmak, sonradan dağınık yapıyı toparlamaktan daha ekonomiktir.

Son değerlendirme

Infrastructure as code, altyapıyı “kurulmuş sistem” olmaktan çıkarıp “tanımlanmış sistem” haline getirir. Ekipler açısından temel kazanım yalnızca hız değildir; tutarlılık, izlenebilirlik ve operasyonel güven de en az hız kadar değerlidir. Bulut maliyetlerini kontrol etmek, güvenlik standartlarını yaygınlaştırmak ve yeni ortamları güvenle çoğaltmak isteyen işletmeler için IaC artık ileri seviye bir tercih değil, güçlü bir temel yaklaşım olarak değerlendirilmelidir.

Doğru araç seçimi, modüler tasarım, sürüm kontrolü ve güvenlik politikaları birlikte ele alındığında IaC; özel yazılım projelerinde daha öngörülebilir teslimat ve daha yönetilebilir bir altyapı sağlar. Özellikle bulut tabanlı ürün geliştiren şirketler için bu yaklaşım, büyümeyi teknik borç üretmeden sürdürmenin en etkili yollarından biridir.