Microsoft Azure platformunun detay servislerini inceleyeceğimiz "Mind Blown Sessions #1" etklinliğimize davetlisiniz.!

Uzun zamandır bloğumda Azure Stack ile ilgili hiçbir paylaşımda bulunmadım ve sadece sessizce takip ettim. Birkaç ayda pek çok yenilik gerçekleşti ve bu paylaşımımda yeniliklerde en çok etkin olan özellikleri açıklayacağım.

Azure Stack geçen yıl TP1 ( Teknik önizlemesi 1 ) adı verilen proof of concept ile beklenilenden daha önce bir sürede tanıtıldı. Bizlere sunulan bu teknik önizlemenin hedefi müşterilere, danışmanlara ve ilk deneyimleyenlere Microsoft'un private ve hybrid cloud ortamının geleceğinin nasıl ne gibi ne tür yeniliklerinin geldiğinin ilk denemesinin yapıldığını göstermekti. Ama, sahiden nedir bu Azure Stack?

Sade Bir Anlatım ile Azure Stack

Azure Stack Microsoft Azure servisleri, özellikleri ve kullanıcı tecrübesi benzerine sahip olmak için on-premise(Datacenter) yapınıza deploy edebileceğiniz bir yazılımdır. Eğer Microsoft Azure kullanıyorsanız (yeni portal, İbiza Portal olarak bilinen portal.azure.com) kendi veri merkezinize Azure Stack deploy ettiğinizde elde edeceğiniz hizmet yukarıdaki cümlelerimde geçmektedir. Böylece lokal tesislerinizde Azure teknolojisini geliştirebilecek, deploy edebilecek, yönetebilecek ve Azure Virtual Machine, Web Application, Virtual Network gibi sayısı daha da artan Azure servislerinden faydalanabileceksiniz. Sadece tarayıcı üzerinden portal.azure.com'u yazmak yerine, size özel Azure Portal'a (kendi veri merkeziniz üzerindeki ) yönlendiren kendi alan adınız ile rastgele bir URL tuşladığınızı düşünün. Oldukça inanılmaz gözüküyor.

Azure Stack benim şirketim için mi yoksa iş için mi uygun?​

Azure Stack sizin veri merkezinize sanallaştırma platformundan ( basit bir sanal makine) veya gelişmiş bulut özelliklerini Azure App gibi servisleri gerçekleştirmek için bir yol sunar. Teknik olarak baktığımda, Azure Stack hizmetini en azından sanallaştırmayı benimsemiş ve kullanmayı hedef almış her şirket tarafından tercih edilebilir olarak görüyorum. Fakat bu, Azure Stack hizmeti benimsemek için yeterli değildir. Bir danışman ve Azure Mimarı olarak, bence Azure Stack aşağıdaki durumlar içerisindeyseniz sizin için uygun olabilir.

Microsoft Azure tarafından sağlanan farklı servisleri, konseptini deneyimlemiş veya deneyimliyorsanız, eğer Azure hizmetinin şirketiniz için onayladıysanız, ve On-Premises tesislerde aynı deneyimi arıyorsanız ( herhangi bir nedene bağlı olarak) Azure Stack sizin için iyi bir tercih olabilir. Azure Stack ve Azure uyumlu olarak çalışır. Hybrid bir ortama sahip olabileceğinizden kaynaklarınızı Azure Susbscription ve Azure Stack arasında hiçbir ekstra bir yapılandırmaya gerek kalmadan kolay bir şekilde kaydırma şansınız olacak. Bununla beraber Azure ve Azure Stack aynı API kullandıkları için yazılım ekibinin kod tarafında güncelleştirme yapmalarına gerek kalmayacak.( API, Resource Deployment, DevOps)

Güncel bulut teknolojilerini ve konseptini sağlayan özel bir bulut platformu arıyorsanız, Azure Stack, Azure tarafından yaratıldı ve test edilmiş ve yapılacak iyileştirmelerden sürekli olarak yararlanmaya devam edeceksiniz.

Uygulamaları ve Servisleri daha hızlı inşa etmek için modern bir yol arıyorsanız, Paas ve Micro Services yapısını baz almış model olarak Azure Stack tam size göre. İlk versiyonunda ( 2017 ortası ) Azure Web Apps'i destekleyecek, biraz daha ileriye gidersek eğer getirmeyi planladıkları hizmetler arasına Azure Fabric'i de katabiliriz.

Azure Stack Müşterilere Nasıl İletilecek ?​

Bahsetmem gereken asıl tartışma konusu, burada Microsoft kazanan taraf oluyor ve bunu da tabi ki sınıflandırılmış esnekliğine borçlu diyebiliriz. Azure Stack bütünleşmiş Sistem platformları ile 3 farklı donanım sağlayıcılarını seçme konusunda özgürlük hakkı verecek.

Yukarıdaki resimde görüldüğü gibi Hewlett Packard Enterprise, DELL ve Lenovo dışında Azure Stack platformunu kendi donanımınızın üzerine deploy edemeyeceğinizdir.

Bu son açıklama takip ettiğim topluluklar tarafından tepki yarattı ve bu can alıcı noktayı iki başlık altında toplayabilirim.

Microsoft bu modelin istenilen Enterpise level olan private / hybird bulut platformuna erişmek için tek yol olduğunu doğruluyor. Microsoft donanım ile bütünleşmenin oldukça ağır bir görev olduğunu ifade ediyor ve müşteriye bir hazır makine verip platformu onaylamayı tercih ediyor.

Topluluk tarafından önerilen ise Microsoft'un ilk olarak fiyatı makul olmayan donanım sağlayıcıları için çözümü kilitlemesinden ve ikinci olarak ise orijinal sanallaştırma ve bulut ideolojisini takip etmemesinden ki bu da var olan kaynakların ister istemez optimizasyonunu ve yeniden kullanımını reddetmek anlamına geliyor ve hatta makul fiyatlı ve emtia donanımları kullanmamayı tercih etmesinden dolayı şaşırıyor.

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.