Altyapıyı kodla tanımlamak: IaC, CloudFormation ve Bicep ile uygulama yöntemi

Kod olarak altyapı ne demek, hangi sorunu çözer?

Kod olarak altyapı (Infrastructure as Code, IaC), sunucu, ağ, veritabanı ve yetki gibi bulut kaynaklarını konsoldan tıklayarak değil, metin dosyalarıyla tanımlama yaklaşımıdır. Dosya sürüm kontrol sistemine girer, gözden geçirilir, test edilir ve bir dağıtım aracıyla çalıştırılır. Böylece ortam kurmak bir kişinin hafızasındaki sıralı adımlara değil, tekrarlanabilir bir tarife bağlı olur.

Elle yönetilen altyapıda tipik sorunlar bellidir: geliştirme ortamı ile canlı ortam birbirinden sessizce ayrışır, kimin neyi neden değiştirdiği bilinmez, felaket sonrası ortamı yeniden kurmak günler alır. IaC bu sorunları şu yollarla azaltır. Değişiklik bir kod değişikliği olarak izlenir, aynı şablon farklı ortamlarda parametre farkıyla çalışır ve beklenen durum ile gerçek durum karşılaştırılabilir hale gelir.

Yazım biçimi açısından ayrım bellidir. Bildirimsel (declarative) araçlarda ulaşmak istediğiniz son durumu yazarsınız, araç oraya nasıl gidileceğini hesaplar. Emirsel (imperative) yaklaşımda ise adım adım komut verirsiniz. CloudFormation ve Bicep bildirimsel yazılır; AWS CDK ise bir programlama dili kullanır ama sonunda yine bildirimsel bir şablon üretir.

CloudFormation ile şablon ve yığın mantığı

CloudFormation, AWS kaynaklarını bir şablonla tanımlayan hizmettir. Şablon bir yığın (stack) olarak dağıtılır; yığın, şablondaki tüm kaynakların birlikte oluşturulduğu, güncellendiği ve silindiği birimdir. Bir kaynak oluşturulurken hata alınırsa yığın önceki duruma geri döner, böylece eksik kalmış ortam bırakılmaz.

Şablonun anlaşılması gereken bölümleri şunlardır: • Parametreler: ortamdan ortama değişen değerler, örneğin ortam adı ya da örnek boyutu. • Eşlemeler (Mappings) ve koşullar: bölgeye ya da ortama göre farklı değer seçmek, bir kaynağı yalnız belirli ortamda oluşturmak. • Kaynaklar: şablonun asıl gövdesi; her kaynak bir tür ve özelliklerle tanımlanır. • Çıktılar (Outputs): başka bir yığının ya da ekibin kullanacağı değerler, örneğin ağ kimliği.

Kaynaklar arası bağımlılık genellikle bir kaynağın diğerine referans vermesiyle kendiliğinden kurulur; sıralamayı elle yönetmeniz gerekmez. Şablon büyüdükçe iç içe yığınlarla parçalara ayrılır. Ağ, güvenlik ve uygulama katmanları ayrı şablonlarda tutulur, aralarındaki bağ çıktılar üzerinden kurulur. Çoklu hesap ve bölge dağıtımında aynı şablonun birden çok hedefe uygulanması da bu hizmetin kapsamındadır.

Bicep ile Azure altyapısını tanımlamak

Bicep, Azure kaynakları için geliştirilmiş alana özgü bir dildir. Azure'un yerleşik JSON tabanlı şablon biçimine göre çok daha okunaklı yazılır ve dağıtım öncesinde bu biçime derlenir. Temel yapı taşları parametreler, değişkenler, kaynaklar, çıktılar ve modüllerdir.

Modül, Bicep'in yeniden kullanım aracıdır. Bir depolama hesabı, bir sanal ağ ya da bir uygulama barındırma birimi bir kez modül olarak yazılır; farklı projeler aynı modülü kendi parametreleriyle çağırır. Böylece kurumun adlandırma kuralı, etiket standardı ve güvenlik varsayılanları tek yerde tutulur.

Dağıtım kapsamı da önemli bir kavramdır. Bir şablon kaynak grubuna, aboneliğe, yönetim grubuna ya da kiracı düzeyine dağıtılabilir. Kaynak grubunun kendisini oluşturmak ya da abonelik düzeyinde politika atamak için hedef kapsamın şablonda doğru belirtilmesi gerekir. Kapsam karışıklığı, yeni başlayanların en sık takıldığı noktalardan biridir.

Değişikliği güvenle uygulamak: önizleme, sapma ve test

IaC'nin gerçek değeri, değişikliği uygulamadan önce görebilmektir. CloudFormation'da değişiklik kümesi (change set) şablonun güncellenmesi halinde hangi kaynakların eklenip değişeceğini, hangilerinin silinip yeniden yaratılacağını listeler. Bicep tarafında benzer görevi dağıtım öncesi what-if işlemi görür. Silinip yeniden yaratılan bir veritabanı kaynağı bu önizlemede fark edilmezse veri kaybı yaşanabilir; bu yüzden önizleme çıktısını okumak bir alışkanlık olmalıdır.

Bir diğer kavram sapmadır (drift). Biri konsoldan elle bir ayar değiştirdiğinde gerçek ortam şablondan ayrışır. CloudFormation sapma tespiti bu farkı raporlar. Çözüm yönü nettir: ya değişiklik şablona işlenir ya da elle yapılan değişiklik geri alınır. Elle müdahaleyi tamamen yasaklamak ancak acil durumlar için ayrı bir süreç tanımlandığında işler.

Sonraki katman şablon testi ve politika denetimidir. Şablon dil denetleyicisiyle sözdizimi hatalarına karşı taranır, güvenlik politikaları kodla yazılır; örneğin şifrelenmemiş depolama ya da dışarıya açık yönetim portu içeren bir şablon dağıtım hattında reddedilir.

Örnek iş akışı: yeni bir test ortamını kodla kurmak

Örneğin bir ekip, canlı ortamın küçük bir kopyası olan test ortamına ihtiyaç duyuyor. Elle kurulum yerine akış şöyle işler. Önce ağ, veritabanı ve uygulama kaynakları şablona yazılır; ortam adı, boyut ve erişim kuralları parametre olur. Şablon bir depoda tutulur ve her değişiklik çekme isteğiyle gözden geçirilir.

Çekme isteği açıldığında dağıtım hattı şablonu denetler, önizleme çıktısını yoruma ekler. İnceleyen kişi hangi kaynakların etkileneceğini görür ve onaylar. Birleştirme sonrası hat şablonu test hesabına dağıtır. İş bittiğinde aynı şablonla ortam silinir; böylece kullanılmayan kaynak maliyet yaratmaz.

Aynı şablon canlı ortama yalnızca parametre dosyası değişerek uygulanır. Fark yaratan şey bu tekrarlanabilirliktir: ortam bozulursa onarmak yerine yeniden kurmak mümkün hale gelir ve yeni bir ekip üyesi ortamın nasıl kurulduğunu belgelerden değil kodun kendisinden öğrenir.

Başlangıçtan ileri düzeye öğrenme yolu

Başlangıçta bulut sağlayıcısının temel kaynaklarını konsoldan tanımak gerekir; ne kurduğunu bilmeden onu kodla tarif etmek zordur. Ardından tek bir kaynağı (örneğin bir depolama alanı) şablonla oluşturup silmek, parametre eklemek ve çıktı üretmek iyi bir ilk alıştırmadır.

Orta aşamada şablonu modüllere bölmek, koşullar ve döngülerle tekrarı azaltmak, birden çok ortamı parametre dosyalarıyla yönetmek gelir. Bu noktada sürüm kontrolü ve dağıtım hattı bilgisi şarttır; IaC, tek başına bir araç bilgisi değil, yazılım teslim disiplininin bir parçasıdır.

İleri aşamada politika denetimi, şablon testi, çoklu hesap dağıtımı ve kendi yapı taşlarınızı geliştirmek bulunur. Şablon yerine programlama dilinde yazmak isteyen ekipler için AWS CDK gibi araçlar soyutlama imkânı verir; aynı mantık fonksiyonlar, sınıflar ve birim testlerle kurulur. Hangi aracı seçerseniz seçin, bildirimsel düşünce biçimi ve durum yönetimi mantığı ortaktır.

Sık yapılan hatalar

• Her şeyi tek dev şablona koymak. Bir hata tüm ortamı etkiler, gözden geçirme imkânsızlaşır. Katmanlara ve modüllere bölün.
• Gizli bilgileri şablona ya da depoya yazmak. Parola ve anahtarlar bir gizli bilgi yönetim hizmetinden referansla alınmalıdır.
• Önizlemeyi atlamak. Bir özellik değişikliği kaynağın yeniden yaratılmasına yol açabilir; çıktıyı okumadan uygulamayın.
• Konsoldan hızlı düzeltme yapıp şablonu güncellememek. Sonraki dağıtım bu düzeltmeyi sessizce ezer.
• Ortamlar arası farkı şablon kopyalayarak yönetmek. Fark parametre ve koşulla taşınmalı, şablon tek kalmalıdır.
• Silme davranışını düşünmemek. Veri tutan kaynaklara koruma ve yedek politikası tanımlanmadan yığın silmek geri dönüşsüz kayıp yaratabilir.

Mindset programlarında nerede çalışılır?

AWS CloudFormation ile Altyapı Şablonlama eğitimi altyapı kod yaklaşımı ve şablon anatomisinden başlar; parametreler, eşlemeler ve koşullar, fonksiyonlar ile çıktılar, iç içe yapılar, değişiklik yönetimi ve sapma kontrolü, çoklu hesap ve bölge dağıtımı ile doğrulama ve politika denetimi modüllerini içerir.

Azure Bicep ile Altyapı Tanımlama eğitiminde Bicep dil yapıları, modül yapısı ve yeniden kullanım, dağıtım kapsamları ve pipeline entegrasyonu işlenir. Şablon yerine programlama diliyle çalışmak isteyenler için AWS CDK ile Programatik Altyapı Tanımı eğitimi kaynak tanımlama ve soyutlama seviyeleri, test ve güvenlik denetimi konularını kapsar.