Altyapıyı Kod Olarak Yönetmek: Elle Kurulan Sunucunun Sonu

Altyapıyı kod olarak yönetmek (Infrastructure as Code, IaC), sunucuları, ağ ayarlarını ve servis yapılandırmalarını elle değil, sürüm kontrolünde duran dosyalarla tanımlamaktır. Kulağa ek iş gibi gelir; gerçekte çözdüğü problem son derece somuttur: bir sunucu çöktüğünde onu aynı şekilde geri kurabilmek.

Elle yönetilen sunucunun üç sessiz maliyeti

Kar tanesi sunucular. Zamanla her sunucu benzersizleşir: biri elle kurulmuş bir eklenti, diğerinde farklı bir zaman aşımı değeri, üçüncüsünde kimsenin hatırlamadığı bir cron kaydı. Test ortamında çalışan kodun üretimde patlamasının en yaygın sebebi budur.

Kayıt yokluğu. Elle yapılan değişikliğin tarihi, sebebi ve sahibi yoktur. Altı ay sonra "bu ayar neden böyle?" sorusunun cevabı, en iyi ihtimalle birinin hafızasındadır. Bu, commit mesajlarının kod için çözdüğü sorunun altyapıdaki karşılığıdır.

Tek kişiye bağımlılık. Kurulumu yalnızca bir kişi biliyorsa, o kişinin izne çıkması bir risk kalemidir.

İki farklı iş: sağlama ve yapılandırma

Alan sıkça karıştırılır. Bir tarafta sağlama vardır: sunucu, ağ, veritabanı örneği gibi kaynakların oluşturulması. Diğer tarafta yapılandırma yönetimi: var olan bir makinenin üzerinde paket kurulumu, dosya yerleştirme, servis ayarı.

Bulut ortamında sağlama için bildirimsel araçlar (istenen son durumu tarif edersiniz, araç farkı uygular), yapılandırma için ise adım tabanlı araçlar yaygındır. Konteyner kullanan ekiplerde ikinci başlığın önemli bir kısmı imaj tanımına taşınır ve yapılandırma yönetimi ihtiyacı azalır.

Kritik kavram: idempotency

IaC araçlarının temel vaadi, aynı tanımı iki kez uygulamanın tek kez uygulamakla aynı sonucu vermesidir. Bu özellik olmadan otomasyon güvenilir olmaz — yarıda kalan bir çalıştırmayı baştan başlatabilmek, olay anında en çok ihtiyaç duyulan şeydir.

Pratikte bu ilkeyi bozan en yaygın kalıp, tanım dosyasının içine gömülen "şunu bir kere çalıştır" tipi kabuk komutlarıdır. Bu komutlar her uygulamada yeniden çalışır ve beklenmedik sonuçlar üretir. Kaçınılmazsa, komut kendi kontrolünü kendi yapmalıdır: "zaten yapılmışsa hiçbir şey yapma".

Durum dosyası ve sürüklenme

Bildirimsel araçlar, gerçek dünyada ne olduğunu bir durum dosyasında tutar. Bu dosya iki ciddi konu getirir.

Birincisi güvenliktir: durum dosyası çoğu zaman parola ve bağlantı dizesi gibi hassas değerler içerir; asla depoya işlenmemeli, şifreli bir uzak konumda tutulmalıdır. Sırların doğru yönetimi ayrı bir başlıktır ve sır yönetimi yazımızda ele aldığımız kurallar burada da geçerlidir.

İkincisi sürüklenmedir (drift): biri panelden elle bir ayar değiştirdiğinde gerçek durum ile tanım ayrışır. Bir sonraki uygulama bu değişikliği sessizce geri alabilir — ya da daha kötüsü, elle yapılan kritik bir düzeltmeyi siler. Çözüm teknik değil kültüreldir: üretimde elle değişiklik yapılmaz, acil durumda yapıldıysa aynı gün tanıma yansıtılır.

Küçük ekipler için kademeli geçiş

Var olan altyapının tamamını bir hafta sonunda koda dökmeye çalışmak, çoğu zaman yarım kalır. İşleyen sıra şudur:

1. Yeni her şeyi kodla kurun. Mevcut sunuculara dokunmayın; bundan sonra oluşturulan her kaynak tanımdan doğsun.
2. Kurulumu belgelemekten koda geçin. Elinizdeki kurulum adımları belgesini betiğe çevirin — belge zaten bir tanımın kötü hâlidir.
3. Önce en kritik parçayı taşıyın. Çöktüğünde işi durduran bileşen hangisiyse, sıfırdan kurulabilir hâle ilk o gelmelidir.
4. Sunucusuz bileşenleri de kapsama alın. İşlev, kuyruk ve tetikleyici tanımları da koddan doğmalıdır; bu modelin sınırları için sunucusuz mimari yazımıza bakın.
5. Yılda bir tatbikat yapın. Tanımdan sıfır bir ortam ayağa kaldırın. Bu tatbikat, denenmemiş yedeklerin yarattığı sahte güvenliğin altyapı tarafındaki panzehiridir.

Nerede işe yaramaz?

Dürüst olmak gerekirse her bağlamda gerekmez. Tek bir küçük sunucuda çalışan ve nadiren değişen bir sistem için tam kapsamlı bir IaC kurulumu, çözdüğünden fazla karmaşıklık getirebilir. Bu durumda bile minimum standart geçerlidir: kurulum adımları depoda yazılı bir betik olarak dursun. Otomasyon kararının genel çerçevesi için ne zaman script yazmalı yazımızdaki hesap burada da uygulanabilir.

Dağıtım hattıyla ilişkisi

Altyapı tanımları da kod olduğuna göre aynı disiplinden geçmelidir: kod incelemesi, otomatik doğrulama ve dağıtım hattı üzerinden uygulama. Değişikliğin önce ne yapacağını gösteren bir "plan" adımı olmadan üretime uygulanması, en pahalı hataların kaynağıdır. Hattı kurarken CI/CD yazımız temel yapıyı, geri alma planı yazımız ise kritik güvenceyi anlatıyor. Konteyner tarafındaki pratikler için Docker resmi dokümantasyonu başvurulabilir.

Sonuç

Altyapıyı kod olarak yönetmenin asıl kazancı hız değil, tekrarlanabilirlik ve denetlenebilirliktir: sunucu sıfırdan kurulabilir, her değişikliğin sahibi ve gerekçesi bellidir, bilgi tek kişinin hafızasından çıkar. Geçiş için tüm altyapıyı bir anda taşımak gerekmez — bundan sonra oluşturulan her kaynağı tanımdan doğurmak bile bir yıl içinde tabloyu değiştirir. Bu hafta yapabileceğiniz en somut adım şudur: en kritik sunucunuzu sıfırdan kurmanın adımlarını yazın. Yazamıyorsanız, gerçek riskinizin boyutunu da öğrenmiş olursunuz.