Azure'da bir ASP.NET Projesinin Anatomisi (SDK2.2)

0 dakikada yazıldı

17944 defa okundu

Düzenle

Visual Studio'ya açıp ilk Azure projenizi yaratmaya başladığınız anda karşınıza hemen bir seçim ekranı gelecektir. Bu seçim ekranı epey kalabalık bir ekran gibi dursa da aslında özünde iki seçenek var :)

İlk Azure projemizi
yaratırken...İlk Azure projemizi yaratırken...

Seçeneklerden ilki "Web Role" ikincisi ise "Worker Role". Geri kalan tüm diğer seçenekler öyle veya böyle bu rollerin biraz daha değiştirilmiş, içi dolu halleri.

Web Role ile Worker Role arasındaki fark aslında çok basit. Web Role içerisinde bir web sitesi bulundurabildiğiniz bir role yaratıyor. Tabi bu arada unutmamak gerek ki her "role" azure deyimi ile bir sanal makine demek. Hatta Role'lerin kaç kopya (instance) olacağı da o rol başına yaratılacak sanal makine sayısını değiştirecektir. Worker Role ise varsayılan ayarlarında herhangi bir input veya output endpoint'i olmayan ve sadece işlem yapmak üzerine kurulu C#/VB kodu olarak düşünebilir.

Hızlı bir örnek vermek gerekirse; bir e-ticaret sitesinin site kısmı web role, arka plandaki sipariş işlemlerini yürüten kısmı ise worker role olarak düşünebilir. Sipariş işlemlerinin yürütülmesi, bankadan ödeme onayı, stok düşülmesi, kargolama işlemlerinin başlatılması gibi işlemler aslında doğrudan web sitesi ile alakalı işlemler değiller. Bu işlemlerin sonuçları web sitesinde gösterilse de bu işlemlerin yapılması web sitesinin değil arka planda çalışan bir başka kodun görevi olabilir. Bir anlamda background processing için de kullanabilirsiniz Worker Role'leri.

Bir azure projesinde birden çok web role veya worker role olabilir. Genelde tüm bu roller beraber bir azure service'ini temsil ederler. Web ile Worker role arasında ayrım yapmamızın bir nedeni de bu işlemleri ve role'leri ayrı ayrı ölçeklendirebiliyor olmak. Örneğin web sitenize gelen çok ziyaretçi varsa web role'ünüzden 10 instance (kopya / sunucu) alabilirken arkaplandaki işlemleri yürüten worker role sadece 2 instance olabilir. Çok farklı bir örnek olarak youtube'u ele alırsak. Sitenin ana yapısını, yani dışarıyla iletişimi sağlayan kısmı için belli 4000 instance (Server) tutulurken arka planda videoları işleyen kısım için 2000 instance alınabilir. Tüm bu ölçeklenebilirliliği bir de uygulamanız çalışırken kendi yüküne bakarak dinamik olarak yapabilirse "yeme de yanında yat" şeklinde süper bir Cloud çözümü oluşturmuş olursunuz. Tüm bunları ümit ediyorum ki zamanla yeni makalelerle blogda inceleyeceğiz :)

Şimdilik hızlı bir başlangıç için hemen ASP.NET Web Role'ü seçerek ilerleyelim. Projenizi yarattığınız gibi Visual Studio'da Solution Explorer'da aşağıdaki manzarayı göreceksiniz.

Solution'da bir Azure projesi
var.Solution'da bir Azure projesi var.

Solution içerisinde hemen bir azure projesi bir de asp.net projesi kendini gösterecektir. İşte buradan sonraki adımlarda Azure'daki ASP.NET projesinin normal bir ASP.NET projesinden farkına bakacağız :)

ASP.NET tarafındaki farklılıkları bulun
:)ASP.NET tarafındaki farklılıkları bulun :)

Yukarıdaki ekran görüntüsünden çok büyük olduğunun farkındayım :) Ama yapacak birşey yok. Gördüğünüz üzere farklılıklar alenen kendini gösteriyor :) Dört adet referans ve bir de ilginç C# dosyası. Şimdi nedir bu arkadaşlar tek tek onları inceleyelim.

WindowsAzure.Diagnostics

Azure üzerindeki bir ASP.NET uygulamasının artık birden çok sunucuda çalıştığı fikrine alıştık :) Bu sunuculardaki farklı performance counter'lar olsun trace loglarınız olsun farklı datalara ulaşmak istediğinizde işiniz zor olacaktır. Neden mi? :) Eh malum her sunucu logunu kendisi tutar. Peki sizin için tek tek sunucuların logları mı önemli yoksa uygulamanızın logları mı? Büyük ihtimal ile uygulamanızın loglarını almak isteyeceksiniz. Artık uygulamanızın kaç sunucuda çalıştığının önemli olmadığına alışmamız gerek :) Sunucu başına log almanın hiçbir anlamı yok çünkü eğer bir sunucuda problem varsa %99 ihtimal diğerlerinde de var. Bu sunucuların hepsi aynı şekilde yaratıldılar, aynı VHD'lerden oluşuyorlar ve sizin aynı uygulamanız üzerlerinde çalışıyor. O nedenle instance'larla ayrı ayrı uğraşmanın anlamı yok. CPU yükünü merak ediyorsanız 15 sunucuya yayılmış uygulamanızı 15 sunucudaki ortalama yükünü merak ediyorsunuzdur. Tekrar aynı konuya geri döneceğim fakat bunu netleştirmek çok önemli. Konsept olarak uygulamanızı bugün 15 sunucuya yaymak zorunda kalmanıza aslında yazılım geliştiricinin umrunda bile olmamalı çünkü bu durum tamamen bugünkü teknolojinin sınırları yüzünden ortaya çıkıyor. Yani bugün 15 sunucuda olan uygulama yarın 5 sunucuda olabilir :) Özetle instance sayısına göre hareket edemeyiz.

İşte tam da bu noktada :) tüm diagnostic bilgilerini alacak, merkezi bir yere koyacak bir ne? evet :) doğru tahmin ettiniz Agent gerekiyor. Diagnostics Agent Windows Azure'daki her base.VHD'de var. Makinede zaten kurulu olan Diagnostics Agent ile konuşup istediğiniz bilgileri toplamasını sağlamak, onları merkezi bir yere atmasını sağlamak için.... özetle Diagnostics Agent ile konuşmak için.... WindowsAzure.Diagnostics :) referansımızı kullanacağız. İşte bu kadar :) Diagnostics konusunun detaylarını ileride inceleyeceğiz ;)

ServiceRuntime ve Configuration

Uygulamanız artık normal bir ASP.NET projesi değil. Bu bir azure projesi. Aradaki fark ne? İsterseniz daha önceki yazılarda incelediğimiz Fabric Controler Host Agent hikayemize geri döneli. Fabric Controller Host Agent bizim uygulamayı IIS üzerine yerleştirip çalıştırmak ve sağlığını garanti etmekle sorumluydu. Yeri geldiğinde uygulamaya restart atıp recycle edicek olan da yine FC Host Agent. Peki ya biz FC Host Agent ile konuşmak istersek? Yani uygulamamı IIS'e attın ama başlatmadan önce haber ver bana.... veya uygulamamı IIS'e atmadan önce haber ver bana benim sana yaptırmak istediğim ek işler var.. gibi şeyler söylemek istersek FC Host Agent'a? :) Nasıl yapacağız? ServiceRuntime sayesinde! Artık Azure ortamında host edilen bir ASP.NET projemize var. Yani IIS üzerinde duran bir ASP.NET projesinin dışında bir kabuk daha var özünde, onun adı da WebRole :) Role'ün açılışı, kapanışı gibi eventler söz konusu. Daha gerçekçi bir örnek vermek gerekirse... diyelim ki ASP.NET projenizin arkasında bir windows servisi olması gerekiyor. ASP.NET projeniz başlamadan önce bu Windows Servisi'nin makineye kurulup çalıştırılması şart. İşte bunu doğrudan ServiceRuntime üzerinden FC Host Agent ile konuşarak yaptırabiliyorsunuz :) Nasıl mı? Detayları şimdilik ileri bir zamana bırakacağım ama ufak bir ipucunu bu yazının sonunda paylaşacağım ;) Sabır.

ServiceRuntime ile beraber Configuration sınıfı da çok önemli. CSCFG ile ilgili tüm operasyonlarımızı da kütüphane ile yapacağız. Malum normal şartlarda ASP.NET'in CSCFG'nin varlığından bile haberi yok :)

StorageClient

Storage hikayesi çoook uzun bir hikaye :) Her zamanki gibi detayları ileri bir yazıya bırakacağız. Peki bu referans da neyin nesi o zaman? Uygulamamızın artık birkaç sunucuya dağıldığını biliyoruz. Load Balancer üzerinden gelen talepler belki de 5 instance olarak ayarladığımız 5 farklı sanal makineye dağıtılıyor. Eh bu durumda o makinelerin disklerini kalıcı veri saklamak için kullanamıyoruz. Bunun birinci nedeni diskler sync edilmiyor birbiri ile. İkincisi ise.... tamamen atıyorum, network seviyesinde datacenter'da bir hata olduğunda FC'nin uygulamamı başka bir fiziksel sunucuya taşıması ihtimalinde tamamen var olan diskimi kaybedecek olmam. Tüm bunlar kötü gizi gözükse de normal dağıtık bir uygulamada yaşanan senaryolar. Allah'tan en azından Azure ortamında tüm bunları FC yönetiyor da :) uğraşmak zorunda kalmıyoruz. Yoksa malum bugün ne yaparsanız yapın 1000 instance'lık (sunuculuk) bir datacenter'a yayılan uygulamanız varsa, eninde sonunda donanım hataları da alırsınız :) Bunların başında disk sonra RAM gelir :) Neyse, konumuza dönelim.

İşte tüm bu senaryo çerçevesinde Azure'da ayrı bir servis olarak sunulan uygulamanız Azure'da olmasa bile kullanabileceğiniz Storage (kalıcı veri ambarı) servisleri var. Bu servislerin hepsi REST API'leri ile açılmış durumda. Kimsenin REST call'larla uğraşmak, retrypolicy'leri HTTP seviyesinde implemente etmek için can atmadığının Microsoft da farkında :) İşte tam da o nedenle tüm bu REST API'lerinin etrafında güzel bir wrapper olarak StorageClient sınıfı yetişiyor. Özetle :) bir yerlere bir dosya kaydedecekseniz bu assembly şart.

WebRole.CS

Ekran görüntüsünün en altlarındaki kalan WebRole.CS dosyasını unutmadınız değil mi? Sıra ona geldi. Aslında tüm bunlar arasında en basiti o. ASP.NET'teki Global.asax'ı bilirsiniz. Uygulama geneli event'leri vs yakalamamıza yardımcı olur. İşte WebRole.CS de onun Azure versyonu :) Özellikle ServiceRuntime ile ilgili konuşurken üzerinden geçtiklerimizi hatırlarsanız ASP.NET'in kendi yaşam döngüsü (lifecycle) üzerinde ayrıca bir de role yaşam döngüsü olduğundan bahsetmiştik. İşte WebRole.cs'de servis yaşam döngüsünün Global.asax'ı :)

[Webrole.cs]

namespace OrnekWebRole\ {\     public class WebRole : RoleEntryPoint\     {\         public override bool OnStart()\         {\             // For information on handling configuration changes\             // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.\ \             return base.OnStart();\         }\     }\ }

İlk yarattığımız projedeki webrole.cs yukarıdaki şekilde olacaktır. Basit hali ile sadece Role'ün başlangıcında birşeyler yapmak istiyorsanız kod yazabileceğiniz bir alan sunuyor :) Burada neler yapılabileceğine ileride bakarız ;)

İşte bu kadar :) Normal bir ASP.NET projesi ile Azure'daki bir ASP.NET projesinin farkları bunlar... desem de inanmayın :) Şaka bir yana özellikle migration senaryoları düşünülürse daha birçok farklılık kendini gösterecektir. Tüm bunları yavaş yavaş .. zamanla .. :) inceleyeceğiz. Fakat Visual Studio içerisindeki bir proje gözü ile bakarsanız normal bir ASP.NET projesi ile azure'daki ASP.NET projesi arasındaki farklılıklar bunlar.

Varolan projelerle nasıl ilerleriz?

Elinizde hali hazırda var olan bir ASP.NET projesini bir Azure projesine çevirmek istiyorsanız hemen Solution Explorer içerisinde efsane bir komut var :) "Add Windows Azure Cloud Service Project" :) Komutu verdiğiniz anda Solution içerisine bir Azure projesi eklenecek, web projeniz Azure projesine Web Role olarak tanımlanacak, Web projenize Azure referansları eklenecek ve işlem tamamlanmış olacak.

Var olan bir ASP.NET Role'e
çevirmek.Var olan bir ASP.NET Role'e çevirmek.

Bu noktada kesinlikle tekrar etmek gerek; herşey bu kadar tos pembe değil :) "Ekledim bitti, artık azure oldu" gibi bir sonuç kesinlikle çıkaramayız. Daha bu işin ciddi ciddi migration kısmı var. Şu an için yapının Visual Studio içerisindeki duruşuna ve neyin ne olduğuna bakıyoruz :)

Bir sonraki yazıda görüşmek üzere....