Azure ortamı ile ilgilendiğimizden beridir :) sürekli olarak her bir role instance'ın aslında kendi kalıcı veri saklama ortamının bulunmadığından bahsediyoruz. Bunun tabi ki bir çözümü var :) Windows Azure Storage adı verilen ayrı Azure servisleri paylaşımlı ve kalıcı bir disk alanı sağlayabiliyorlar. Fakat tüm bu servisler REST API'leri ile kullanılıyor ve paylaşımlı yani uzak noktada bir veri saklama yeri sağlıyorlar. Oysa bizim doğrudan kodumuzun çalıştığı yer olan sunucunun da bir diski var. Bu disk kalıcı olmasa da :) yani FC'nin farklı senaryolarda uygulamamızı farklı fiziksel/sanal sunuculara taşıyacağı ve diskimizi kaybedebileceğimizi bilsek de sonuç itibari o disk hala bizim kodumuzun en hızlı erişime sahip olduğu veri saklama birimi. Ayrıca :) tamamen beleş! Beleş derken :) zaten sunucumuzun vm boyutuna göre ödediğimiz para karşılığı aldığımız bir disk alanı olduğunu için beleş diyorum :) oysa ileriki zamanlarda inceleyeceğimiz Windows Azure Storage için ek ödeme yapmamız gerekecek.

Hoş Geldin Local Storage

Herhangi bir instance'ın kendi disk alanına ulaşmak isterseniz kullanmanız gereken yapı Local Storage yapısı olacak. Aslında kullanımı epey basit, ilk olarak Visual Studio'da role'ün ayarlarına geçiyoruz.

LocalStorage ayarlarımız karşınızda.

Role ayarlarındaki tablardan biri olan "Local Storage" tabına geçtiğimizde "Add Local Storage" diyerek istediğimiz kadar bir alan belirleyip bu alana da bir isim vererek işlemi tamamlayabiliyoruz. Artık verdiğimiz isimle tanımlanmış istediğimiz kadar bir disk alanımız oldu. Seçenekler arasında "Clean on role recycle" seçeneği biraz aldatıcı olabilir. Role recycle edildiğinde "Clean" demeseniz de yani o CheckBox'ı işaretlemeseniz de hala bu disk alanını geçiçi bir alan olduğunu unutmamak çok kritik!

[C#]

LocalResource X = RoleEnvironment.GetLocalResource("OrnekStorage");
var Path = X.RootPath;

İşte kod bu kadar :) Yukarıdaki kodu çalıştırdığınızda Path değişkenine "E:\XXX\YYY" gibi bir disk yolu gelecektir. Artık o yolu kullanarak istediğiniz gibi System.IO sınıflarını kullanabilirsiniz. Artık orası sizin istediğiniz boyutta tamamen kontrolünüze bırakılmış bir disk alanı.

Nereden? Nasıl? Niçin?

Başından beridir :) "aman dikkat bu disk kalıcı değil" gibi :) sürekli tehlike çanlarını çalıyorum :) Peki o zaman LocalStorage neden var? LocalStorage geçiçi işlemler için geçici fakat çok yüksek performanslı bir disk alanı olarak düşünmek çok doğru olur. Random Read/Write için süper bir seçenek. Kodunuz işleyeceği bir dosyayı diske alıp işleyip sonra kalıcı bir veri saklama alanına koyabilir. İleriki zamanlarda işleyeceğimiz diğer veri saklama yöntemlerinde hem sakladığımız veri miktarı hem de transaction başına para ödememiz gerektiğini göreceğiz. Oysa buradaki disk hem makine ile beraber gelen beleş bir alan hem de yaptığımız IO işlem yoğunluğuna göre ek bir para vs ödememiz gerekmiyor.

Hepinize kolay gelsin ;)

İlk zamanlarda Azure'a Remote Desktop ile bağlanmak çok daha meşakkatli bir işken artık yeni SDK'ler ile beraber çok basit bir hale geldi. Peki nedir tam olarak bu Remote Desktop? Azure'a Remote Desktop ile bağlanmak ne demek?

Biliyorsunuz deploy ettiğimiz her role'ün birden çok instance'ı var. İşte her bir instance'ın çalıştığı size ait olarak sanal makineye remote desktop ile bağlanabiliyorsunuz. Peki bunun amacı ne? Amacı tamamen debugging. Yani remote ile bağlaniyim bazı ayarlar yapıp çıkiyim gibi bir düşünceniz olmasın :) Unutmayın ki bu makineler her an değiştirilebilir, yani bir hata vs olduğunda FC uygulamanızı taşıyabilir ve makinede remote ile bağlanıp yaptığınız tüm değişiklikler uçar gider. O nedenle remote bağlantısını daha fazla bir debugging aracı olarak düşünmek gerek.

Visual Studio'dan Publish

Bugüne kadar önceki makalelerle publish ve upgrade yöntemlerine göz atmıştık fakat hiç Visual Studio içerisindek direk publish denemedek. Remote Desktop konusunda hem azure management panelinden bir sertifika yüklemek hem de servisinizin csdef ve cscfg'sinde ayarlar yapmak gerekiyor. İşte tüm bu ayarları ve süreci kolaylaştırmak adına Visual Studio ile beraber gelen Publish Wizard'ını kullanmak en akıllıcası.

Visual Studio içerisinde Publish Wizard'ı kullanırken.

Publish Wizard açıldıktan sonra karşınıza boş bir liste gelecek. Benim aşağıdaki ekran görüntüsünde subscription listesinin dolu gelmesine aldanmayın :) O sizde boş gelecek. Şimdi burada aslında yapılması gereken daha önce bahsettiğim gibi bizim azure hesabına ulaşılması için azure'un yönetmin panelinden bir management certificate yüklenmesi sonra onun kendi bilgisayarımızda da ataçlanması vs gibi uzun bir süreç.

Publish Wizard'a Azure hesabımız için yaratılmış bir sertifikayı vermek gerekecek.

Bunun yerine yukarıdaki ekran görüntüsünde "Sign in to download credentials" dediğinizde özel bir sayfaya yönlendirileceksiniz. Sayfaya direk azure hesabınızın LiveID'si ile login olduğunuzda uzantısı *.publishsettings olan bir dosya downloada başlayacak. İşte o dosyayı download edip yine yukarıdaki ekran görüntüsündeki "Import" düğmesine basıp Import etmeniz gerekiyor. publishsettings dosyasının içeriğine bakarsanız zaten bir sertifika ve subsriptionların ID'lerini bulabilirsiniz.

[publishsettings]

<?xml version="1.0" encoding="utf-8"?>
<PublishData>
  <PublishProfile
    PublishMethod="AzureServiceManagementAPI"
    Url="https://management.core.windows.net/"
    ManagementCertificate="XXXXXX">
    <Subscription
      Id="35283b01-5568-48cb-97cc-XX"
      Name="Azdem155G43017W" />
    <Subscription
      Id="3aaeb2e8-fb95-4e6c-a785-XX"
      Name="Windows Azure MSDN - Visual Studio Ultimate" />
    <Subscription
      Id="d3d0c62a-f14e-4195-a4b5-XX"
      Name="DEVELOAD" />
  </PublishProfile>
</PublishData>

Import işlemi bittikten sonra uygulamanızı publish etmek istediğiniz subscription'ı seçip sihirbazda yavaş yavaş ilerleyebilirsiniz :)

Remote Desktop seçeneğini aktif hale getirmeli.

Gördüğünüz gibi aslında webdeki yönetim panelinde yapabildiğimiz çoğu şey bu sihirbazda da yapabiliyoruz. Var olan bir servisi seçip upgrade başlatabilirsiniz veya yeni bir servis bile yaratabilirsiniz. Ekranın en altındaki "Enable Remote Desktop for all roles" ise bizim ilgileneceğimiz seçenek olacak. Checbox'ı işaretledikten sonra yanındaki "Settings" düğmesine basarsanız remote desktop için kullanacağınız kullanıcı adı ve şifresini de belirleyebilirsiniz.

Artık sihirbazın sonuna doğru ilerlemeye hazırız. En sonda bizi "Publish" düğmesi bekliyor olacak. Basarak hem yaptığımız değişikliklerin hem de uygulamanın yeni sürümünün sunucuya atılmasını sağlayabiliriz.

Visual Studio içerisinden deployment devam ediyor.

Deployment başladıktan sonra tüm detayları Visual Studio içerisindeki "Windows Azure Activity Log" penceresinden izleyebilirsiniz. Herşey tamamlandığında remote bağlantı için tekrar web yönetim paneline yönlenmemiz gerekecek.

İstediğimiz Instance'a Remote...

Yönetim paneline girdikten sonra istediğiniz bir Instance'ın listeden seçip sonrasında yukarıdaki "Connect" düğmesini kullanarak Remote bağlantıyı başlatabilirsiniz. Remote Desktop'a geçtiğinizde sizden Visual Studio içerisindeyken yaratmış olduğunuz şifre istenecektir. Onu da girdiğiniz kendinizi bir anda Azure'daki bir sanal makinenin desktopında bulacaksınız.

Azure'daki makinemizin diskleri...

Makineye hazır RDP yapmışken :) biraz ortalığı karıştıralım değil mi? Hatırlarsanız her sanal makineye ek üç tane VHD ataçlanıyordu. Bunlardan üçünü de yukarıdaki listede görebiliyoruz. Birinde işletim sistemi, diğerinde uygulamamız, sonuncusunda da bize özel bir disk alanı bulunuyor.  Bu disk alanının artık kalıcı bir veri saklama ortamı olmadığı fikrine alıştık sanırım :) Son birkaç yazıdır bundan sürekli bahsediyoruz ;)

Small Instance Konfigürasyonu

Biliyorsunuz Small Instance'da tek çekirdek var. Bu çekirdeğin 2.1 GHz bir AMD olduğunu görmüş olduk. Ayrıca spesifikasyonlara uygun şekilde 1.75GB da RAM'imiz var Small Instance'da.

Uygulamamız diske açılmış :)

Diskleri biraz daha karıştırdığımızda uygulamamızı da doğrudan kendi diskinde bulabiliyoruz. Bizim webform1.aspx işte burada :)

Azure'da bir role altında çalışan processler.

Son olarak gelin bir de sistemde çalışan processlere göz atalım :) Yukarıdaki ekran görüntüsünde gördüğün listedeki bazı processler bizi ilgilendiren ve azure mimarisinden tanıdık olduğumuz uygulamalar.

1. Windows Azure Drives adında bir role ek VHD ataçlanmasını sağlayan ek bir özellik için kullanılır. İleriki yazılarda bu konuya değineceğiz.
2. Diagnostic dataların toplanmasını ve merkezi bir yere kopyalanmasını sağlar.
3. Diagnostic dataların toplanmasını ve merkezi bir yere kopyalanmasını sağlar.
4. Makineye remote bağlantı yapılabilmesini sağlar.
5. Windows Azure Guest Agent (FC Guest Agent) ve bootstrapper.
6. Hyper-V guest VM integration servisleri
7. Web role'ün IIS ayarlarını yöneten bir WCF named pipes servisi.

İşte böylece hem azure'daki bir instance'a nasıl RDP yapabileceğimizi gördük, hem Visual Studio içerisinden deployment senaryosuna göz atmış olduk hem biraz da azure'daki sanal bir makineyi karıştırdık ;)

Hepinize kolay gelsin.

Azure ortamına bir servisi deploy ettikten sonra doğal olarak bir gün onu upgrade de etmemiz gerekecek :) İşte gibi bir senaryoda ilerleyebileceğim birkaç yol var. Bunlardan ilki normal upgrade prosedürü. Her zamanki gibi Azure projenize sağ tıklar ve package'ı yaratırsınız. Sonra management portalına girersiniz :)

Normal bir upgrade senaryosu...

Upgrade etmek istediğiniz deployment'ı seçip sağ tıkladığınız anda gelen context menüden upgrade komutunu vererek upgrade sürecini başlatabilirsiniz.

Upgrade sürecini başlatırken.

Upgrade'i başlattığınız anda karşınıza yukarıdaki ekran gelecektir. Yeni deployment için bir isim verebilir ve yani azure deployment paketi ile konfigürasyon dosyasını iletebilirsiniz. Eğer ki VM Size veya Role sayılarında bir değişiklik oluyorsa en alttaki CheckBox'ı işaretlemeyi unutmayın. Dikkat :) Role sayısı, instance sayısı değil. Yani özetle aslında öğrenilmek istenen şey CSDEF'de değişiklik oldu mu bilgisi.

Bu noktada "OK"'e basmanız halinde upgrade işlemi başlayacak ve instance sayınıza göre her upgrade domain gezilerek tek tek otomatik upgrade edilecek. Fakat gelin bir de farklı bir senaryoya bakalım :) ama bunun için önce upgrade öncesinde bulunan ve daha önce deploy edilmiş olan servisimizin içindeki web role'ün instance count'unu değiştirelim.

Servis çalışırken konfigürasyonu değiştirmek.

Herhangi bir deployment'ı seçip üst menüden "Configure" komutunu verirseniz karşınıza aşağıdaki ekran gelecektir. Bu ekranda yeni bir konfigürasyon dosyasının azure paketini deploy etmeden sisteme atabilir veya hali hazırda bulunan konfigürasyonu direk text olarak düzenleyebilirsiniz.

Instance Count'u 2'ye değiştirirken.

Ben açılan ekranda hemen Instance Count'u 2 yaparak elimdeki web role'e yeni bir sunucu daha eklenmesini sağlayacağım. Yeni sunucunun ayağa kaldırılması, uygulamanın yüklenip sunucunun Load Balancer'a eklenmesi için bir 5dk beklememiz gerekecek.

Manual Upgrade

İşlem tamamlandıktan sonra Upgrade senaryomuza geri dönelim. Upgrade için ana projemizdeki Instance Count'u da iki yapıp, yeni bir baket yaratıp bu sefer Upgrade penceresinde "Upgrade Mode" olarak Manual'i seçeceğiz.

Manual upgrade'de her bir upgradedomain'in upgrade olmasını bizim tetikleyebilmemiz sağlanıyor. Yani normal şartlarda azure tek tek her upgrade domain'i load balancer'dan çıkarıp sırayla upgrade ederken Manual seçenekte her adım için bizden onay bekleyecek.

Upgrade'i başlatmaya hazırız.

Upgrade işlemini onayladığınızda ve yeni paketiniz azure'a yüklenip işlemler başlamaya hazır olduğunda yukarıdaki gibi bir manzara ile karşılaşacaksınız. Artık manual update işlemini başlatmaya hazırız.

Manual Upgrade'i bu sefer gerçekten başlatalım :)

Upgrade işlemine hazır olan Deployment'ı seçtiğinizde üst ribbon menüde "Start" diye bir komut göreceksiniz. Start komutuna basmak upgrade işlemlerinin başlaması için yeterli. İşlemleri başlattıktan sonra da tek tek upgradedomain'lerin onaylarını vereceğiz.

Tek tek upgrade...

Role'ümüzde iki instance olduğu için bu instancelardan biri ayrı bir upgradedomain diğeri ise ayrı bir upgradedomain'e alınmış durumda. Yukarıdaki ekran görüntüsünde ilk instance upgrade edilmiş ve bitmiş. İkincisi ise yeni tetiklenmiş. Tüm upgradedomain'leri gezene kadar sürekli ribbon'daki Start'a basarak tek tek upgrade'leri tetikleyerek bir yandan da uygulamanızın durumunu test edebilirsiniz.

VIP Swap

Bir diğer upgrade yöntemi ise VIP Swap. VIP Swap aslında arkada hem bir production hem de staging deploymentlarınızın olmasını gerektirir. Yaptığı işlem ise basitçe domainlerle IP'leri değiştirmektir :) Yani bir anda staging deployment'ınızın production, production ise staging olur. Bunun en büyük avantajı tabi ki anında geri dönebiliyor olmanız :) bir sorun gördüğünüz anda çat diye eski haline çevirmeniz mümkün. Bu süreçte kesinlikle sunucularda bir upgrade süreci başlatılmıyor çünkü zaten upgrade edilmiş bir staging ortamını upgrade edilmemiş bir production ile değiştiriyorsunuz.

VIP Swap'in belki tek dezavantajı 2000 instance'lı bir deployment'ınız varsa :) bunu bire bir aynı şekilde hem staging hem de production için tutmak zorunda olmanız. Her iki ortamın CSDEF'lerinin bire bir aynı olması gerekiyor. Eğer CSDEF'te değişiklik varsa VIP Swap yapma şansınız olmayacaktır. Staging'de de aynı kaynakları muhafaza etmeye gelince.. itiraf etmek gerekirse 2000 instance da olsa sonuçta staging'i test amaçlı tutar ve SWAP sonrası herşey yolundaysa staging sunucularını silerseniz sonuçta sadece kullandığınız saat kadar ödeme yapacağınız için çok büyük bir sorun da yaratmayacaktır.

VIP Swap

VIP Swap yapabilmek için herhangi bir deployment'ı seçip üst ribbon menüden "Swap VIP" komutunu verebilirsiniz. İşlem zaten süper kolay tamamlanacaktır ;)

Kolay gelsin.

Artık yavaş yavaş birşeyleri Azure ortamında görmenin zamanı geldi :) Hemen Visual Studio'yu açıp "File / New Project" üzerinden "Cloud"'u seçip ilk projemizi yaratalım. Bunu yaparken de Cloud projemize deneme amaçlı olarak bir ASP.NET sitesinde ekleyelim.

İlk Azure projemiz...

Projemizi yarattıktan sonra ASP.NET tarafındaki tüm dosyaları silip basit bir ASPX ekleyip içine de klasik :) "Hello World" yazabiliriz. Böylece minimalist bir ASP.NET sitemiz olmuş olacak.

Basit bir Cloud projesi.

Dikkat ederseniz WebRole.Cs ile Web.Config'i silmedim. Konsept olarak onları bırakmakta fayda var :) Web.Config'in içini yine de aşağıdaki şekilde temizleyebilirsiniz. Malum sample site'ı sildiysek onunla ilgili gereksiz ayarları da silmekte fayda var.

[web.config]

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.diagnostics>
    <trace>
      <listeners>
        <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, 
            Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, 
            PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
          <filter type="" />
        </add>
      </listeners>
    </trace>
  </system.diagnostics>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
</configuration>

Artık default.aspx'in arkasındaki "Hello World" kısmını siz halledersiniz :) Projemiz ilk ayarlarında tek instance ve small vm size çalışacak şekilde geliyor. Şimdilik orada bir değişiklik yapmayacağız ve hemen deployment'a geçeceğiz.

Windows Azure hesabı edinmek

Windows Azure hesabı edinmek için basit bir şekilde windowsazure.com adresine gitmeniz gerekiyor. Buradan yeni bir hesap edinebilirsiniz veya deneme hesabını da buradan alabilirsiniz. Her iki seçenekte de Microsoft kredi kartı bilgileri alacaktır. İlk seçenekte normal bir hesap aldığınız için doğal olarak kullandığınız kaynakların ücreti kredi kartınızdan çekilecek. Azure ortamında neye ne kadar para ödediğimiz konusunu ileride inceleyeceğiz fakat şimdilik kullandığınız sunucular için saat başına para ödediğinizi bilmenzide fayda var. Eğer bir deneme hesabı aldıysanız yine sizden kredi kartı bilgileriniz alınacak fakat deneme süresi bitene kadar kesinlikle kartınızdan para çekilmeyecek. Eğer deneme hesabının limitlerine gelirseniz o ay için deneme hesabınızdaki kaynaklar kapatılacak. Bir sonraki ayda tekrar açılarak deneme hesabı limitlerinde azure hizmetlerini tekrar kullanabilir hale geleceksiniz fakat bu süreçte hiçbir zaman kredi kartınızdan para çekilmeyecek. Deneme hesapları için kredi kartı bilgis alınmasının birinci nedeni spam deneme hesabı alınmasını engellemek ikincisi ise deneme dönemi bittikten sonra kullanılan kaynakların ödemesini alabilmek.

Azure hesabınızı edindikten sonra yönetim paneli için sürekli ziyaret edeceğiniz adres ise http://windows.azure.com şeklinde olacak. Tamamen Silverlight ile geliştirilmiş olan bu site Azure ortamındaki tüm servisleri kullanabilmenizi, yönetebilmenizi sağlayacak. Biz de şu anda elimizde olan HelloWorld projesini bu portal üzerinden azure'a yükleyeceğiz.

Azure uygulamamızı paketlemek.

Azure projemiz ve hesabımız artık hazır olduğuna göre hemen Visual Studio'da Solution Explorer içerisinde Azure projesine sağ tıklayıp "Package" komutunu verebiliriz.

Azure Package yaratırken.

Bir sonraki adımda karşınıza çıkacak soru paket yaratırken service configuration olarak Cloud.cscfg veya Local.cscfg'nin kullanımı vey Release veya Debug Build kullanılıp kullanılmayacağı şeklinde olacak. Genel olarak tabi ki Cloud.cscfg'yi ve Release build konfigürasyonunu kullanacağız.

Azure paketimiz hazır.

Paketleme işlemi bittiği gibi hemen paketlerin bulunduğu klasör ekranınıza gelecektir. Yukarıdaki ekran görüntüsünden de görülebileceği üzere toplam iki tane dosyamız var. Bunlardan CSPKG adından da tahmin edilebileceği üzere "Cloud Service Package" yani uygulamamızın tüm dosyalarını içeren paket. Diğer dosya ise CSCFG :) işte bu sanırım şu anda ciddi tanıdık geliyor. Bizim Cloud.CSCFG'nin ta kendisi. Özetle :) konfigürasyon dosyası ayrıca dururken geri kalan herşey bir paket içerisinde toplanmış durumda.

Bu noktada gelin birkaç şeyin üzerinden tekrar geçelim. Birinci sorumuz :) CSDEF nerede? Cevap : CSDEF paketin içerisinde. Yani eğer CSDEF'te bir değişiklik yapmak isterseniz tüm paketi tekrar yaratıp yollamak zorundasınız. Paketi tekrar yollamak ise bir upgrade başlatmak demek. Sanırım şu anda neden konfigürasyon dosyasının dışarıda bırakıldığını anlamışsınızdır :) konfigürasyon dosyası paket değiştirilmeden yani uygulamaya upgrade yapılmadan da değiştirilebiliyor. Bu da tabi ki ciddi bir esneklik sağlıyor.

Hemen bir noktayı daha hatırlayalım :) VM Size bilgisi CSDEF'teyken Instance sayısı CSCGF'deydi. Yani VM Size değiştirirseniz tekrar paket yaratıp yollamanız gerekecek, aynı şey role'lerinizin endpoint bilgileri için de geçerli. Oysa Instance sayısı CSCFG'de olduğu için uygulamaya upgrade yapılmadan uygulama çalışırken de değiştirilebiliyor.

Sıra geldi deployment'a...

Hemen http://windows.azure.com adresine gidip LiveID'miz ile giriş yaparak yönetim paneline ulaşıyoruz. Panel daha önce de bahsettiğimiz üzere bir Silverlight uygulaması. Uygulama 30 saniye aralıklarla elindeki veriye refresh atıyor :) o yüzden arada sırada beklemek zorunda kalabiliyoruz. Refresh counter'ını ekranın sol altında görebilirsiniz. Ben özellikle bu refresh sayesinde session'ımın expire etmemesine bayılıyorum :) Bir günden daha fazla paneli açık bırakıp direk tekrar kullanabilir olmak güzel :) Basit ama güzel :)

Azure Yönetim Paneli

Panelin sol altında farklı Azure servislerinin kaba bir listesini görebilirsiniz. İşte bu listeden panelin farklı bölümlerine geçerek işlemlerimizi yapabiliyoruz. Hemen sol alttan "Hosted Services" seçeneğini seçerek ilerleyeceğiz.

Azure ortamında hosted serviceler.

Sol taraftan "Hosted Services, Storage Accounts & CDN"'i seçtikten sonra yukarıdan da tekrar "Hosted Services"'i seçerseniz panelin orta kısmında tüm servislerinizi görebilirsiniz. Eğer yeni bir hesap açtıysanız tabi ki burası boş gelecektir. Bende hali hazırda bir deployment olduğu için o da gösteriliyor. Benim örneğimde "shortone" adında bir service deployment'ı var. Söz konusu bu servisin "prod4" adındaki deployment'ı altında bir tane Worker Role bir tane de Web Role bulunuyor. Her iki role de ikişer instance şeklinde düzenlenmiş.

Bu ekran görüntüsünde dikkat edilmesi gereken bir diğer nokta ise bende toplam 3 subscription olması. Bu aslında üç tane ayrı Windows Azure hesabı anlamına geliyor. Farklı Azure hesabları aynı LiveID'ye bağlanabiliyor. Durum böyle olduğunda LiveID'niz ile login olduğunuzda bu hesapları subscription olarak görebiliyorsunuz. Bu ayrım genelde projeler arası "muhasebe" kapsamında da ayrım yapmak istediğinizde çok mantıklı olabilir.

İlk Hosted Service'imiz.

Panelde uygun subscription'ı seçtikten sonra üst ribbon bar'da "New Hosted Service" diyerek yeni bir servis yaratmaya başlayabiliriz. Bu servis bizim biraz önce yarattığımız HelloWorld web uygulamasını barındıracak.

Servisimizi yüklerken...

Yukarıdaki ekran ilk servis yaratırken ve yüklerken karşımıza çıkacak olan ekran. En üstte yine subscription seçebiliyorsunuz. Bir allta service'e istediğimiz gibi bir isim verirken "URL prefix" ise servisimizin barındırılacak adresi yaratmak için kullanılıyor. Sonrasında istersek elimizdeki farklı domain'leri de buraya yönlendirme şansımız var ama isterseniz doğrudan deneme.cloudapp.net gibi Azure'un verdiği bir adresi de kullanabilirsiniz.

Bir alt kademede servisimiz barındırılacağı datacenter'ın konumunu seçiyoruz. Servisinizin kullanacağını düşündüğün ülkelere olabildiğinde yakın bir datacenter seçmek çok mantıklı olacaktır. Şu an için kabaca her kıtada iki datacenter var.

Deployment options denilen kısımda üç seçenek var. Bunlardan en sonuncusu bir deployment yapmamak ve sadece servisi tanımlamak. Böylece deployment'ı sonra da yapabilirsiniz. İlk iki seçenek ise production ve sating olarak ayrılıyor. Bu iki ayrım arasında sadece tek bir fark var :) servisiniz yayınlanacağı adres. Production deploymentı yaparsanız önceki adımlarda seçtiğinizde adreste siteniz yayında olur. Staging derseniz size özel apayrı bir staging URL daha yaratılır ve deployment oraya yapılır. Staging daha fazla test amaçlı ve herkesin görmediği bir alan olarak düşünebilirsiniz.

Son olarak deployment'ımıza da bir isim verip artık azure servis paketimizi ve konfigürasyon dosyamızı verebiliyoruz. Zaten Visual Studio paketi yarattıktan sonra klasörünü açmıştı, hemen orada dosyaları gösterebilirsiniz. Şimdi gönül rahatlığı ile "OK"e basın ve süreci panelden izleyin :) Upload dahil sunucuların provisioningi toplam 10 dakikayı bulacaktır. Bu süreçte FC Azure DataCenter'ında istediğimiz şartlara uygun boş yer bulacak, VM'leri dağıtacak, ayağa kaldıracak, load balancer'a haber verecek vs vs vs :)

SLA SLA SLA! :) %99.95 için 2 instance şart.

Yüklemenizi başlattığınız anda yukarıdaki şekilde bir uyarı alacaksınız. Bunun nedeni çok basit :) Bizim uygulamadaki web role tek instance çalışmak üzere ayarlı ve Azure bu durumda %99.95'lik garantisini veremiyor. İşte uyarı da bununla ilgili. "Yes" diyerek bu uyarıyı es geçip deployment'a devam edebilirsiniz. Fakat unutmayın :) tavsiye edilen her zaman 2 instance, benden söylemesi.

Paket upload olurken...

Upload işlemi bittikten sonra sonra servisinize role sayısına ve instance sayısına göre sunucuların hazırlanması 5 ile 15 dakika arasında sürebiliyor. Süreci doğrudan yönetim panelinden izleyebilirsiniz.

Herşey hazır olduktan sonra servisinizin deployment'ını seçip yönetim panelinin sağ tarafındaki konsoldan da servise ait linki bulabilirsiniz. Tıklayın ve servisinizi azure ortamında çalışır görün ;)

Staging için verilen adres.

İtiraf ediyorum :) tüm bu deployment senaryosunu kolaylaştırmanın bir yolu var :) ama bire bur bu senaryoyu görmek de bence çok önemli. Neyin ne olduğunu anlamak ve yönetim paneli ile azure paketimiz arasında ilişki bence kritik. İleriki yazılarda farklı konulara da bakarken Visual Studio içerisinden doğrudan Publish senaryolarına göz atacağımz ;)

Görüşmek üzere.

İşte çoğunuzun beklediğini tahmin ettiğim etkinlikle karşınızdayım!!! :) İki tam gün Windows 8 Metro development etkinliği ve tabi ki her zamanki gibi ÜCRETSİZ! 5-6 Mayıs (Cumartesi-Pazar) tarihlerinde Microsoft Istanbul ofisinde olacak bu etkinliği kaçırmayın derim.

Hafta sonu 2 günlük ücretsiz Win8 Development Kampı

İki gün boyunca Windows 8 Metro Style App development konusuna göz atacağımız etkinliğin ikinci gününde bol bol da lablarımız olacak. O nedenle :) her iki güne de gelirken bilgisayarınızı getirmeniz, hatta Windows 8 Consumer Preview ile beraber Visual Studio 11 Beta'yı da kurmuş olmanız şart. Aksi halde herkes lab yaparken kurulumlarla uğraşmak zorunda kalabilirsiniz. (Not: isteyenler VMWare 8 sanal makine imajı verebilirim etkinlikte)

KAYIT OLMANIZ GEREK! :)

Evet, etkinliğe katılmak için kayıt gerekiyor her zamanki gibi. Böylece kahve lojistiğimizi ayarlayabiliyoruz :) Kayıt için hemen buraya tıklayabilirsiniz. Süper olacağından emin olduğum bu hafta sonunu kaçırmayın derim.

Azure ortamında yayınlayabileceğimiz role'lerin instance count ve instance size gibi özellikleri olduklarını daha önceki yazılarda görmüştük. Böylece uygulamamızın kaç sanal makinede çalışacağına, ne kadar kaynak kullanacağına karar verebiliyoruz. Azure'un en önemli noktalarından biri ise Fault Tolerance yani hata toleransı. En basit noktada Microsoft, Azure ortamındaki uygulamalarda %99.95 uptime (çalışır durumda olma) garantisi veriyor. Bu garantiyi verebilmek için tabi Microsoft'un bir şartı var, o da her role'ün en az iki instance olması. Bu istek tabi ki çok doğal bir istek fakat %99.95'i garantilemek ve hatta yükseltmek için aklımızda bulundurmamız gereken birkaç detay daha var. İşte bunlar da Fault Domain ve Update Domain ;)

Fault Domain

Varsayılan ayarlarda her role'de en az iki tane Fault Domain oluyor. Maalesef şimdilik Fault Domain sayısını biz belirleyemiyoruz ve tamamen bizden bağımsız bir şekilde FC (Fabric Controller) tarafından yönetiliyor. Normal şartlarda iki instance bir role yüklediğimizi düşünürsek her bir instance ayrı Fault Domain'lere alınacaktır.

Fault Domain'lerin amacı network seviyesinde veya doğrudan donanım seviyesinde hatalar olduğunda uygulamanızın ayakta kalmasını sağlamak. Bunun için iki instance olan bir role'ün her instance'ı Azure DataCenter'ı içerisinde farklı Rack'lere yerleştiriliyor. Eğer bir Rack'te sorun çıkarsa söz konusu instance başka bir noktaya taşınana kadar FC Load Balancer'a trafiği kalan instance'lara göndermesini söylüyor. Bu sürede yeni VM (sanal makina) hazır olduğunda uygulamanız oraya yüklenerek yine trafik aktarımı başlatılıyor.

Upgrade Domain

Azure ortamında projenize bir upgrade gönderdiğinizde doğal olarak tüm instance'ların kapatılıp, upgrade edilip tekrar açılmaları düşünülemez. Uygulamanız çalışır durumdayken bir yandan da bölüm bölüm upgrade edilmeleri gerekiyor. İşte bu noktada UpgradeDomain'ler devreye giriyor. UpgradeDomain'leri "beraber upgrade edilecek instance" grupları şeklinde düşünebilirsiniz. Eğer iki instance uygulamanız varsa önce ilki Load Balancer'dan çıkartılacak ve upgrade edilecek, sonra da ikincisi. Böylece dışarıdan gelen taleplere sürekli olarak cevap verebilen ve ayakta olan bir instance kesinlikle olacak. Azure içerisinde Upgrade Domain sayısının varsayılan değeri 5.

UpgradeDomainCount csdef içerisinde.

UpgradeDomain sayısını isterseniz CSDEF içerisinde düzenleyebilirsiniz. UpgradeDomain sayısı ile FaultDomain sayılarının ve tabi ki instance sayınızın farklı durumlardaki birleşimi çok farklı sonuçlar verebilir. Bu konuda çok yapabileceğiniz birşey olmasa da :) en azından başınıza neler gelebileceğini bilmenizde fayda var.

Diyelim ki UpgradeDomainCount sayısını ayarlamadınız ve varsayılan değeri olan 5 ile kaldı. Uygulamanızı ise 3 instance olacak şekilde ayarladınız. Karşınıza çıkabilecek seçeneklerden biri aşağıdaki şekilde;

Senaryo 1

Yukarıdaki manzara çok güzel gözüküyor. Herşey güzel bir şekilde dağıtılmış. FaultDomain'lerden biri giderse geriye iki instance kalacağı garanti. Aynı şekilde Upgrade gerçekleşirken de tek bir instance dışarı çekilecek ve upgrade tüm instance'lara tek tek yapıldığı sürede de en az iki instance sahibi olacağımızı biliyoruz. Yani :) 3 instance olarak düzenlediğimiz senaryoda arada sırada 2 instance'a düşme ihtimalimiz var. Tabi burada şu notu da iletmem gerek, FaultDomain'lerin çatlaması her dakikada bir olan birşey değil. Belki de aylarca hiç başınıza gelmeyecek ki zaten başınıza gelse de pek farkına varabileceğinizi sanmıyorum ama yine de bu durumu akılda tutmak gerek. 3 instance olduğunda 10 dakika için sadece 1 instance kaybediyor olmak çok problem olmasa da 3000 instance kullanırken 10 dakikalığına 1000 instance kaybetmek ciddi sorun olabilir.

Senaryo 2

Peki ya FC performans kazanmak amacıyla toplam 3 instance'ınızın ikisini aynı Fault Domain'e koyma kararı alırsa? Fault Domain sayısını bizim belirleyemediğimizden bahsetmiştik. İşte böyle bir durumda hangi Fault Domain'de hata yaşandığına göre 1 veya 2 instance'a düşme şansınız var. Hatta daha da felaket senaryolarına doğru ilerlersek eğer network seviyesinde / Rack seviyesinde hata gerçekleşirken siz de upgrade gerçekleştiriyorsanız :) yukarıdaki resimden hem UpgradeDomain2'yi hem de Fault Domain 1'i kaldırırsanız... servisiniz tamamen aşağı inmiş oluyor. Tabi burada şunu diyebilirsiniz :) Fault varsa neden upgrade domain'e upgrade çakarsın ki? :) ya tam upgrade anına denk geldiyse ve zaten upgrade süreci başlamıştıysa :) Çok ince bir ip üzerinde olduğumuzun farkındayım, milyonda bir ihtimallere doğru ilerliyoruz ama en azından bu detayları bilmekte fayda var diye düşünüyorum.

Senaryo 3

Şimdi gelin biraz daha farklı bir senaryoya gidelim :) Role'ümüz 9 instance. UpgradeDomainCount'u da 3 olarak ayarladık. FC de 3 Fault Domain düzenlemiş. Yine milyonda bir senaryosuna gidersek ve Upgrade esnasından farklı bir Rack'de hata oldu dersek, 9 instance'dan 4'e düşüyoruz. Cılkını çıkardığımın farkındayım :) Ama umarım genel perspektifi aktarabilmişimdir.

Görüşmek üzere ;)

Azure'da bir web veya worker role yarattığınız gibi Solution Explorer içerisindeki Azure projesinin altında Roles klasöründe role kendini gösterir. Peki Azure projesi içerisindeki bu diğer dosyaların anlamı ne? İşte şimdi bu soruyu cevaplayacağız :)

Solution Explorer'daki config dosyaları bize bakıyor...

Azure projenizi yarattığınız anda hemen bir csdef ve iki cscfg dosyası oluşturulacaktır. Şimdiden söyliyim :) buradaki CS'ler C# değil :) Yani VB ile proje yarattığınız vbdef falan olmuyor :) Buradaki CS'ler "Cloud Service" anlamına geliyor.

[ServiceDefiniton.csdef]

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject1" 
    xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="OrnekWebRole" vmsize="Small">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition>

Cloud çözümümüzde şu anda tek bir web role olduğunu düşünerek yukarıdaki CSDEF dosyasına baktığımızda ilk bakışta http80 üzerinden bir Endpoint olduğunu görebiliyoruz. CSDEF dosyasının açılımı "Cloud Service Definition" yani servisin ana yapısını tanımlayan bir dosyadan bahsediyoruz. O nedenle Endpoint'lerin burada listelenmesi çok mantıklı. Bunlar servisi tanımlayan ana öğeler, konfigürasyon değiller. XML içerisindeki dikkat etmemiz gereken ufak bir detay daha var, o da : vmsize=Small kısmı! Daha önceki yazılarda da bahsetmiştik Azure ortamında projenizi yayınlarken web role'ünüzü istediğiniz kadar sunucu / instance'a yayabilirsiniz ama bunu yaparken her bir instance'ın boyutunu da belirlemeniz gerekiyor.

Yukarıdaki tablodu güncel Instance Size bilgilerini bulabilirsiniz. Ayrıca daha detaylı bilgi için de Microsoft'un buradaki sitesini inceleyebilirsiniz. Özetle :) kaç instance alırken instance size'ı da vermeniz gerekiyor ve bu bilgi CSDEF'de bulunuyor.

[ServiceConfiguration.cscfg]

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureProject1" 
    xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
    osFamily="1" osVersion="*">
  <Role name="OrnekWebRole">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
            value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

CSCGF dosyalarının açılımı Cloud Service Configuration şeklinde. Bu dosyalardan varsayılan ayarlarda iki tane geliyor. Böylece kendi makinenizde test ederken local.cfg'yi azure'da deploy ederken de cloud.cfg'yi kullanabiliyorsunuz. İsterseniz farklı staging cfg dosyaları da yaratabilirsiniz.

Yukarıdaki XML dosyasında önemli olan birkaç nokta var. Birincisi Diagnostics ile ilgili connectionstring. Diagnostic bilgisi eğer ki kullanırsanız :) DiagnosticsAgent tarafından belirli aralıkla kalıcı veri saklama alanlarına (yani storage hesaplarına) aktarılabiliyor. Storage hesaplarının detaylarına ileride bakacağız. Storage hesaplarının kendilerine özel bir connectionstring'leri oluyor aynı SQL gibi. Şu an yukarıdaki XML'de gördüğünüz UseDevelopmentStorage=true connection string değeri developer makinesindeki storage emülatörünü kullanacağımız anlamına geliyor. Bu konunun detaylarına ileride bakacak olsak da şimdilik konuyu bilmekte fayda var.

CSCFG dosyası içerisindeki bir diğer önemli şey ise .... <Instances count="1" /> kısmı...Tahmin edebileceğiniz üzere Role başına kaç instance olacağı bilgisini buraya yazıyoruz. Şimdi tam da burada değinmemiz gereken önemli bir nokta var. Dikkat ettiyseniz Instance sayısını bir konfigürasyon olarak kabul edilirken instance size doğrudan CSDEF'de servisin tanımında yazılıydı. Bu da şu sonucu ortaya çıkarıyor :) Instance size değiştirmek isterseniz servisin yapısını değiştirmiş oluyorsunuz ve tüm instance'ların restart'ı şart oluyor. Instance size değiştirmek ise sadece konfigürasyon değişikliği olduğu için total bir role restart gerekmiyor.

Genel yaklaşım olarak ek konfigürasyon bilgileri hep CSCFG dosyalarına konur. Ama bunu yapabilmek için de öncesinde CSDEF'te söz konusu konfigürasyonun varlığını tanımlamanız gerekir. Nasıl mı?

Özel Konfigürasyonlar

Kendi özel konfigürasyon ayarlarınızı saklayabileceğiniz yerlerden biri CSCGF dosyası. Bu dosya içerisindeki konfigürasyon değerleri saklamak istiyorsanız ilk olarak CSDEF'te konfigürasyonun varlığını tanımlamalısınız.

[CSDEF]

  <WebRole name="WebRole1" vmsize="Small">
    <ConfigurationSettings>
      <Setting name="DataConnectionString" />
    </ConfigurationSettings>
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>

Yukarıda gördüğünüz örnek CSDEF'de servisin tanımına yeni bir konfigürasyon ihtiyacı eklemiş oluyoruz. Artık eğer bir CSCFG'de bu konfigürasyona dair değer / girdi bulunmaz ise proje kesinlikle build edilemeyecektir.

[CSCFG]

  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DataConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
        value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>

Aynı örneğin CSCFG kısmına baktığımızda ise eklediğimiz yeni ConnectionString değerine yine DevelopmentStorage değerini verdiğimizi görüyoruz. Bu gibi özel konfigürasyonları ister SQL connection string'i için ister başka ayarlar için kullanın. Olayın özü bu konfigürasyon dosyalarının uygulamadan tamamen ayrı tutulması ve konfigürasyondaki değişikliklerin uygulamada bir restart etkisi yaratmaması. Ha :) tabi eğer ki bir konfigürasyon değişikliği restart gerektiriyorsa onu da sizin tetiklemeniz veya belki de uygulama içerisinden config'in değişip değişmediğini takip edip gerekli uygulama içi değişiklikleri tetiklemeniz gerekecektir.

[C# / WebRole.cs]

RoleEnvironment.Changing += RoleEnvironmentChanging;

WebRole.CS'de OnStart'da Role'ün Changing eventine bir listener ataçlayıp değişiklikleri takip edebilir, onaylayabilir veya reddedebilirsiniz.

[C#]

private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
    if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))
    {
        e.Cancel = true;
    }
}

Yukarıdaki kod ile değişikliğin bir konfigürasyon değişikliği olup olmadığını kontrol edip kabul edip etmeyeceğimizi gibi kararları verebiliyoruz.

[C#]

RoleEnvironment.Changed += (s, arg) =>
{
    if (arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>()
        .Any((change) => (change.ConfigurationSettingName == "BirAyar")))
    {
        if (!configSetter(RoleEnvironment.GetConfigurationSettingValue("BirAyar")))
        {
            RoleEnvironment.RequestRecycle();
        }
    }
}

Değişiklik olduktan sonra ise :) isterseniz yukarıdaki gibi değişikliğin tipine göre farklı kararlar alabilirsiniz. Konfigürasyonlarla ilgili farklı senaryolarla ileride farklı konuları incelediğimizde karşılaşacağız. Şu an için tüm senaryoların üzerinden geçmek maalesef mümkün değil.

Peki bunun kolay yolu yok mu?

:) Bir yere kadar var. Azure projesi içerisinde Roles klasöründen herhangi bir Role'e çift tıklarsanız karşınıza tam da yukarıda bahsettiğimiz ayarların bazılarını düzenleyebilmenizi sağlayacak bir GUI gelecektir.

Visual Studio içerisinden konfigürasyonlar.

Yukarıdaki ekran görüntüsünde gördüklerimize hızlıca göz atalım. Bazları zaten eminim ki tanıdık gelecektir konfigürasyon dosyalarından :)

Full Trust / Partial Trust

Bu hikaye ilginç bir hikayedir :) Şimdi zaten varsayılan ayarlardan Full Trust geliyorda "Partial Trust" neden var ki? diyebilirsiniz. Aslında hikayeye Adem ile Havva'dan başlamak gerek :) Azure'un ilk zamanları... :) Daha Full Trust yok :) Şaka değil... Önceki yazılarda hep bahsettik, eğer bir WebRole alırsanız IIS var, Worker Role alırsanız yok dedik. Aslında verdiğim bilgi tam olarak doğru değildi :) Azure'un ilk zamanlarında hem Web hem Worker Role'lerde IIS yoktu. Onun yerine Microsoft tarafından sadece Azure için geliştirilmiş özel bir IIS Hosted Web Core içeren bir sunucu uygulaması vardı. Bu uygulamanın geliştirilmesindeki mantık FC Guest Agent ile IIS arasındaki iletişimi optimize etmek ve bu ikiliyi birbirine biraz daha yaklaştırmaktı. Fakat sonra insanlar IIS'in diğer özelliklerini istedikçe ve IIS Hosted Web Core full bir IIS desteği veremeyince Microsoft da "Full Trust" diye birşey çıkardı. Bu modda full IIS'iniz var ve makine üzerinde de her tür scripting hakkına sahipsiniz. Yani kod ile gidip IIS'e yeni bir http header vs ekleyebilirsiniz. İşte Full Trust ile Partial Trust arasındaki büyük farklılık bu ve default ayarlarda Full Trust geldiği için ben şu anda merak ediyorum kaç proje Partial Trust kullanıyor diye :) Bilmem mesajı doğru verebildim mi :)

Instance Count / VM Size

Sanırım bunlarla ilgili yeterine konuştuk. Daha fazla konuyu uzatmanın lüzumu yok :) Endpoint'leri de aynı şekilde direk geçeceğim. Hatta aynı şeyi Diagnostics için de yapıp konfigürasyon kısmını bitirdik diyeceğim :) Eğer konfigürasyon sayfasında "Settings" tabına geçerseniz oradan da ConnectionString gibi ayarları yapabildiğinizi görebilirsiniz. Endpoints tabında da eğer isterseniz özel endpointler tanımlanabilir. Örneğin bir worker role'ün http80 endpointi olmasa ,IIS'i olmasa da aslında gidip http80 endpointi ayarlayabilir ve belki de kendi datanızı stream edebilirsiniz :) Kulağa ilginç geliyor değil mi?

Konfigürasyon sayfasında diğer tablarla ilgili ilerleyen zamanlarda yeri geldikçe apayrı yazılar yazacağım için şimdilik oralara bulaşmıyorum ;) Bir sonraki yazıda görüşmek üzere!

Kendinize çok iyi bakın.

Çoğunuzun bu blogpost'a kızacağını biliyorum ama emin olun yapabileceğim birşey yoktu :( Bu Cumartesi günü Microsoft'ta sadece yazılım geliştirici iş ortaklarına özel bir Azure günü yaptık. Aslında "yaptık" dememeliyim çünkü organizasyonu malum Microsoft yaptı ben konuşmacı olarak katıldım. Çoğunuzun hafta sonu Azure aktivitesi beklediğini bildiğim için bu yazıyı çekinerek yazıyorum ama size söz hafta sonu azure aktivitemiz olacak, planlıyoruz.

Microsoft İş Ortakları'na Özel Azure Günü

Gün boyunca benim üç tane oturumum oldu, Azure'da ne nedir?, Storage servisleri ve SQL Azure konularına baktık. Günün başında Microsoft'tan Sarper Çelenk Microsoft tarafından iş ortakları fırsatlarına değinirken günün son oturumunda da Muammer Benzeş System Center ile Private/Public Cloud yönetiminden bahsetti.

Güzel bir gündü :) benim için de çok değerli oldu. Hiç aklıma gelmeyecek ilginç feedback'ler ve sorular aldım :) Katılan herkese çok teşekkürler, umarım herkes için faydalı olmuştur. Gün boyunca yaptığımız örnekleri aşağıdaki linkten indirebilirsiniz ;)

Azure Günü Örnek Kodlar - azure_ornekler.rar (19.8 MB)

Görüşmek üzere.

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...

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# 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 projesinden 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 400 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 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 :)

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 :) Üç 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ğiniz 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

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 kabul 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.

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 yeni yarattığınız bir Azure projesine eklemek isterseniz basit bir şekilde ASP.NET projesinin solution'a ekledikten sonra Azure projesindeki "Roles" klasörüne sağ tıklayarak aşağıdaki gibi ilerleyebilirsiniz.

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 :) Eğer elle bir ASP.NET projesini yukarıdaki gibi eklerseniz webrole.cs veya yazının başlarında bahsettiğimiz referanslar otomatik gelmeyecektir. Onları da elle eklemeniz gerekecek. Bu durumda zaten sadece kullanacağınız şeyleri ekleyerek ilerleyebilirsiniz.

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

Yine yılın o zamanı geldi :) Biliyorsunuz MVP'lik yıllık bir ünvan ve her yıl gönüllü yaptığımız katkılarla tekrar değerlendiriliyoruz. Bu sene de daha "Her Salı Azure Günü" serimize başlamadan yaklaşık iki ay önce hatırlarsanız MVP programı için raporumu hazırlamış ve göndermiştim. Değerlendirmenin sonucu dün belli oldu :) Microsoft 2012 yılı için bana Windows Azure çerçevesinde yaptıklarım için teşekkür etmek istemiş ve böylece ben de bu yıl için Windows Azure MVP'si oldum! Geriye dönüp baktığımıda son bir yılda 8 ülkede Azure anlatmışım :) Ben de pek farkında değildim açıkçası durumun :) ama şu çok net ki zamanımız neredeyse artık 100%'ünü Azure alıyor.

MVP Programında 5 Yıl

2010 yılında Microsoft artık her yıl ayrı ödül göndermek yerine :) halka göndermeye başladı MVP'lere :) yukarıdaki resim durumu açıklıyordur sanırım. Programda 5 yılımı tamamlayınca "5 Yıl Halka"mı da almış oldum :) Tabi bu da "zaman ne kadar hızlı geçmiş" etkisi yarattı bende. 2008'te ASP.NET MVP'si olarak girdiğim programda üç sene Silverlight MVP'si olarak yer aldım. Şimdi de Windows Azure... Bakalım gelecek neler getirecek.

Hepinize bu süreçteki desteğiniz için çok teşekkür ediyorum. Umarım blogdaki yazılar sizler için faydalı oluyordur. Gelin bu blog yazısının yorum kısmını da bir istek kutusu gibi kullanalım :) Varsa istekleriniz yazın ;)

Görüşmek üzere!