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.

Öncelikle bilmemiz gereken bir durum var. Bu hizmet Service Management dağıtım modelinden Resource Manager dağıtım modeline geçiş için tasarlanmamıştır. Azure Site Recovery hizmetini kapsamlı bir şekilde blog şu yazımda açıklamıştım. Azure Site Recovery, felaket kurtarma amaçlı şirket içerisinde çalışan workload sunucularının seçtiğiniz Azure Datacenter içerisine replike olmasını sağlar. Felaket anında sunucular hizmet vermeye devam eder. Sanallaştırma platformu Hyper-V,Vmware ve Physical sunucularınızı replike etme yeteneğine sahiptir.

Avantajları:

Süreç tamamen Azure Portal aracılığıyla yönetilir ve bir defada birden fazla sanal sunucular (VMs) için toplu bir taşıma işlemini destekler. İsteğe bağlı olarak Azure Site Recovery hizmetinin cmdlet'leri kullanılarak PowerShell sayesinde süreci otomatize etmesi desteklenebilir. Bir kez ayarlanır ve Portal arayüzünden replikasyon takibi yapılabilir, sürecini izlemek ve herhangi bir sorun tespit etmek kolaydır, böylece taşıma tamamen Azure portalı üzerinden yönetilebilir.

Dezavantajları:

Azure Site Recovery kurulumu karmaşık ve zaman alır. Elbette bu sadece bir kez gerçekleşiyor ancak bir hizmet olduğu için bir takım kurulum talimatları var. Bu seçenek ile Azure Site Recovery servisin gerçek amacı dışında bir geçiş senaryosu içinde kullanılabilir. Bu senaryoya özgü bazı adımlar, eksik ve el ile yapılandırılması gerektiren bölümleri vardır. VM replikasyon işlemi eklenir ve senkronizasyon gerçekleşmesi data boyutuna göre zaman alır. Bu senkronizasyon işlemi yavaş olabilir ve etkilenen diskler sayısına bağlı olabilir. Son olarak, Azure Site Recovery ile geçiş yapılacak sanal sunucular için gereklidir bazı yapılandırma gereklidir. Process Server rolü ile iletişime geçebilmesi için her taşınacak sunucuya agent kurulumu gerekmektedir.

Sonuç:

Azure Site Recovery ile taşıma işlemine yapılabilir fakat önerebileceğim bir yöntem olarak gözükmüyor. Sebebi ise, taşıma sırasında sunucularda belirli bir "downtime" oluşması ve taşınması gereken her sunucuda bir takım (agent, config) ayarların yapılması gerekmektedir. Paralel olarak taşımanıza imkan verebilir fakat Azure Site Recovery hizmetinin ücretli olduğunu hatırlatmakta fayda var.

Seçenek 4 – migAz Tool

MigAz aynı veya farklı subscription içerisine sanal sunucuların taşınmasını sağlayacak en yeni ve yetenekli bir araçtır. Benimde bir çok taşıma sürecinde kullandığım şimdilik tam bir çözüm olduğunu ve ileride daha iyi hale geleceğini düşündüğüm arayüz ile birlikte karşımıza çıkmaktadır.

Herşey arayüz üzerinden seçilerek tasarlanyor fakat yine de işi tamamlamak için komut takım cmdlet çalıştırmak gereklidir.

Avantajları:

Araç oldukça kolay bir şekilde taşıma sürecinizi başlamanızda sizlere yardımcı olmak için yeterli dokümantasyon ve birkaç seçenek sunar. Herhangi bir kesinti olmadan sunucularınızı Resorce Manager dağıtım modeline taşımak mümkündür. Aslında bir yandan bu şu anlamada gelmektedir, ASM(v1) ve (ARM)v2 kaynaklarınız aynı anda hizmet verebilir.Geçiş işlemleri için size bir test ortamıda sağlamış oluyor. Şu anda desteklenen senaryoları içeren liste aşağıdaki gibidir.

• Classic Portal içerisinde bulunan Virtual Network(vNet), isteğe bağlı olarak Resource Manage(ARM) taşınırken farklı bir ip adres aralığına terfi edebilir.
• Classic Portal içerisinde bulunan Virtual Network(vNet) aynı şekilde Resource Manager(ARM) modeline taşınabilir.
• Classic Portal içerisinde bulunan tüm sanal sunucu bileşenlerini Resource Manager modeline geçişini sağlar.

Dezavantajları :

Bu aracı kullanırken henüz bir hata ile karşılaşmadım. Oldukça güçlü gözüken ve arka tarafta geçiş sürecini sihirli bir hale getirebiliyor. Arayüz üzerinden yapılan seçimlerde sonra Resource Manager API kullandığı ".JSON" dosyalarını geçiş için sizlere oluşturacaktır. Bu sayede deployment template dosyası hazır hale gelebiliyor. Son olarak, herhangi bir sorun ile karşı karşıya gelirseniz, geliştiricilere destek olmak mümkün olacak. Çünkü bu Microsoft Open Source Code of Conduct projesidir.

Sonuç : Güzel bir GUI ile ve kaynakları seçerek ve bir komut dosyasını geçiş çalıştırmak oldukça kolay gözüküyor. ASM2ARM çıkışından sonra bu şekilde bir ihtiyaç doğdu ve o yüzden JSON şablonları ve geçiş detayları için dosyaları kullanarak süreci başlatır.. Tüm seçeneklere baktığımız zaman migAz oldukça kolay bir şekilde genel taşıma sürecini yönetmek için en kolay yoldur. Önermiş olduğum geçiş senaryolarını özetlemek adına aşağıdaki tablo içerisinde aklınıza takılan yerlerin özetini bulabilirsiniz.

Son zamanlarda hakkında pek çok soru aldığım bir konudan bahsetmek istiyorum. Azure bizlere Virtual Machine hizmetini iki farklı şekilde oluşturmamıza olanak sağlıyor. Bu farklı türlerdeki sanal sunucular Microsoft Azure içerisinde çalıştığı platform farklılıklarından kaynaklanmaktadır. Yazıya devam etmeden önce bu iki farklı terminolojinin ne anlama geldiğini kısaca açıklamanın faydalı olacağını düşünüyorum.

Classic (v1) / Azure Service Management

Classic veya Azure Service Management (ASM) olarak adlandırılırlar.Diğer adıyla v1(Virtual Machine) olarak da görebilirsiniz. Service Management kaynakları classic portal, yeni portal(Ibıza) veya Azure PowerShell / CLI ile yönetilebilir. Ancak, Classsic VM'ler bazı özellikleri, yeni Azure Portal(Ibıza) üzerinde henüz mevcut değildir. ( Network Card Custom DNS, vd.)

ARM (v2) / Azure Resource Manager

Resource Manager veya Azure Resource Manager(ARM) olarak adlandırılırlar. Azure Resource Manager yapısı Service Management yapısına göre oldukça farklıdır ve bunun detayını blog üzerinde "RESOURCE MANAGER VS SERVICE MANAGEMENT" adlı yazımdan bulabilirsiniz. Microsoft Azure ilk hizmet vermeye başladığı zamanlarda sadece PaaS ve SaaS hizmetlerini düşünerek yola çıkmıştı fakat müşterilerinden gelen talepler doğrultusunda IaaS hizmeti verince işler biraz karıştı. Service Management içerisinde oluşturulan bir sanal sunucuya dışardan gelen istekler önce Cloud Service hizmetine gelip oradan ilgili sanal sunucuya aktarılıyordu. Fakat bu yapı Resource Manger altyapısı ile yepyeni bir boyuta taşınarak Network Interface kaynağına gelip oradan erişim sağlanıyor ve Resorce Manager sunuculardaki esnekliğin, ayrıca yönetimin üst seviyelerde olduğunu şahit olacaksınız.( + Performans ) Azure yeni portal(Ibıza) üzerinden özellikle Automation ve DevOps'un etkisini ne kadar yazsak az olacağını düşünüyorum. Resource Manager Template Deployment ve Şablonlarınızı import/export yöntemi ile önemli avantajlar sunmaktadır. ARM şablonları ve geliştirdiğiniz deployment modelleri operasyon anlamında inanılmaz kolaylık sağlıyor olacak.

Azure üzerinde artık yeni bir hizmet oluşturduğunuz zaman Resource Manager altyapısını tercih etmeyi unutmayın.Teknik yetenekleri dışında Microsoft'un yeni satış modeli olan Cloud Solution Provider ise sadece Resource Manager dağıtım modelinden anlayabiliyor. Başka bir yazımda ise bu modelleri derinlemesine inceliyor olacağım. Ancak, bugün, hala Service Management (Classic) platformunu kullanan müşterilerim oldukça mevcut ve tüm kaynaklarını Resource Manager platformunda geçirmek için 4 seçenek üzerinde duracağım

Seçenek 1 – ASM2ARM Script

İlk seçeneğimiz ASM2ARM adında bir Powershell Script olarak karşımıza çıkmaktadır. GitHub üzerinden erişebileceğiniz bu script ile (v1)Virtual Machine yapısından (V2)Virtual Machine taşımanıza izin veren kod bloklarını ve cmdlet kümesini içerir. Bu sayfa üzerinde migration işlemi için bu aracı nasıl kullanılacağı hakkında daha detaylı bilgiler elde edebilirsiniz. Bu script geliştiren kişinin bir Türk olduğunu yazmayıda unutmayalım.

Avantajları:

Bu seçenek ile süreci tamamen scripted duruma getirebilirsiniz. Herhangi bir portal arayüzüne erişip bir aksiyon almanıza gerek yoktur."ASM2ARM" ile ancak "tek" makine taşınabilir. Paralel olarak taşımak için alt yapıda bulunan tüm sanal sunucuları PowerShell içerisinde döngü kullanımı ile tek seferde gerekli taşıma sürecini başlatabiliriz. Eğer kurulmuş bir ağ topolojisinde (vNETs vb) taşımak istiyorsanız iyi bir seçim olacaktır.

Dezavantajları:

Powershell Script kullanırken bu parametrelerden birini yanlış yazdığınız zaman, özellikle çok fazla hataya eğilimli olduğunu söylemekte fayda var. Aynı zamanda taşınan kaynakların isimlerine otomatik olarak bir prefix ekler böylece önünde 'migrated-' ismi gelmektedir. Bu durum maleesef idealden olarak görüyorum. Son olarak, bu taşıma süresince v1 VM(Service Management) kapalı durumda olması gerekir ve bu da kesinti anlamına gelmektedir.

Sonuç:

Powershell'in yeteneklerine baktığımızda harika bir seçim olduğunu düşünmeme rağmen, yavaş taşır ve hizmet kesinti gerektirir.

Seçenek 2 – Azure Powershell

Azure SDK v2.9 sürümü ile, kaynakların taşınması için bir takım cmdlet yapısı inşa ediliyor. Microsoft'un resmi sayfasında bulabileceğiniz bu konuda adımlara bakarak taşıma işlemlerini yapabilirsiniz. Bu komutlar hali hazırda birçok destek ve esneklikleri olup bir sonraki sürümlerde yenileri eklenecektir. Cmdlet örnekleri " Move-AzureService, Move-AzureVirtualNetwork" şeklinde gözlemlenir.

Avantajları:

Süreç tamamen Azure Powershell cmdletleri ile yapılabilir.Microsoft'un resmi yazısı eski olsa bile, cmdlet örnekleri temel geçiş senaryoların bir çoğunu kapsamaktadır. Büyük bir yararı ise taşıma sırasında hiçbir kesinti ortaya çıkmamasıdır. VHD dokunmadan metedata ile sorunsuz bir geçiş yapılabilir.

Dezavantajları:

Şu anda desteklenen senaryolar sınırlıdır. Bulut Hizmetleri, bütün vNET ve sadece classic VM alt yapısı için geçerlidir. Resource Group içerisinde bulunan vNET yapısına dahil edilemez.

Sonuç:

Azure PowerShell ile çok hızlı ve hiçbir kesinti olmadan geçiş sağlanabilir. Kestirmeden nirvanaya ulaşmak için Powershell Workflow ile paralel işlemler başlatabilirsiniz. Ancak, desteklenen senaryolar sınırlıdır ve bütün vNETs taşınması gerekir ise mevcut bir ağ topolojisinde taşınamaz(Farklı CIDR aralığına). Microsoft'un resmin yazısı içerisinde geçiş senaryoları dikkatli bir şekilde okunmalıdır.