Herkes Terraform Kullanıyor: Peki Sürüklenmeyi Kim Yakalıyor?

Kısa cevap: Altyapıyı kodla tanımlamak artık ayırt edici bir yetkinlik değil, bir zemin. CNCF verilerine göre bulut kullanıcılarının %90'ı bir biçimde altyapıyı kod olarak (IaC) yönetiyor ve Terraform bu alanda %76 paya sahip. Sorun benimsemede değil işletmede: aynı kaynakta kurumların %64'ü yetkin bulut ve otomasyon personeli bulamadığını söylüyor, %45'i ise güvenlik ve uyum riskini IaC'nin başlıca zorluğu olarak sayıyor.

Bu yazı, Terraform'u kurduktan sonra başlayan asıl işi ele alıyor: kodun tarif ettiği altyapı ile gerçekte çalışan altyapı arasındaki farkı ölçmek.

Sürüklenme (drift) nedir ve neden sessizdir?

Sürüklenme, kodda yazan durum ile bulutta gerçekte var olan durumun ayrışmasıdır. Bir mühendis konsoldan bir güvenlik grubu kuralı eklediğinde, bir otomatik ölçekleme olayı bir etiketi değiştirdiğinde ya da bir sağlayıcı varsayılan bir ayarı güncellediğinde ortaya çıkar.

Sürüklenmeyi tehlikeli yapan şey büyüklüğü değil sessizliği. Hiçbir uyarı üretmez, hiçbir panoda görünmez ve genellikle iki anda ortaya çıkar: bir felaket kurtarma tatbikatında ya da bir denetimde. İkisinde de geç kalınmış olur.

Olgun bir uygulamada sürüklenme tespiti sürekli çalışır ve tespit edilen her sapma bir hata gibi ele alınır, bir istisna gibi değil.

Terraform ile Ansible aynı işi yapmıyor

İkisi sık sık alternatif sanılıyor; oysa boru hattının iki farklı ucundalar.

Terraform sağlama (provisioning) katmanıdır. Bildirimsel çalışır: hedef durumu tarif edersiniz, aradaki farkı o hesaplar. Güçlü olduğu yer kaynakların varlığı ve ilişkisidir; ağ, sanal makine, yönetilen hizmet, erişim politikası.

Ansible yapılandırma (configuration) katmanıdır. Prosedürel çalışır: sistem ayağa kalktıktan sonra üzerinde ne olacağını uygular; paket kurulumu, servis ayarı, security baseline.

İkisi arasındaki sınırı net çizmek, IaC projelerinde en çok geri dönüş sağlayan kararlardan biri. Sınır bulanıklaştığında aynı ayar iki yerde tanımlanır ve hangisinin kazandığı runtime'a kalır.

Değiştirilebilir altyapıdan değiştirilemez altyapıya

Sürüklenmeyi kaynağında kurutan yaklaşım, çalışan sunucuyu güncellemek yerine yenisini kurup eskisini kaldırmaktır. Bu, yamalama penceresini bir dağıtım işine dönüştürür ve "hangi sunucuda hangi sürüm var" sorusunu ortadan kaldırır.

Her iş yükü buna uygun değil. Durum tutan sistemler, eski uygulamalar ve lisansı donanıma bağlı yazılımlar hâlâ değiştirilebilir kalır. Önemli olan hangi sistemin hangi modelde olduğunun yazılı olması; karışık bir filoda bu kayıt yoksa yama yönetimi tahmine dönüşür.

Ölçülebilir dört kontrol

Bir IaC hattının sağlıklı olup olmadığı şu dörtle ölçülür:

Sürüklenme tespiti hangi sıklıkla çalışıyor? Cevap "dağıtımdan önce" ise sürüklenme dağıtım anında keşfediliyor demektir; bu, en pahalı andır.Son otuz günde kaç sapma bulundu ve kaçı koda geri yazıldı? Bulunup düzeltilmeyen sapma, bulunmamış sapmadan farksızdır.Konsoldan yapılan manuel değişiklik kayıt altında mı? Değilse kök neden analizi her olayda sıfırdan başlar.Felaket kurtarma ortamı üretimin aynı koddan üretilmiş hâli mi? Değilse tatbikat, üretimi değil başka bir sistemi test ediyor demektir.

Dördüncüsü özellikle önemli: kurtarma ortamının üretime birebir eşlik ettiğini varsaymak, bir şey kanıtlayan felaket kurtarma testi yapılana kadar bir varsayımdır.

Yetkinlik açığı bir eğitim sorunu değil, bir tasarım sorunu

%64'lük personel açığı rakamı, Terraform'un yaygınlığıyla onu ölçekte iyi işletmek için gereken uzmanlık arasındaki farkı gösteriyor. Bu açığı kapatmanın yolu daha çok eğitim değil, daha az seçenek sunmak: standart modüller, gözden geçirilmiş varsayılanlar ve politika denetimi.

Aynı disiplin uygulama katmanında da geçerli. Bir servisin gerçekten hazır olduğunu ilan etmenin nasıl yazıldığını Kubernetes readiness probe yazısında ele almıştık; hardening baseline'ının nasıl kurulacağını ise sistem sıkılaştırma sayfasında bulabilirsiniz.

Eclit'in otomasyon hattını nasıl kurduğunu DevOps sayfasında görebilirsiniz.