Kod olarak altyapı (IaC) nedir ve elle kurulan sunucular neden ölçeklenmez?

Her altyapı kurulumu aynı şekilde başlar: Biri bir bulut konsoluna giriş yapar, birkaç formu tıklayarak doldurur ve bir sunucu oluşturur. İşe yarar. Altı ay sonra bu sunucunun yeniden kurulması gerekir (bir arızanın ardından ya da birebir aynı bir staging ortamı oluşturmak için) ve ilk seferde tıklanan her ayarı kimse tam olarak hatırlamaz. Kod olarak altyapı (Infrastructure as Code), bu senaryoyu imkânsız kılmak için vardır.

Temel fikir

Genellikle IaC olarak kısaltılan kod olarak altyapı; sunucularınızın, ağlarınızın, veritabanlarınızın ve diğer bulut kaynaklarınızın bir web konsolundan elle yapılandırılmak yerine, tıpkı uygulama kodu gibi sürüm kontrolüne eklenen yapılandırma dosyalarında tanımlanması demektir. “Sunucu oluştur” butonuna tıklayıp açılır menülerden ayar seçmek yerine, tam olarak neyin var olması gerektiğini tarif eden bir dosya yazarsınız; bir araç da bu dosyayı okuyup gerçek altyapıyı ona uygun hâle getirir.

Bu iş için en yaygın kullanılan araç, tüm büyük bulut sağlayıcılarında aynı temel yaklaşımla çalışan Terraform'dur; her büyük bulutun kendi yerel seçeneği de vardır (AWS CloudFormation, Azure Resource Manager şablonları). Araç ne olursa olsun temel fikir aynıdır: Gerçeğin kaynağı, konsolda o an mevcut olan durum değil, dosyanın kendisidir.

Bu neden sanıldığından daha büyük bir mesele?

• Tekrarlanabilirlik. Birebir aynı bir staging ortamına mı ihtiyacınız var ya da bir felaketin ardından canlı ortamı yeniden mi kurmanız gerekiyor? Aynı yapılandırmayı yeniden çalıştırın. Bu, her ayarı hatırladığınızı ummak değil; tanımı gereği garanti altındadır.
• Altyapı değişiklikleri için kod incelemesi. Bir güvenlik duvarı kuralındaki ya da veritabanı boyutundaki değişiklik, kimsenin görmediği bir konsol tıklaması olmaktan çıkar ve tıpkı uygulama kodundaki bir değişiklik gibi, uygulanmadan önce bir ekip arkadaşının incelediği bir pull request'e dönüşür.
• Gerçek bir denetim izi. Sürüm kontrolü neyin, ne zaman ve kim tarafından değiştirildiğini tam olarak gösterir. “Bu security group neden tüm internete açık?” sorusu bir arkeoloji kazısı değil, bir git blame işlemi olur.
• Sapma (drift) tespiti. IaC araçları yapılandırma dosyasını gerçekte çalışan sistemle karşılaştırıp farkları işaretleyebilir. Böylece birinin doğrudan konsolda yaptığı ve dosyalara hiç geri yansıtılmamış manuel “hızlı düzeltme” yakalanır; aksi hâlde bu düzeltme sessizce ezilir ya da, daha kötüsü, sessiz sedasız daha da sapar.

Ekipler genellikle nereden başlar?

Kimse ilk günden tüm altyapısını Terraform'la yazmaz ve bunda bir sakınca yok. Yaygın ve mantıklı bir yol, kaybedilmesi acı verici ya da elle yeniden kurulması yavaş olan parçalarla (ağ yapılandırması, veritabanı, temel işlem kaynakları) başlamak ve yeni sıkıntılar ortaya çıktıkça kapsamı zamanla genişletmektir. Amaç, konsolun hiç elle kullanılmaması değildir; kaybetmeyi gerçekten göze alamayacağınız ya da güvenilir biçimde yeniden üretmeniz gereken kaynakların, yalnızca birinin neye tıkladığına dair hafızasında yaşamak yerine bir dosyada tanımlı olmasıdır.

Dikkat edilmesi gereken tuzak

IaC'ye geçişin en sık başarısız olma nedeni araçlar değil, sessizce çürüyen yarım bir geçiştir. Bir ekip ilk kurulum için Terraform yazar, ardından bir olay sırasında acil düzeltmeleri doğrudan konsolda yapar (bu, çoğu zaman o an için doğru karardır) ve bu değişiklikleri dosyalara yansıtmak için asla geri dönmez. Altı ay sonra dosyalar artık gerçeklikle örtüşmeyen bir altyapıyı tarif eder ve kimse onlara tam olarak güvenmez; bu da IaC'nin çözmesi gereken sorunun ta kendisidir. Bunu kalıcı kılan şey, “dosyalar gerçekliği tarif eder” ilkesini bir hedef olarak değil, her zaman geçerli bir kural olarak benimsemektir.

Altyapıyı en baştan bu şekilde kurmak, Burncode'da yürüttüğümüz bulut ve DevOps çalışmalarında standart bir uygulamadır. Bir ortamı yeniden kurmayı, ölçeklendirmeyi ya da başka bir mühendise devretmeyi bir tahmin oyunu olmaktan çıkarıp sıradan ve sorunsuz bir işe dönüştüren de budur.