Altyapı Kodlaması (IaC) ile Ortam Farklarını Azaltmak: Başlamadan Önce Netleştirilecek 4 Soru

Test ortamında sorunsuz çalışan bir sürüm canlıya çıkınca hata veriyor. Kod aynı, ancak altyapı aynı değil: farklı bir veritabanı sürümü, daha düşük bir bellek sınırı, kapalı kalmış bir ağ kuralı. Altyapı kodlaması (IaC), sunucu, ağ ve servis ayarlarını elle yapılan işlemler yerine sürümlenen dosyalarla tanımlar. Böylece ortamlar arasındaki farklar görünür ve izlenebilir hâle gelir. Bu yazıda araç seçiminden önce yanıtlanması gereken dört soruyu ve test ile canlı arasındaki farkın bir plan çıktısında nasıl okunduğunu anlatıyoruz.

Ortam farkı önemlidir, çünkü canlıda çıkan bir sorunda ilk saat çoğu zaman koda değil, iki ortamı elle karşılaştırmaya gider. Ayarlar kişilerin hafızasında ya da konsol geçmişinde duruyorsa bu karşılaştırma tahmine dönüşür. IaC ile aynı karşılaştırma, depodaki iki dosya arasındaki bir farktan ibaret olur.

01Soru 1: Hangi ortam farkları bilinçli, hangileri tesadüfî?

Test ve canlı ortamın birebir aynı olması gerekmez. Test ortamı daha küçük ve daha ucuz olabilir. Önemli olan, farkın yazılı ve gerekçeli olmasıdır. Başlamadan önce kısa bir fark sözlüğü hazırlayın ve farkları dört gruba ayırın:

• Boyut farkları: Sunucu sayısı, işlemci, disk. Genellikle bilinçlidir ve değişkenle yönetilir.
• Sürüm farkları: Veritabanı, işletim sistemi, Kubernetes ya da çalışma zamanı sürümü. Çoğu zaman tesadüfîdir ve kapatılmalıdır.
• Ağ ve erişim kuralları: Canlıda daha sıkı olabilir. Her fark için yazılı bir gerekçe bulunmalıdır.
• Veri: Canlı ortamdaki kişisel veri, KVKK kapsamında test ortamına olduğu gibi kopyalanmamalıdır. Maskeleme ya da yapay veri tercih edilir.

Her fark için tek satırlık bir kayıt yeterlidir: ne farklı, neden farklı, kim onayladı. Gerekçesi yazılamayan fark büyük olasılıkla tesadüfîdir.

02Soru 2: Altyapının tek doğruluk kaynağı nerede duracak?

İkinci soru, "gerçek durum nerede yazılı?" sorusudur. Yanıt bir kişinin bilgisi ya da bulut konsolu olmamalı, bir sürüm kontrol deposu olmalıdır. Tipik bir düzen şöyledir:

1. Bulut kaynakları (ağ, veritabanı, depolama) Terraform ile tanımlanır.
2. Sunucu yapılandırması Ansible ile yazılır.
3. Konteyner ve orkestrasyon ayarları Docker ve Kubernetes tanım dosyalarında tutulur.
4. Ortak mantık tek modülde durur; test ve canlıya özgü değerler ayrı değişken dosyalarında yer alır.

Bu düzenin kritik noktası şudur: test ve canlı farklı kod değil, aynı kod ve farklı değişken kullanır. Fark sadece değişken dosyasında aranır. Ayrıca durum (state) dosyası uzak bir yerde, kilitli ve erişimi kısıtlı tutulmalıdır. Konsoldan elle değişiklik yasak olmalı ya da en azından istisna olarak kayda geçmelidir.

03Soru 3: Değişiklik hangi akıştan geçecek?

Kod depoda olsa bile değişiklikler herkesin bilgisayarından uygulanıyorsa fark yine görünmez kalır. Üçüncü soru, değişikliğin kim tarafından, hangi sırayla ve hangi onayla uygulanacağıdır. GitHub Actions gibi bir CI/CD aracıyla basit bir akış kurulabilir:

1. Değişiklik bir çekme isteğiyle (pull request) açılır.
2. Hat otomatik olarak bir plan çıktısı üretir ve isteğe ekler; neyin ekleneceği, değişeceği ve silineceği inceleyenin önüne gelir.
3. Gözden geçirme sonrasında değişiklik önce test ortamına uygulanır.
4. Canlıya uygulama ayrı bir onay adımı ister.

Böylece her değişikliğin bir sahibi, bir gerekçesi ve bir kaydı olur. Aynı değişikliğin önce test ortamında denenmesi de iki ortamın birbirinden uzaklaşmasını engeller.

04Soru 4: Sapmayı kim, nasıl izleyecek?

Kurulumdan sonra bile biri acil bir durumda canlıda elle ayar değiştirebilir. Bu sapma (drift) kaçınılmazdır; sorun, fark edilmemesidir. Dördüncü soru, bunu kimin ve hangi sıklıkla kontrol edeceğidir:

• Plan komutunu zamanlanmış olarak (örneğin günlük ya da haftalık) çalıştırın. Beklenmeyen bir fark çıkarsa sorumluya bildirim gitsin.
• Acil müdahale gerekiyorsa elle değişikliği yapın, ancak aynı gün koda yansıtın ya da geri alın.
• Parola, anahtar ve erişim bilgilerini koda yazmayın; ayrı bir sır yönetimi aracında tutun ve rotasyon sorumlusunu belirleyin.
• Bu kontrolün sahibini ve sonuçların nereye yazılacağını önceden belirleyin.

İzleme panoları uygulama sağlığını gösterir; plan çıktısı ise altyapının tanımlı durumdan ne kadar uzaklaştığını gösterir. İkisi birbirini tamamlar.

05Altyapı kodlaması (IaC) ile fark nasıl görünür hâle gelir: varsayımsal bir örnek

Aşağıdaki senaryo anlatım amacıyla kurgulanmıştır; belirli bir müşteriye ya da projeye ait değildir, değerler örnek niteliğindedir. Bir sipariş uygulaması test ortamında sorunsuz çalışıyor, canlıda ise ödeme sağlayıcısına yapılan çağrılar zaman zaman zaman aşımına uğruyor.

IaC öncesinde ekip iki ortamı konsollardan tek tek açıp karşılaştırır. Bu iş saatler sürebilir ve bir ayarın gözden kaçma ihtimali yüksektir. Altyapı koda alındıktan sonra aynı karşılaştırma, canlı ortam için üretilen plan çıktısında şu şekilde okunur:

Veritabanı sürümü: test 14, canlı 13 (fark).
Uygulama konteyneri bellek sınırı: test 1 GB, canlı 512 MB (fark).
Dışa doğru 443 numaralı bağlantı kuralı: test açık, canlı tanımsız (fark).

Üç fark da artık somut bir satırdır. Ekip her biri için karar verir:

• Veritabanı sürümü tesadüfîdir; canlı sürümü planlı bir bakım penceresinde yükseltilir.
• Bellek sınırı bilinçli bir boyut farkıdır, ancak canlıdaki iş yükü için yetersizdir; değişken dosyasında güncellenir.
• Dışa doğru bağlantı kuralı unutulmuştur; koda eklenir ve çekme isteğiyle onaylanır.

Önemli olan sonuçtur: farklar ortaya çıktıktan sonra ya koda alınır ya da fark sözlüğüne gerekçeyle yazılır. Bir sonraki sürümde aynı satırlar plan çıktısında tekrar çıkmaz.

06Sık sorulan sorular

IaC için Kubernetes kullanmak şart mı?

Hayır. IaC bir yöntemdir, belirli bir platforma bağlı değildir. Sanal makinelerden oluşan bir altyapı da Terraform ve Ansible ile kodlanabilir. Kubernetes kullanıyorsanız küme ve uygulama tanımları da aynı depoya eklenebilir.

Elle kurulmuş mevcut ortamı koda nasıl alırız?

Tek seferde değil, küçük parçalarla ilerlemek daha güvenlidir. Önce mevcut kaynakların envanterini çıkarın, ardından önce test ortamında bir bileşeni (örneğin ağ ya da tek bir veritabanı) koda alın. Plan çıktısı "değişiklik yok" diyene kadar tanımı düzeltin. Canlı ortama bu doğrulamadan sonra geçin.

Test ve canlı ortamın maliyeti aynı olmalı mı?

Hayır. Aynı kod, farklı boyut değişkenleriyle çalıştırılabilir. Test ortamı küçük tutulur; sürüm, ağ yapısı ve yapılandırma mantığı ise canlıyla aynı kalır. Maliyet farkı bilinçli bir fark olarak sözlükte yer alır.

07Sonuç: önce sorular, sonra araç

IaC'nin değeri araçların kendisinden çok, ortam farklarını yazılı, incelenebilir ve izlenebilir hâle getirmesinden gelir. Başlamadan önce dört soruyu yanıtlayın: hangi farklar bilinçli, doğruluk kaynağı nerede, değişiklik hangi akıştan geçecek, sapmayı kim izleyecek. Bu yanıtlar netleştiğinde Terraform ya da Ansible seçimi çok daha kolay hâle gelir. OPEIS Teknoloji olarak CI/CD hattı kurulumu, Terraform ve Ansible ile altyapı kodlaması ve Docker/Kubernetes orkestrasyonu konularındaki çalışma kapsamımızı DevOps & Altyapı Yönetimi sayfasında inceleyebilirsiniz.