Azure Stack Lisans ve Fiyatlandırma​

Bu benim için gizemli soru dediğim konudur çünkü erkenden bilgiler edindiğimi söylebilirim. Fakat şu meşhur NDA durumuna uymak için, bu bilgiyi paylaşma hakkım ne yazık ki yok. Bahsedebileceğim şey, lisans verme modeli ne olursa olsun, bana kalırsa pahalı olacak ve SMB markete ulaşabileceğini düşünmüyorum. Hatırlatmakta fayda var. 3 adet farklı third-party var. Bunlar donanım sağlayıcısı, yazılım sağlayıcısı ve entegratörlerdi.

Sistem Entegratörleri Bütününün Hangi Parçasında Yer Alıyor ?​

Bu kendime sorduğum sorulardan biriydi. Windows Azure Pack ve Sistem Center gibi standart ürünlerin üzerinde, sistem entegratörleri neredeyse müşterilerin datacenter yapısı içerisine bu ürünleri başarılı bir şekilde deploy etmek zorundaydılar. Fakat yalnızca Azure Stack Bütünleşmiş bir sistem olacağından dolayı zihinlerde bir soru yükseldi. Sistem entegratörlerine artık ihtiyaç gözükmüyor gibi duruyor. Çözüm deploy etmeleri için daha fazla ihtiyaç yok. Bir çeşit tak ve çalıştır…

Bu doğru, fakat çok kötü değil( Meraklılar için durum böyle değil, ne yazık ki )

Aslında, Azure üzerindeki workloadlarını deploy etmek ve dizayn etmek için müşteriler bizleri çağırırken, bugün entegratörler müşterilerinizle ne yapıyor ? Kesinlikle mutlu olacaksınız, ve bu da Azure Stack hakkında konuşurken optimistik olmamız için en büyük neden. Çünkü Azure Stack datacenterınız üzerindeki Azure, ( bir Azure kapalı siyah kutu ) müşteriler ilk olarak satın almak için hangi Azure Stack teklifin kabul etme konusunda karar verecek ve sonra ikinci olarak Azure Stack'i bugün Azure kullandıkları şekilde kullanmaları için size ihtiyaçları olacaktır. Bu kısımda tutarlılık ve deneyim sizin Azure hakkındaki uzmanlık görüşünüzü yerel sahada oldukça sizi farklı kılacaktır..

Özleyeceğimiz şey ise, biraz alıştırma yapmak için Azure Stack platformunun üzerinde ellerimizin olmamasıdır. Ama, teorik olarak, bu pek çok hedefe ulaşmak için büyük problem olmayacaktır. Topluluk için baş ağrısına yol açan neden ise, evde lab üzerinde 1 node PoC ortamı deploy etmemiz neredeyse imkansız oluşudur. Technical Preview sürümüne sahip olan Azure Stack' için önerilen minumum Ram 96 Gb ve bütün servisleri deploy etme ve LAB'dan keyif almaya başlamak için 128 Gb olmasını beklemek gerekiyor. Evde 128 Gb Ram gücünde bir sunucuya sahip olmak konusunda çok bir fikrim yok.

Azure Stack TimeLine tablosunu aşağıda bulabilirsiniz.

CSP Azure Stack'ten faydalanabilir mi ?​

Henüz her şey net değil ve Microsoft Azure Stack ile Cloud Solution Provider etkileşiminden temiz bir görüntü yayınlamadı. Ama CSP programı aracılığıyla rahatça söylenebilir ki CSP Azure Stack'i spesifik Azure özelliklerini sunmak için kullanabilecek. Azure Stack'i kullanarak CSP formunu yavaşlatan en büyük faktörler :

1. Locked-Hardware (donanım sağlayıcıları): Cloud Solution Provider donanım sağlayıcılarıyla donanım satın alırken indirim ve avantajlarını edinmek için mutlaka işbirliği yapmak durumunda kalacaklar. Bu faktöre göz atarken oldukça kötümserim. CSP başka bulut platform çözümüne ihtiyaç duyabilir veya kendi kendine inşa etmeye devam edebilir. Bu faktörle ilgili çok kötümserim.
2. Lisans Verme ve Ücretlendirme: Locked-Hardware durumu söz konusu olduğundan CSP'nin üretebileceği kar marjını etkileyebilir.

Azure Stack ve Uygulanması Modeli Hakkında Ne Düşünüyorum ?​

Microsoft oldukça büyük bir firma, usta zihinler her gün ürünlerini geliştiriyor, yeni teknolojiler ve yaklaşımlar yaratıyor, farklılaşıyor ve kendi iş modellerini marketi etkilemek için değiştiriyorlar. Ama, hiçbir insan kurşun geçirmez değil. Microsoft hatalar yapabilir ve düşüş yaşayabilir.( Windows Phone durumunda olduğu gibi, korkunç bir şekilde gelişmiyor.) Azure Stack ile birlikte dramatik bir şekilde iş modelini değiştiriyorlar.

Ben gerçekten merakla hangi müşteri segmentini hedeflendiğini görebilmek için lisans verme anonsunu bekliyorum. Ama bunu yanında müşterinin vereceği reaksiyon içinde beklemekteyim. Gerçekten nasıl davranacakları hakkında en ufak bir fikrim yok. Benim ilk tahminlerim modelin topluluğun ve benim tarafından pek hoş karşılanmayacağını söyleyebilirim. Bütünleşmiş Sistem Platformlarına ( Locked-Hardware durumuna ) karşı değilim ancak sanallaştırma ve bulut konusunda erken hedeflerle ilgili zihnimde soru işaretleri var. Donanımın tekrar kullanılması ve maliyeti düşürme bunların başında geliyor. Azure Stack bu hedeflere uymuyor, seçebildiğimiz donanımların üzerinde kısıtlamalar yapabilmenin yanı sıra içimde Azure Stack dönemiyle ilgili büyük bir heyecanla karışmış kötü hislerim var. Umarım bir şekilde cevaplarını bulur ve aktarırım.

Kendi fikirlerimden oluşmuş Azure Stack'in iyi ve kötü tarafları :​

İyi Özellikleri​

Veri Merkezinizde Azure Servisleri : Azure Stack ile ilgili heyecan veren en büyük şey, veri merkezinize Azure özelliklerini ( IaaS,PaaS..) getirebiliyorsunuz. Elinizde test edilmiş en güncel bulut teknolojiler olacak. Gerçekten kulağa çok hoş geliyor. Eğer kamu bulut platformlarından herhangi bir nedenden dolayı kaçınıyorsanız (Gizlilik,Kısıtlı Kurallar,Güven) ama aynı zamanda sağlanan özellikleri kullanmayı diliyorsanız, Azure Stack tam size göre.

Tak ve Oyna Modeli : Bütünleşmiş Sistem modeli kullanmaya hazır özel bulut platformu getirerek TCO'yu azaltacak.

Hybird Bulut Platformu : Platform arası tutarlılık garantilendiğinden Azure Stack müşteri kullanımı veya planlanması için gerçekten bir avantaj. Aynı yaklaşımları, dizayn karar faktörlerini, araçları, scriptleri ve özellikleri kullanabilirsiniz.Artık daha fazla on-premise platformu ve kendi bulutunuzu yönetmek için farklı iki modele ihtiyaç duymayacaksınız, böylelikle önemli bir ölçüde gerçek iş kaygılarına harcanacak IT eforlarını azaltacak.(Uygulamaları deploy etmek, göç, geliştirmek…)

Kötü Özellikleri​

Bütünleşmiş Modelin Diğer Tarafı : Donanımı kitlemek asla iyi bir fikir değildi,müşteriyi donanım sağlayıcısını özgürce seçmekten mahrum ediyor ve böylelikle ücretleri daha iyi kontrol ediyordu. Bu model erken edinme durumundan dolayı marketi azaltacak ve böylelikle hızlı yayılabilecekken gidişatını kötü etkileyecek.

Peakup olarak üniversitelerde verdiğimiz seminerlerin Eskişehir Üniversitesi ayağındaydık. Ezgi Can ve Fatih Doğan arkadaşlarımla birlikte katıldığımız seminerde gün boyunca Microsoft Cloud Vision - Big Data - IoT teknolojilerinden bahsettik. Keyifli bir organizasyon oldu. Katılım gösteren öğrenci arkadaşlarımıza teşekkür ediyorum.

Azure Resource Manager dağıtım modelinde en çok karşılaştığım ve çok fazla tepki aldığım konulardan bir tanesi için geliştirdiğim Powershell Fonksiyonunu paylaşmak istiyorum. Bu fonksiyon sayesinde artık bağlandığınız Subscription üzerindeki bulunan Resource Group'ların içerisinde herhangi bir kaynak yok ise sizin için bu script temizliyor olacak.

Öncelikle Azure Resource Manager modülünün kurulu olduğunu emin olduktan sonra yapmanız gereken Azure Powershell üzerinde "Login-AzureRmAccount" cmdlet çalıştırıp oturum açalım.

Başarılı bir şekilde Azure hesabınızı girdikten sonra artık geliştirdiğim Powershell Fonksiyonunun kullanmaya geldi. İlgili fonskiyon Powershell session içerisine import edildikten sonra yapmanız gereken sadece fonksiyonu çağırmak.

Yukarıda fonksiyon detaylarını görebilirsiniz. Fonksiyon çağırıldığı zaman tüm Resource Group'lar çağrılır ve içerisindeki kaynak sayıları kontrol edilerek herhangi bir kaynak olmayan Resource Group'lar tek tek silinmeye başlar.

Fonksiyon çağrıldığı zaman karşınıza subscription detayları gelecektir. Bu detaylar içerisinden işlem yapmak istediğiniz hesabı seçtikten sonra kaynak olmayan Resource Group'ların temizlenmesi başlayacaktır.

function Remove-AzureEmptyResourceGroup { $SelectSubs = Get-AzureRmSubscription | Out-GridView -PassThru Select-AzureRmSubscription -SubscriptionId $SelectSubs.SubscriptionId | Out-Null Write-Host "Select default subscription is" $SelectSubs.SubscriptionName -ForegroundColor Green $RGs = Get-AzureRMResourceGroup foreach($resourceGroup in $Rgs){ $name= $resourceGroup.ResourceGroupName; $count = (Get-AzureRmResource | where { $_.ResourceGroupName -match $name }).Count; if($count -eq 0){ Write-Host "The resource group $name has $count resources. Deleting it..." ` -ForegroundColor Red -BackgroundColor White Remove-AzureRmResourceGroup -Name $name -Force -Verbose; } else{ Write-Host "The resource group $name has $count resources" ` -ForegroundColor Blue -BackgroundColor White } } }

Service Manager Azure VM'ler için, Classic Portal içerisinde sekme üzerinden kullanım ve kota limitlerini kontrol ve gözlemleyebilirsiniz. Ancak, ARM için klasik veya yeni portal yoluyla mümkün değildir. Kullanımı ve aboneliğiniz için o anda ayarlanmış olan eşikleri denetlemenin tek yolu, Azure PowerShell'i kullanmanız gerekir. Azure PowerShell modülünü buradan indirebilirsiniz. Öncelikle bu kontrol işlemine Classic Portal üzerinden nereden baktığımızı hatırlayalım.

Öncelikle bu limitleri neden kontrol ve gözlemlememiz gerektiğini kısa cümleler ile açıklayayım. Bunların başında Azure Subscription içerisinde limitler oldukça önemsiz gözükmüş olsa da şimdi bir senaryo ile anlatmaya çalışacağım. Öncelikle Usage limitlerini nasıl göreceğimizi adım adım anlayalım.

Powershell üzerinde Resource Manager dağıtım modeli için oturum açalım.

Powershell ile oturum açma işleminden sonra işlem yapmak istediğiniz subscription seçmeyi atlamayalım. Benim girdiğim hesap içerisinde birden fazla subscription var. Bunu atlamamanızı öneririm. Bkz "Select-AzureRSubscription".Kullanacağımız cmdlet dizisi aşağıdaki gibidir.

Artık Powershell ile işlem yapmak istediğiniz Azure Resource Manager Subscription seçtik. Bir sonraki yazımızda ARM için Usage raporları veren cmdletleri tanıyıp çalıştırmaya çalışacağız.

• Get-AzureRMVMUsage -Location "Kontrol etmek istediğiniz Datacenter lokasyonunun adını yazınız." Örn – West Europe
• Get-AzureRMStorageUsage

Öncelikle Resource Manager modelindeki sanal makineler için usage limit kontrolü gerçekleştirelim.

Powershell ile işlem yapmak istediğiniz Azure Resource Manager Subscription seçtik. Artık Azure Resource Manager için Usage ve Kota çıktılarını veren cmdletleri tanıyıp çalıştırmaya çalışacağız.

• Get-AzureRMVMUsage -Location "Kontrol etmek istediğiniz Datacenter lokasyonunun adını yazınız." Örn – West Europe
• Get-AzureRMStorageUsage

Öncelikle Resource Manager modelindeki sanal makineler için usage ve kota limit kontrolü gerçekleştirelim.

"Get-AzureRMVMUsage" cmdlet içerisine "-Location" parametresini göndererek ve karşına sorgulamak istediğimiz DataCenter adınız yazdım. Bu kısımda önemli noktalara değinmek istiyorum. Bildiğiniz gibi Azure üzerinde sanal makine serileri var. Bu serilere göre donanım, disk, cpu gibi değeleri değişiyor. Yukarıdaki çıktıda serilere göre aboneliğinizin içerisindeki limitleri görebilirsiniz. Görmekte olduğunuz Sanal sunucularınız için Core limitleridir.

Bu kısımda dikkat edilmesi gereken nokta, bu limitleri kontrol etmediğinizi varsayarsak örneğin altyapınız gereği bir kaynaklarınızı scale up ederek CPU limitlini attırmak istediğinizi varsayalım. Bu komut size kaynaklarınızın bulunduğu lokasyon için sanal sunucu oluştururken Core sayısını belirtiyor. Neden böyle bir limit var diye düşünenler olabilir hemen bunuda açıklayalım. Microsoft kaynak planlanmasını hayal edin, her abone olan kişi kafasına göre kaynak yaratabilseydi resource yönetimi ne kadar zor olacaktı. Aslında bununla Microsoft bir nebze resource yönetimini planlıyor.

Birde bunun Storage Account tarafı var ama ben bu kısımla pek karşılaşmadım çünkü zaten default olarak yeterli bir limit tanımlı bence, zaten cloud tarafında storage account hizmetinin bir limiti olması Microsoft tarafından resource yönetmeyi zorlaştıracağını düşünmüyorum. Burada önemli kısım çalıştırdığınız sanal sunucularınızın Core sayılarından ibaret olduğunu unutmayın.

"Get-AzureRMStorageUsage" cmdlet size Storage Account limitlerinizi gösterecektir.

Yazımızda Azure Resource Manager limitlerinin öneminden bahsettik. Bu limitlerin önemini kaynaklarınızı scale up ederken veya farklı bir subscription içersine geçişler yaparken kesinlikle karşılacaksınız. Onun için Support sayfası üzerinden Microsoft tarafına ticket açarak 1-2 gün içerisinde arttırılmasını sağlayabilirsiniz. Yine kendi tecrübemden aktarmak istediğim bu Case açma sürecini hafta sonuna getirmeyin çünkü o ekip hafta sonu çalışmıyor.

Yazımızın ilk ve ikinci bölümünde Fonksiyon kullanımın önemini, kullanım şeklini ve basit bir örnek yaparak anlatmaya çalıştık. Birkaç farklı örnek ile fonksiyonları anlayama devam edelim. Yine örnekler üzerinden kolayca ilerlemeye çalışalım. Geliştireceğimiz bu seferki fonksiyonda artık parametreler ile çalışmayı öğrenelim.

• Fonksiyon Adı : Verb-Noun ilişkisi – Get-ComputerInformation
• Parametre : Bilgisayar adını argument olarak göndermeye çalışalım.
• Script Block : 'Get-WMIObject' cmdlet'i ile ilgili class yapısı kullanılarak istenilen sorguları yazalım.

Yukarıdaki görüntüde görüldüğü gibi fonksiyonumuzun adı "Get-ComputerInformation" olarak belirlenmiş durumda gözlemleniyor. Bu fonksiyonun adında da anlaşılacağı gibi çalıştırıldığı zaman bilgisayarınız hakkında bir takım bilgiler vermesini gerekiyor.

Fonksiyon içerisinde yazılan satırları sırasıyla inceliyeylim. "Get-WMIObject" cmdlet 3 farklı şekilde kullanımı göreceksiniz. Bunların sebebi bu cmdlet içerisine farklı 'WMI Class' gönderiminden kaynaklanıyor. WMI Class diğer bir özelliği ise işletim sistemi içerisinde çok fazla class olmasına rağmen isimlerinden tam olarak ne yaptığını anlamanız mümkün gözüküyor. Cmdlet kullanımına dikkat ederseniz, "-ComputerName" parametresi sayesinde herhangi bir makineye DCOM protokolleri üzerinden remote makineye sorgular yapabilirsiniz.

Yukarıdaki fonksiyonu çalıştırdığınız zaman çalıştırdığınız "-ComputerName" parametresi karşına girilen makine adı hakkında WMI sorguları gerçekleşecektir. Bu örnekte kendi makine ismimi vererek ilgili fonksiyonun çalıştırılmasını sağladım.

Görüldüğü gibi fonksiyon çağrıldığı zaman WMI Sorguları çalışıyor ve "ComputerName" parametresine girilen değer doğrultusunda sorgular gerçekleşiyor. Fonksiyonu incelediğiniz zaman "ComputerName" parametresinin karşına alacağı değer değişebilir olduğunu fark edebilirsiniz. Bunun için çok fonksiyonumuza parametre tanıtalım ve nelerin değiştiğini görelim.

Zamanı geldiğini düşünüyorum artık!. Fonksiyonumuzun içerisine İlk Parametre tanıtımı gerçekleştirdik. Param ile başlayan, parantez açıp içerisine değişken tipini ve değişken adını tanıttıktan sonra parantezi kapatıp tanımlamayı gerçekleştirdik. Daha sonra fonksiyon içerisine gönderilen parametrenin "Get-WMIObject" cmdlet içerisinde kullandığını yukarıda görebilirsiniz. Burada temel amaç fonksiyon içerisine gönderilen parametre sayesinde fonksiyonun istenilen kısmında kullanılmasını sağlamaktır.

Bir sonraki yazımızda tanımadığımız parametrenin kullanımının detayına bakıyor olacağız.

Bu yazı serisinde Sistem Yöneticilerin işini kolaylaştıran Powershell'in, kendisini bu yönde geliştirmek isteyen kişiler için Powershell Function kullanımına değinilecektir. Diğer yazılım dillerinden aşina olunan ve karmaşık scriptleri basitleştiren bir yöntem olan fonksiyon kullanımının ne kadar kolay bir mantık içerisinde olduğunu anladıktan sonra kullanım oranınız o yönde artacaktır. Herhangi bir yazılım dilinde ya da PowerShell içerisinde fonksiyon kullanımını gören bir sistem yöneticisi başlangıçta karmaşıklıktan şikâyet edebilir, fonksiyon kullanımını gereksiz, zor, işleri daha da karıştıran bir yol olarak görebilir. Ancak sistem üzerinde gerçekleştireceğiniz günlük işlerinizi PowerShell yardımı ile otomatize etmeye başladıkça fonksiyon kullanımının hayat kurtarıcı bir yol olduğunu fark edeceksiniz.

Yukarıdaki Kullanım Biçimi bilgisinde görüldüğü gibi herhangi bir fonksiyonu oluşturmak için Function anahtar kelimesi ile başlanması gerekmektedir. PowerShell içerisinde girilen bu anahtar kelime ile Powershell artık bir fonksiyon oluşturma aşamasında olduğunu anlayacak ve fonksiyon ismi bilgisinin girilmesini bekleyecektir.

FonksiyonAdı : Script içerisinde sınırları belirlenmek istenen kod bloğuna verilecek isimdir. Bu noktada ilgili kod bloğunu anlaşılır biçimde tanımlayacak isimler verilmesi, fonksiyonun karmaşık scriptlerde kullanılmasını kolaylaştıracaktır. Powershell cmdlet isimlendirme mimarisine dikkat ettiğinizde "Verb-Noun" şeklinde görüyor olacaksınız. Aynı şekilde geliştirdiğiniz tüm Fonksiyonları bu şekilde tasarlanmasına dikkat etmenizi öneririm.

Parametreler : Seçeneğe bağlı olarak fonksiyonlar ile birlikte kullanılabilir. Herhangi bir parametreye sahip olmayan bir fonksiyon oluşturulduğunda yalnızca fonksiyon isminin kullanılması ilgili kod bloğunun olduğu gibi çalıştırılmasını sağlayacaktır. Örneğin statik bir ip numarasının pinglenmesi için bir fonksiyon yazılabilir. Böylece yalnızca fonksiyonun ismi PowerShell konsolunda girilerek ilgili ip'nin pinglenmesi sağlanabilir. Ancak parametre kullanımı ile fonksiyon içerisinde kullanılan ip numarasına bir değişken atanır ve fonksiyon bu parametre ile çalıştırılabilir. Böylece ping işlemini gerçekleştirecek fonksiyon vX ve ardından ip numarası yazılarak istenilen ip numarasına ping atılabilir.

Script Bloğu : Fonksiyon içerisinde kullanılmak istenen kodları barındıran bölümdür. Fonksiyon oluşturulurken köşeli parantez içerisine yerleştirilen tüm değerler, fonksiyon ismi çağrıldığında parametreleri ile birlikte çalıştırılacaktır.

Powershell Function mimarisi kendi içinde "Standart" ve "Advanced" olarak iki kısıma ayrılmaktadır. Yazımızın ilerleyen kısımlarında bunların farklarından söz edilecektir. Basit bir örnek ile fonksiyon oluşturmaya başlayalım. Örneğimiz gereği, "C:\WorkFolders" altında aşağıdaki dosyalar gözükmekte ve bunların farklı boyutları bulunmaktadır.

Bu klasör içerisinde bulunan dosyaların boyutları "1MB" fazla olanlarının ekrana listelenmesini sağlayan bir fonskiyon geliştirelim ve "Script Block" içerisine yazmamız gereken adımları tasarlayamaya hemen başlayalım.

Fonksiyon Adı : "Get-FileSize" – Verb-Noun ilişkisini unutmayalım. Parametre : Kullanımı yok. Script Block : Powershell içerisinde "Get-ChildItem veya alias olan 'dir' komutları sayesinde belirtiğiniz klasör yolundaki tüm dosyaların boyutlarını listeme şansınız var. Bu boyutları görüntülenmesini sağladıktan sonra "Where-Object" cmdlet sayesind gerekli filtreleme yaparak istediğimiz sonuca ulaşalım.

Powershell Console üzerinde gerekli session içerisinde çalıştıralım ve sonucu görelim.Daha sonra console üzerinde "Get-FileSize" yazarak geliştirdiğimiz fonksiyonu çağıralım.

İlk adımımız olan "Function ve Script Block" kısımlarını yazarak ve Fonksiyonun o an çalışan Powershell Session içerisine aktarılmasını bir kez çalıştırarak sağlamış bulunuyoruz. Örneğimizin ilk adımı olan dosyaları listelemeyi tamamladık fakat, filtre yaparak "1MB"'dan büyük olanların gelmesini sağlayalım.

"Where-Object" cmdlet kullanarak 'Length' niteliğine göre filtrelememizi gerçekleştirdik. Gördülüğü gibi '-gt' operatörü bize büyüktür anlamını ifade ediyor. Powershell diğer bir güzel kısmı "KB,MB,GB" şeklinde girilen değerleri otomatik olarak algılayabiliyor.

Yukarıda görüldüğü gibi, "Get-FileSize" isimli fonskiyonumuzu başarı bir şekilde geliştirdik ve örnek içindeki istediğimiz senaryoya ulaştık. Belirtiğimiz filtre sayesinde Powershell Console üzerine ilgili klasör yolu üzerindeki dosyaların 1MB büyük olanarın ekranda gözükmesini sağladık.

Yazımızın diğer aşamalarında biraz daha farklı örneklere, derinlere ve özellikle günümüz süreçlerinden konuşuyor olacağım.

Yazımızın ilk bölümünde Fonksiyon kullanımın önemini, kullanım şeklini ve basit bir örnek yaparak anlatmaya çalıştık. Birkaç farklı örnek ile fonksiyonları anlayama devam edelim. Yine örnekler üzerinden kolayca ilerlemeye çalışalım. Geliştireceğimiz örneğin amacı verdiğiniz tarihin yılın kaçıncı günü olduğunu Powershell Console üzerine yazdırması olsun. Öncelikle yapmamız gerekenleri hemen özetliyoruz.

• Fonksiyon Adı : Verb-Noun ilişkisi
• Parametre : Henüz kullanımı yok. İstebilirse tarih parametre olarak gönderilebilir.
• Script Block : 'Get-Date' cmdlet'i içerisinde bulunan 'DayOfYear' methodu ile kolay bir şekilde gönderilen tarihin yılın kaçıncı günü olduğunu anlamak mümkün.

Fonksiyon oluşturmak için hemen ismiyle başlayalım.

'Return-DayOfYear' isimli function anahtar kelimesiyle başlayan satırımızı ve süslü parantezlerimizi koyarak fonksiyonu oluşturmayı başardık. Süslü parantezler içerisine ( Script Block ) kısmına artık fonksiyonun yapması gerekenleri yazmamız gerekiyor.

'Get-Date' cmdlet içerisne istediğim tarihi yazdım ve dikkat ederseniz parantez içerisine alıp 'DayOfYear' methodunu çağırmayı başardım. Cmdlet altındaki methodları parantez içerisine alarak görme şansınız var.(Get-Member incelenebilir.) Daha sonra Powershell Console ekranına Yılın kaçıncı günü olduğu bilgisi kolay bir şekilde yazacaktır. Bu sayede sizde bu basit fonksiyonu raporlar yaparken ufak notlar almak için kullanabilirsiniz.

Ufak bir hatırlatma yapalım, geliştirilen fonksiyonların Powershell'in anlayabilmesi için session içerisine aktarılması yani çalıştırılması gerekiyor. Powershell içerisine tanıtımı yapıldıktan sonra o session boyunca kullanıma devam eder ve Powershell Drive içerisinde 'Function Drive' içerisinde saklanır. Geliştirdiğiniz fonksiyonların her Powershell Session içerisinde kalması için yapılması gereken birkaç yöntemler bulunmaktadır. Bunlar yazımızın ilerleyen kısımlarında açıklıyor olacağım.

Powershell Drive içerisinden fonksiyonların görünümü aşağıdaki gibidir.

Function drive içerisine girdikten sonra geliştirdiğiniz fonksiyonlar burada saklanmaktadır.

Fonksiyonların kaldırılması için ilgili PowerShell oturumunun kapatılması sağlanabilir. PowerShell konsolundan ya da çalıştırılan script içerisinden çıkıldığında fonksiyon ve fonksiyona atanan değerler kaldırılacaktır. Ayrıca Del komutu kullanılarak ilgili fonksiyon aynı oturum içerisinde silinebilir. Aşağıdaki örnek üzerinden bunu gerçekleştirebilirsiniz.

Azure Resource Manager ile artık bildiğiniz gibi Role-Based Access Control, Resource Lock, Resource Tag ve Billing vd yönetimsel ihtiyaçlarımızı karşılamaktadır. Resource Manager Policy, isteğe bağlı olarak yazılan özel politikalar yoluyla erişimini kontrol etmenizi sağlar. Geliştirdiğiniz bu politikalar ile, kurumun kaynaklarını yönetmek için gerekli olan kuralları yazabilir ve kullanıcıların yapabileceği hataları önleyebilirsiniz.

Özellikle organizasyon içerisinde istenmeyen eylemleri veya kaynakları tanımlayan politikalar oluşturmak istenebilir.Tanımladığınız politikaları subscription, resource group veya resource bazında istenilen kapsamda atayabilirsiniz. Bu makalede, size politika oluşturmak için kullanabileceğiniz politika oluşturmak için gerekli dilinin temel yapısını açıklayıp sonra farklı kapsamlarda bu politikaları uygulamak ve bazı örnekler göstereceğim.

Resource Manager ile Policy Management arasındaki farkı iyi anlamak gerekli. Resource Manager hali hazırda bizlere zaten role-base access control yaptırabiliyor. Fakat biz biraz daha yönetimi derinleştirmek istiyoruz. Örnek olarak "Engin" kullanıcısına Azure Subscription içerisinde belirli bir Resource Group için yetki verdiniz. Buraya kadar herşey istediğiniz gibi gidiyor. Eğer biraz daha derinleşmek isterseniz, örnek olarak Resource Group içerisine kaynak yaratsın ama sadece sizin belirlemiş olduğunuz "Azure Datacenter" lokasyonunda veya belirlediğiniz kaynakları örn: " Storage Account, VM , SQL" sadece bu hizmetleri oluşturabilsin deme şansına sahip olabiliyorsunuz. Benzer şekilde, Azure içerisinde bulunan hizmet katalog yapısını kontrol etmek veya kaynaklar için istenen adlandırma kurallarına zorlayabilirsiniz.Örneğin sadece Virtual Machine oluşturabilsin fakat size olarak "D2" şeklinde belirtme şansınız var.

Policy Defination structure​

Policy tanımı yaparken JSON söz dizimi kullanılarak oluşturulur. Eylemler ve koşullar yerine getirildiğinde ne yapması gerektiğini söyleyen bir tanımlama veya mantıksal operatorler kullanılır.

Temelde, bir policy aşağıdaki kısımlardan oluşmaktadır.

Condition/Logical operators : Belirlediğiniz koşulları mantıksal operatorler ile manipüle edebilirsiniz. Bunlar "Not"," And"," Or" olarak çağrılır.

Effect: - Bu kısım önemli belirlediğiniz koşul yerine geldiği zaman ne olacağını açıklar. Effect olarak alabilecek değerler aşağıdaki gibidir.

• "Deny" değeri verilir ise yapılacak aksiyon hem audit edilir ve hemde işlem gerçekleşmez.
• "Audit" değerli verilir ise yapılacak aksiyon audit edilir, fakat işlem gerçekleşir.
• "Append" değeri koşul içerisinde yer alan kaynaklara izin verir.

Aşağıdaki örnekte örnek bir JSON Policy Template görebilirsiniz.

Bu örnekte söz dizimi biraz inceleyelim."JsonPolicy" adında bir değişken oluşturulmuş ve JSON içerisine condition ve effect tanımlamaları yapılmış durumdadır.Template içerisinde "North-Europe ve West-Europe" lokasyonlarında yapılacak işlemleri için bir durum belirtilmiş. Bu durum kısmı ise "Effect" alanına "Deny" değeri verilmiş gözüküyor. Özetle eğer bu lokasyonlarda dışında oluşturulacak kaynaklar için işlemler başarsız bir şekilde olacaktır ve audit edilebilme şansımız olacaktır.(Template içinde bulunan "in" kısmına dikkat ediniz!) JSON Template içeriğini Powershell ISE üzerinde geliştirdim. Sebebi ise bir değişken atayıp script içinde ilerleyen kısımlarında kullanabilmek içindir. Visual Studio ile yazmış olsaydınız yada başka bir araç ile JSON file çağırıp değişkene atamanız yeterli olacaktı.

Yukarıda yazmış olduğumuz "Policy" tanımını AzureRM Powershell Modulü içerisinde bulunan "New-AzureRmPolicyDefinition" isimli cmdlet ile gerçekleştirebiliyoruz. Bu cmdlet bir takım parametreler alır ve bunlar aşağıdaki gibidir.

• -Name : Oluşturulmak istenilen policy adıdır.
• -Description : Tanımlanan policy için açıklama girilir ve daha sonra bakıldığında hatırlatma için fikir verebilir.
• -Policy : Bu parametre geliştirdiğiniz JSON template detayını gönderilecek olan kısımdır. Dilenirse yukarıda bulunan resimdeki variable gönderilebilir veya bir path üzerinde bulunan JSON yolu ifade edilebilir.

"New-AzureRMPolicyDefinition" cmdlet'inin resim içerisinde kullanımı bulabilirsiniz. Eğer geliştirdiğiniz Policy tanımlamalarında sıkıntı yok ise başarılı bir şekilde oluşturulacaktır. "Name" parametresine policy adı olarak "regionPolicy" İsimini verdik.

Policy oluşturuldu. Artık bu policy bir kaynak grubuna atamasını gerçekleştirelim. Yazmış olduğumuz politikayı Resource Group içerisinde oluşacak kaynaklar için atamasını yapalım. Atama işlemi için portal üzerinde herhangi bir Resource Group'un bir ResourceId'si bulunmaktadır. Bunu çok kolay bir şekilde Portal arayüzünden görebilirsiniz. Dilerseniz benim gibi aşağıdaki cmdlet yardımıyla Resource Id'si bulabilirsiniz.

"Get-AzureRMResourceGroup" cmdlet sayesinde -Name parametresine "Resource Group" adını göndererek ResourceId değerini döndürdük. Bu değeri policy ilgili Resource atarken kullanıyor olacağız.

Bir önceki yazımızda Resource Group için gerekli ResourceId bilgisini öğrenmiştik. Bu işlemi Portal üzerinden yapmak için aşağıdaki detaylardan yararlanabilirsiniz.

Resource Id değerini farklı yöntemler ile bulduktan sonra artık oluşturduğumuz policy atama işlemine geçebiliriz. Atama işlemini gerçekleştirecek cmdlet "New-AzureRmPolicyAssignment" olarak karşımıza çıkmaktadır. Bu cmdlet bir takım parametreler alır ve bunların detayları aşağıdaki gibidir.

• -Name : Atanacak policy için bir Assignment adı verilir.
• -PolicyDefinition: Tanımlanan policyler bu parametre içerisine gönderilir. Böylece Assignment gerçekleşir, kısaca her Assignment yapıldığında bir Policy tanımlamasının parametre içerisine gönderilmesi gerekiyor.
• -Scope : Bu parametre ile kapsam detayı belirtilir.( Resource Group, Subscription, Resource ) Öğrenilen ResourceId kısmı bu parametre içerisine gönderilir. // ResourceId şeklinde gönderilmelidir.

Policy atamasını sağlayacak cmdlet kullanımına geçelim.

Yukarıda çalıştırılan Powershell cmdlet detaylarını açıkladım. Fakat kısaca yine üzerinden geçecek olur isek, bir önceki yazımızda JSON template içerisinden oluşturduğumuz Policy tanımlamasını "Get-AzreRMPolicyDefinition" cmdlet ile çağırıp "regionPolicy" adında bir değişkene atadım. "New-AzureRMPolicyAssignment" cmdlet içinde bulunan "PolicyDefinition" parametresine "$regionPolicy" olarak gönderdim ve Powershell Console üzerinde başarılı bir şekilde atamanın gerçekleştiğini görebilirsiniz.

Bildiğiniz gibi bizim JSON Template içinde "West ve North Europe" datacenter dışında kaynak oluşturulursa "deny" verilmesini belirtmiştik. Bununla ilgili Policy oluşturduk ve Assignment sürecinide tamamladık, artık çalışıp çalışmadığını kontrol edelim.Çok basit bir şekilde "Storage Account" oluşturuyorum. Bunun adını "regionpolicy" olarak belirleyip Region olarak "Central US" seçmiş bulunmaktayım.

"Create" butonuna tıklayarak, Storage Account oluşturma işlemini başlattık. Oluşturduğumuz Resource Group bizim Policy ataması yaptığımız olduğunu dikkat etmeyi unutmaylaım.

Yukarıda görüldüğü gibi yazmış olduğumuz Policy başarılı olduğunu görmekteyiz. Aldığımız hatalara bakıldığı zaman Policy tanımlaması yüzünden ilgili kaynak oluşturulamadığını ve hangi Policy üzerinden geldiğini açıklamış gözüküyor. Herşey istediğimiz gibi fakat bu sizin delegasyon yaptığınız kullanıcının ekranına yansıyan hatadır. Daha sonra biz bunu görüntülemek isteyebiliriz. Bu süreci kim, ne zaman ve neden hata almış gibi denetleme yapma şansımız var. Bunun için yardımınıza "Policy Audit Events" grubuna dahil olan Powershell cmdletler koşuyor olucak.

Policy Audit Events

Eğer kuralını uyguladıktan sonra, politikaların kimlere uygulandığını ve ne sebepte kaynaklandığını görebilirsiniz. Bu verileri almak için PowerShell veya Azure CLI kullanmanız gerekiyor. Powershell ile yapmak istediğimiz zaman yardımınıza "Get-AzureRmLog" adında cmdlet yetişiyor olacak. Bu cmdlet size Azure Resource Manager içerisine düşen log detaylarını getirmektedir.

Yukarıda kullandığımız cmdlet içerisinde bir filter işlemi gerçekleştirdik. "OperetaionName" değeri eğer ""Microsoft.Authorization/policies/deny/action"" eşit olanları getirmesini istedik. Bu sayede sadece işlem yapan kişilerde "deny" durumu oluşan log detaylarını ekranda görmemizi sağladı. İsterseniz bunu tüm audit loglar gelsin şeklinde değiştirme şansına sahipsiniz. Yapmanız gereken sadece OperationName karşına girdiğimiz değeri şu şekilde ""Microsoft.Authorization/policies/audit/action" değiştirmeniz olacaktır. Bununla beraber Azure Resource Manager içerisinde tüm policy ile gelen tüm logları audit etmenizi sağlayacaktır.