CIM ve WMI tarafından kullanılan repository, farklı namepsace yapısı içerisinde düzenlenmiştir. Bir namespace alanı temelde bir klasör gibi düşünülebilir ve farklı yönetim amaçlarıyla ilgili öğeleri gruplamak için kullanılır. Namespace alanları kendine içinde class(sınıflar) içerir. Bir class, yönetilebilir bir yazılım veya donanım bileşenini temsil edebilir. Örneğin, Windows işletim sistemi, işlemciler, disk sürücüleri, hizmetler, kullanıcı hesapları vb. Için class yapısı bizlere sağlar. Network ortamında bulunan her bilgisayar, farklı işletim sistemlerine sahip olacağından dolayı farklı namespace alanları ve class yapısına sahip olabilir.

Farklı namespace ve class yapısına hızlı bir örnek verecek olursak, Örneğin Active Directory rolüne sahip bir bilgisayar ile Windows Client arasında namespace ve class yapısı doğal olarak farklılık gösterecektir. Gelelim bu repository içerisinde nasıl aramalar yapılır bu namespace ve class nasıl erişeceğim dediğiniz duyar gibiyim. İşte bu kısımda yardımımıza önereceğim araçlar yetişiyor olacak ve işimiz çokta kolaylaştıracak.

Ama bunun öncesinde bir WMI ve CIM class çağırıldığı zaman bunların bir takım özellikleri bulunuyor ve bunları aşağıda inceleyelim.

• Methods: Method yapısı kullanılarak aksiyonlar aldırabiliriz. ( Uzak bilgisayara Re-start, servis-start-stop)​

• Properties: Çağırdınız class içerisinden alınabilecek bilgilerdir. Nitelik.​

• Events: WMI veya CIM class'ını izleyip gerçekleştiklerinde harekete geçebilecekleri eylemlerdir.( Trigger)​

Şu anda WMI için namespace ve class yapısını keşfedebileceğiniz birkaç GUI aracı var, bu yüzden bir kez Namespace, Class, Properties veya event yapısı ile çalışmak istediğiniz zaman karar verebilirsiniz. Birçok sistem yöneticisi tarafından WMI'yi keşfetmek için en sevdiğim araçlardan biri, SAPHIEN firmasının WMIExplorer diyebilirim. Bu araçlar oldukça kolaylık sağlıyor. Powershell ile Namespace, class, properties ve method aramaları gerçekleştirebilirsiniz ama oldukça zor olabiliyor siz isterseniz bunun için aşağıdaki örneklere dikkat edin.

Bilgisayarınızdaki veya remote bir bilgisayardaki tüm namespace alanlarını listelemek için Windows PowerShell'i kullanabilirsiniz.

Yukarıdaki örnekte Powershell ile bilgisayarınız üzerinde bulunan tüm "Namespace" isimlerini listemiş bulunuyoruz. Namespace içerisinde "Class" detaylarını nasıl incelendiğine bakalım. Windows PowerShell, belirli bir namespace alanındaki tüm class'ları listeleyebilir. Örneğin, "root \CIMv2" namespace alanındaki tüm sınıfları listelemek için aşağıdaki komutlardan birini çalıştırabilirsiniz.

Yukarıdaki görüldüğü gibi Powershell içerisinden ilgili NameSpace adını yazıp, tüm WMI ve CIM Classlarini listelenmesini sağladık. Class isimlerine dikkatinizi çekmek istiyorum. "Win32_*" ile başlayanlar WMI temsil ediyorlar, bu classları kullandığınız zaman isimlerinden göründüğü gibi bilgileri elde edebiliyoruz. Mesela, "Win32_Volume" Class'ını Powershell içerisinden çağırıp sorgulama yaptığım zaman, sorgulama yaptığım işletim sistemleri üzerinde Volume bilgilerini alabileceğimiz detaylar gözüküyor olacak. Burası gerçekten çok fazla detay gerektiren ve zamanla kavranabilecek bir yer. SCCM, SpiceWorks, diğer Inventory Management yapan tüm yazılımlar aslında OS üzerindeki bu class yapısına sorgular yaparak bilgileri topluyor. Bir sonraki yazımızda bu class yapısının özelliklerini inceleyelim.

Bu yazı serisinde Powershell ile WMI ve CIM teknolojilerinin nasıl çalıştığını, kullanım methodlarını genel hatlarıyla detaylandırmaya çalışıcam. Artık Blog üzerinde genelde seriler yazmaya çalışıyorum ve bu yazı serisine başlamak için çok sabırsızdım. Bir şekilde herkes Powershell ile haşır neşir oluyor fakat bu tarz derinlemesine konulara bakmaya fırsatı olmuyor veya dokunamıyor. İşte bu yazı serisinde bu teknolojilerin öneminden bahsedeceğim.

Windows Management Instrumentation (WMI) ve Common Information Model (CIM) birbirleriyle ilgili teknolojilerdir. Her ikisi de, farklı platformlarda uygulanabilen bağımsız yönetim standartlarını tanımlayan Distributed Management Task Force (DMTF), tarafından tanımlanan endüstri standartlarını temel alır. WMI, Microsoft'un Web-Based Enterprise Management (WBEM) standardının bir uygulamasıdır. Ön standartlara ve tescilli teknolojiye dayanan eski bir teknolojidir. CIM daha yeni bir teknolojidir ve açık, Cross-platform standartlarına dayanmaktadır. WMI, Windows NT 4.0'dan bu yana Windows işletim sisteminde kullanılabilir durumdadır.

DMTF nedir diyenler bu sayfaya göz gezdirebilirler. Distributed Management Task Force (DMTF) - www.dmtf.org.

Her iki teknoloji de ortak bilgi deposu olarak (WMI deposu olarak da bilinir) bağlanmanın bir yolunu sağlar. Bu depo içerisine sorgular gönderebilir ve yönlendirebileceğiniz yönetim bilgilerini içerir. Windows PowerShell 3.0 ve sonraki tüm sürümler her iki teknolojiyi de desteklemektedir. Windows PowerShell'in önceki sürümleri yalnızca WMI'yı desteklemektedir. Windows PowerShell 3.0 ve sonraki sürümlerinde, paralel olarak iki komut grubu, WMI veya CIM'i kullanarak görevleri gerçekleştirmenize izin verir.

Yukarıdaki resim bir bilgisayarın Repository yapısı ile iletişim kurabileceği iki yolu gösterir. Yeni yol olan Common Information Model (CIM) komutlarını kullanmaktır(Get-CIMOBject). Bu komutlar Web Services for Management (WS-MAN) protokolünü kullanarak iletişim kurar ve Windows Remote Management (WinRM) hizmetine bağlanır. Eski yol olan Windows Management Instrumentation (WMI) komutlarını kullanmaktan geçiyordu ve bu komutlar, DCOM protokolünü kullanarak iletişim kurar ve WMI hizmetine bağlanırlar. (Get-WMIObject) Distributed Component Object Model (DCOM) protokolünü merak edenler bu sayfadan detaylara erişebilirler.

CIM komutları, çok sayıda Cross-Platform ve Cross version yetenekleri sunar. Çeşitli bağlantıları desteklerler bunlar sırasıyla,

• DCOM kullanan yerel bilgisayara bağlantı sağlarlar.​

• Web Hizmetleri Yönetimi olan (WS-MAN) protokolünü kullanan uzak bilgisayara bağlantılar sağlayabilirler. Bu protokol defaul olarak HTTP tabanlıdır.​

• DCOM veya WS-MAN kullanabilen uzaktaki bir bilgisayara oturum temelli bağlantılar sağlar.​

DCOM bağlantıları, genellikle Windows işletim sisteminin bir parçası olan Windows Management Instrumentation (WMI) hizmetine yapılır. WS-MAN bağlantıları, Windows PowerShell Remote Session ayarını etkinleştiren, Windows Remote Management (WinRM) hizmetine yapılmaktadır. WinRM hizmetini aktif ederken dikkat edilmesi gereken nokta, Windows Management Framework bir parçası olduğunu ve Windows Management Framework 2.0 ( Powershell version 2.0 üstü) ve daha yeni sürümlerinde bulunmaktadır. WinRM, varsayılan olarak Windows 7, Windows 8, Windows Server® 2008 R2, Windows Server 2012R2 ve Windows Server 2016 çalıştıran bilgisayarlara kurulu olarak gelmektedir. Varsayılan olarak tüm bu işletim sistemlerine yüklenmesine rağmen, WinRM yalnızca Windows Server 2012 ve üstü işletim sistemlerinde otomatik olarak etkinleştirilmiştir.

CIM komutlarını iki şekilde kullanabilirsiniz. İlk yöntem olan bağlanmak istediğiniz uzaktaki bilgisayarın WinRM'yi yüklenmesi ( işletim sistemi versiyonu detayını unutmayalım) ve aktifleştirmenizi gerektirir. Bu süreç genellikle, Windows Management Framework 3.0'ın yüklenmesini ve Windows PowerShell Remote Session özelliğinin aktif hale getirilmesi durumudur. CIM komutlarını kullanmanın ikinci yöntemi ise, komutu eski hali olan WMI teknolojisini kullanması durumudur. Bu sayede, WMI komutlarıyla aynı sorgulara cevaplar alabilir ve Windows Management Framework uzak bilgisayarda kurulmasını ve aktifleştirilmesi gibi süreçler ile uğraşılmaz.

Windows Management Instrumentation (WMI) komutları ve teknolojisinin detayları

WMI komutları ile CIM komutları aynı havuzu kullanırlar. Aralarındaki tek fark, WMI komutlarının uzak bir bilgisayara nasıl bağlandığının detayıdır. WMI komutları session tabanlı bağlantıları desteklemez. Komutlar, yalnızca geçici bağlantıları DCOM üzerinden destekler. WMI veya CIM komutlarıyla kullanıldığında, DCOM bazı durumlarda kullanımı zor olabilir. DCOM, Remote Procedure Call (RPC) protokolünü kullanır. Bu protokol doğru çalışması için güvenlik duvarı istisnaları gerektirir.

WMI komutları, WMI servisiyle iletişim kurar. Uzak bilgisayarda herhangi bir WMI sorgusu yaptığınız zaman Windows Management Framework herhangi bir sürümünün detayı aranmaz ve Windows PowerShell Remote Session özelliğinin etkinleştirilmesi ile uğraşılmaz. Bağlanılacak uzak bilgisayarda Windows Güvenlik Duvarı özelliği etkinleştirilmişse ve third-party bir hizmet aktif ise, WMI sorguları için uzak bilgisayarda güvenlik duvarı tarafında kuralları WMI servisi için kurallar yazılması gereklidir. CIM komutları DCOM'u da kullanabileceğinden, WMI komutları session olarak sorgulama yapmadığı için (ad-hoc connection model) WinRM'in uzak bilgisayarda aktif edilmesi aranmaz. CIM ve WMI özetine baktığımız zaman, WMI ile sorgular yaparken herhangi bir servisin aktif edilmesi ile uğraşılmasına gerek kalmaz sadece Firewall tarafında bir takım kurallar yazılması gereklidir.

WMI işletim sisteminin farklı bölümlerine erişim sağlayan nesne topluluğu olarak bakabiliriz. PowerShell'de nesnelerinde sahip olduğumuz gibi her biri için properties, method ve event'lar var. Bu nesnelerin her biri "System32\wbem" dosyasında ".mof" uzantısıyla kaydedilen MOF (Management Object Framework) adlı dosyalar tarafından tanımlanır.

WMI veya CIM hangisi tercih edilmeli?

Öncelikle çoğu zaman, WMI cmdlet'lerinin yerine CIM cmdlet'lerini kullanmanız gerekir. Bunun birden fazla sebebi var aslında.

• CIM cmdlet'leri uzak bilgisayarlara yapılan bağlantılar için WS-MAN'ı kullanır.​

• CIM cmdlet'leri, uzak bilgisayara oturum temelli bağlantılar için DCOM veya WS-MAN kullanabilir.​

WMI cmdlet'leri ile sorgulamalar yaparken, Windows Management Framework 2.0 veya daha yeni bir sürümü yüklü olmayan bir bilgisayara veya Windows Management Framework 2.0 yüklü ancak Windows PowerShell Remote Session sistemine sahip olmayan bir bilgisayara geçici bir bağlantı oluşturmanız gerektiğinde bu gereksinimlere ihtiyacınız yoktur.

CIM tarafında ise oldukça farklı durumlar mevcut yazımızın başında dediğim gibi cross platform desteği olması, ortamda bulunan bir switch cihazına CIM session üzerinden komutlar gönderme şansınız var. CIM cross platform ve cross versiyon olayında oldukça önde olduğunu tekrar hatırlatalım.

WMI ve CIM teknolojilerinin detaylarını anlattıktan sonra artık cmdlet mimarisine geçelim. Kendine ait ama çok benzer bir yapıya sahipler. "Get-Command" cmdlet yardımı ile "WMI" cmdlet hepsini listeleyelim.

Yukarıdaki bulunan resimde WMI ailesine ait tüm cmdlet listesi bulunmaktadır. Şimdi ise CIM cmdlet ailesine göz gezdirelim.

CIM cmdlet ailesi WMI'dan fazla görünüyor. Yeni teknoloji olan CIM modeli oldukça işimizi kolaylaştıran cmdletere sahip. Çok kısa bir örnek ile bunun detayına değinmek istiyorum. WMI ve CIM işletim sisteminin repository olarak düşünmeyi asla unutmuyoruz. Ortamınızda bulunan bilgisayarlarda SCCM, Intune, SpiceWorks ve diğer Varlık yönetimi yapan tüm uygulamalar arka tarafta WMI veya CIM kullanarak bizlere raporlar sunmaktadır. Bir sonraki yazımızda Repository kullanımının detayına bakalım.

MSHowto Ekibi olarak, 24 Şubat 2018 Cumartesi günü Microsoft İstanbul Ofisi Jupiter 2 salonunda benim de konuşmacı olarak yer alacağım "MSHOWTO ile Tech Summit -1" etkinliğimize davetlisiniz. Sınırlı katılımcı sayısından dolayı kayıt işlemini hemen yapmanızı öneririz. Etkinlik içeriğine ve kayıt formuna aşağıdaki linkten ulaşabilirsiniz.

Kayıt olmak için tıklayın.​

Uzun bir zaman aralığından beri PowerShell ISE'yi kullanmaktayım. Powershell 2.0 versiyonu ile hayatımıza giren Integrated Script Envoirment artık yerini devretme zamanı geldi mi? Bunun dışında Third Party olarak çok sık kullandığım Powershell Studio aracından hiç bahsetmiyorum fakat bazen çok fazla kaynak tüketip beni üzüntü ve muz kabuğuna uğratabiliyor. Ek olarak, PowerShell de Visual Studio Code tarafından şahane bir şekilde desteklendiğini söyleyebilirim. Ayrıca, Visual Studio Code, PowerShell Core için tüm platformlarda (Windows, MacOS ve Linux) desteklenirken Powershell Integrated Script Environment henüz Powershell Core desteklemiyor. Powershell Core merak edenler için uzun bir seri hazılıyorum.

Powershell Integrated Script Environment ( ISE ) destek verenler kullanmaya devam ettiğim ve hayatımı kolaylaştıran inanılmaz eklentiler geliştirdiler. Bunların bir kaçtanesi; "Azure Automation", "ScriptBrowser", "ISESteroids", "ISEPack", "WMIQuery" saymakla bitmeyecek bir çok eklentiler benim çoğu zaman hayatımı hep kolaylaştırdı. Kolay değil bu değişimi Kabul etmek benim tarafımdan fakat Visual Studio Code yetenekleri ile çok daha hızlı gelişti ve sonucunda bende değişime ayak uydurmak zorunda kaldım. ( Team Services Extesion bunun başındaki sebep aslında ). Mevcut işletim sisteminizde en az PowerShell 5.0 versiyonu ile Windows'da Visual Studio Code ile Powershell geliştirmeye başlayabilirsiniz. Windows 10'u veya diğer Windows İşletim Sistemleri (ör. Windows 8.1 vb.) Için Windows Management Framework 5.0 yükleyerek Visual Studio Code üzerinden Powershell geliştirmenin keyfine varın.

Visual Studio Code yukarıda bahsettiğimiz gibi farklı platformlarda desteklenmektedir. Bunlar sırasıyla,

1. Windows
2. Linux
3. macOS

Visual Studio Code kurulumu ve kullanımı için adımları göstermeyeceğim. Bununla ilgili internette sayfalarca döküman var. Visual Studio Code kurulumu yaptıktan sonra sol kısımda gördüğünüz extension ekranı içerisinden Powershell aramasını yaparak ilgili extension kurulum yapmanız gerekmektedir. Daha sonra Visual Studio Code içerisinde geliştirdiğiniz Powershell satırlarını Execute, Debug etc. süreçlere dahil edebilir hale geleceksiniz.

Bu geçiş sürecine bende alışmaya çalışıyorum ama oldukça hoşuma gidiyor artık. Visual Studio Team Services bağlantısı benim için çok fazla önem arz etmekteydi. Artık Visual Studio Code ile hayatıma devam edeceğim. Powershell Studio ( SAPHIEN ) benim için ayrı bir yeri var.

Azure Resource Manager şablonlarının yazılması ve deploy edilmesi size esneklik ve otomatik bir ortam sunmasını sağlarken bazı durumlarda, Azure Resource Manager şablonları kısa sürede çok karmaşık hale gelebilir. Ayrıca, Azure Infrastructure ortamınız için Microsoft'un en iyi uygulamalarının ekibiniz tarafından yazılan her şablona yansıtılması sağlamak bazı durumlarda zor olabilir. Eğer Azure Resource Manager dağıtım modeline hakim değilseniz, Azure Resource Manager makale serimi okumanızı tavsiye ederim.

Bu makale serisinde, Azure Resource Manager şablonunu geliştirirken ve dağıtımını basitleştirmeye yardımcı olan açık kaynak kodlu Azure Building Blocks ele alacağız. Microsoft içerisinde bulunan dağıtım modelleri ve uygulamalar ekibi tarafından öngörülen en iyi uygulamaları yansıtan ( IaaS, PaaS ) – benzeri olan Azure Resource Manager şablonlarını içerir. Azure Resource Manager şablonlarını kullanarak ( Template Deployment – Github) kaynak dağıtımını destekler. Azure kaynaklarını yöneten bir kişi, Resource Manager Deployment API sayesinde JSON formatında bir model kullanır ve bunu Azure Resource Manager API üzerine gönderir. Örnek olarak ortamınıza deploy etmek istediğiniz kaynakları ; Virtual Machine, Virtual Network, Storage, Network Security Group olarak belirterek gerekli dağıtımı sağlayabilirsiniz. Yine talebinize göre dağıtımı yapılmak istenilen kaynağın özelliklerinin tamamı, dağıtım yapılacak zamanda parametrik hale getirilerek özelleştirilir. Aşağıda bulunan resim içerisinde Azure Resource Manager dağıtım modelini destekleyen bir JSON dosyası bulunmaktadır.

Azure Resource Manager şablonları çok güçlü, büyük ve karmaşık mimarileri dağıtmanıza izin verirken, Azure Resource Manager hakkında geniş bilgiye ihtiyaç duyarlar. Bu durum ise bazı zamanlarda geliştirdiğiniz şablonları koruma kısmında zorluk çekmenize sebebiyet verir. Çünkü herhangi bir değişiklik, ön görülemeyen sorunlara neden olabilir. Azure Resource Manager güçlü dememin altında yatan oldukça fazla sebep var. Örneğin, bir Virtual Machine dağıtmak istediğinizi varsayalım. Deploy olurken içerisine kurabileceğiniz role, registry, gibi ucu açık bir kapı olduğunu düşünün. "Ne gerek var ?" Dediğinizi duyar gibiyim. İşte burası biraz komplike bir süreç olduğu gözükebilir ama Virtual Machine Scale Sets kullanırken zaten bunları yapmak zorunda kalıyorsunuz. Azure Building Blocks temel amacı daha basit bir şekilde deployment süreçlerinizi yapabilmenizi sağlamaktadır.

Azure Building Blocks projesi, Azure kaynaklarının kullanımını basitleştirmek için tasarlanmış bir komut satırı aracı olup, Azure Resource Manager kapsamını kullanarak bu sorunu çözer. Building Blocks, Resource Manager Deployment modelindeki gibi JSON formatı ile yazılır ve Azure Resource Manager şablonlarından yararlanarak dağıtımı gerçekleştirir. Azure Resource Manager Template olduğu gibi parametre belirtebildiğiniz gibi, Building Blocks içinde bu şansa sahipsiniz. Building Blocks JSON şeması çok basit olacak şekilde tasarlanmıştır. Azure Building Blocks 2.0 versiyonu ile şimdilik anılmaktadır.

Building Blocks şu anda aşağıdaki kaynak türlerini desteklemektedir.

• Virtual Networks​

• Virtual Machines (including load balancers)​

• Virtual Machine Extensions​

• Route Tables​

• Network Security Groups​

• Virtual Network Gateways​

• Virtual Network Connection​

Yazımızın ilk serisinde genel hatlarıyla Azure Resource Manager ile Building Blocks yapısını anlamamız için açıklamalarda bulunduk. Building Blocks açık kaynaklı bir yazılım olduğunu ve Resource Manager dağıtım modelinde bize daha seri bir şekilde deployment yapmamıza yardımcı olacağından bahsettik. Şimdi ise genel yapısını ve nasıl kullanabileceğimize bakalım. Öncelikle Building Blocks aracını kurmanız için bir çok yöntem karşımıza çıkıyor. Eğer mevcut bilgisayarınız içerisinden bu tool erişip gerekli dağıtımı yapmak istiyorsanız, Azure Command Line Interface ( Azure CLI ) Yönetim aracını kurmanız gerekmektedir. Burası tamamen sizin seçiminize kalmakla beraber, dilerseniz Linux Bash üzerinden Building Blocks aracını yükleme şansına sahipsiniz. Ben bu yazı serisi içerisinde Azure CLI üzerinden devam edeceğim. Alternatif olarak tool kurulum süreçleri ile uğraşmak istemiyorum diyenler Azure Cloud Shell tercih edebilir ve Web Based olarak devam edebilirler.

Bir önceki yazımızda bahsettiğimiz gibi Azure Building Blocks 2.0 versiyonu ile indirilebilir durumdadır. Open Source bir araç olduğu için ve Azure CLI üzerinden kullanabilme durumunu hesaba katıp geniş bir şekilde bir çok platformda bu aracı tercih etmenizi sağlayacağını söyleyebiliriz. Bunların başını çeken, macOS, Ubuntu, Red Hat Enterprise Linux (RHEL), Fedora, or CentOS gibi İşletim sistemleri bulunmaktadır. Windows ise zaten söylememe gerek olduğunu düşünmüyorum. Şimdi sırasıyla Azure Building Blocks için neler gerektiğine bir göz gezdirelim.

• Azure CLI 2.0 – İşletim sisteminize şu adresten kurulum gerçekleştiriniz.​

• Node.JS - İşletim sisteminize şu adresten kurulum gerçekleştiriniz.​

• Windows için – Command Prompt – Linux için ise Bash açılması gerekmektedir.​

Windows üzerinde çalışan Azure CLI üzerinden gideceğim için Command Prompt üzerine gelip, aşağıdaki Package Manager (npm) çağırıp kurulumu gerçekleştireceğim.

Yukarıda görüldüğü gibi Azure Building Blocks kurulumunu başarıyla yaptık. Şimdi, Azure Building Blocks aracına nasıl eriştiğimizi anlamaya çalışalım. Aşağıdaki resimde görülen örnekte, Powershell üzerinden "azbb" yazdığım zaman ilgili aracı çağırmış bulunmaktayım. Bu araç ile gönderebileceğimiz parametleri görmekteyim. Yazımızın ilerleyen kısımlarında bu parametleri kullanıp deployment yapmaya çalışacağız.

Azure Building Blocks kurulumunu yaptık. Yukarıda bulunan resim size şaşırtmasın, Azure Building Blocks kurduğum zaman artık "Powershell" içerisinden çağırdım. Versiyon kontrolü yapmak istersek "AZBB" aracını çağırarak parametre göndermesi gerçekleştirelim ve versiyonumuzu öğrenelim.

"azbb –version" parametresini göndererek hangi versiyonda olduğumu öğrenmiş oldum. Bir sonraki yazı içerisinde artık Azure Building Blocks için deployment ve template geliştirme sürecine başlıyor olacağız.

Azure Building Blocks temelde bir adet "Settings File" ihtiyaç duyar. Bu "Settings File" içerisine, Deploy etmek istediğiniz kaynağın detayları belirtirsiniz. Bu size tanıdık gelen bir format olacak fakat Azure Resource Manager Deployment modelinde geliştirdiğinizden oldukça basit bir şekilde karşınıza çıkmaktadır. Bu kısımdaki esneklikleri anlamak için hemen boş bir "Settings File" oluşturalım ve ardından ilk örneğimizle yola çıkalım.

{ "$schema": "https://raw.githubusercontent.com/mspnp/template-building-blocks/master/schemas/buildingBlocks.json", "contentVersion": "1.0.0.0", "parameters" : { "buildingBlocks": { "value": [ {} ] } } }

Yıukarıda bulunan JSON şemasını izleyen bir "Building Blocks" tanımlaması ve ardından buildingBlocks dizisini istediğiniz şekilde dolduracak bir yapı izlemektedir. Şimdi basit bir örnek ile başlayalım.

Yapmak istediğimiz ilk kısım, Azure Subscription içerisinde basit bir Virtual Network ve subnet yaratılması gerekmektedir. Sırasıyla mimari aşağıdaki yapıyı içerir.

• 10.0.0.0/16 adres alanına sahip "msft-hub-vnet" isimli bir VNet.
• 10.0.1.0/24 adres alanına sahip "firewall" olarak adlandırılan "msft-hub-vnet" içindeki bir alt ağ.

Her blok bir JSON içerisinde nesne olarak temsil edilebilir. Örneğimiz içerisinde, basit bir Virtual Network'ü temsil etmek için aşağıdaki JSON nesnesini kullanalım.

{ "$schema": "https://raw.githubusercontent.com/mspnp/template-building-blocks/master/schemas/buildingBlocks.json", "contentVersion": "1.0.0.0", "parameters": { "buildingBlocks": { "value": [ { "type": "VirtualNetwork", "settings": [ { "name": "msft-hub-vnet", "addressPrefixes": [ "10.0.0.0/16" ], "subnets": [ { "name": "firewall", "addressPrefix": "10.0.1.0/24" } ] } ] } ] } } }

Yukarıdaki JSON dosyasında buildingBlocks nesnesinin içerisine gerekli tanımlamaları yaptık. Dikkat ederseniz, "Type" adında bir nesnemiz var ve onun karşınıza gerekli kaynağın modelini tanıtıyoruz. Azure Resource Manager Template gibi uzun gözüküyor. "Bunun hangi aşaması kolay ? " dediğinizi duyar gibiyim. Bu yüzden bu aradaki farklı anlamanız için aynı mimarinin Azure Resource Manager Template ile yazmaya çalışsaydınız örneğini aşağıdaki resimde görebilirsiniz.

Resim içerisine hepsini sığdıramadım fakat, yukarıdaki sadece basit bir Virtual Network oluşturulması için yapılan adımlardı. Azure Resource Manager Template kullanarak deployment yapmak oldukça zamanımızı alabiliyor. Hızlı ve basit bir şekilde yapmak için Azure Building Blocks sizleri bekliyor. Bir sonraki yazımızda geliştirmiş olduğumuz "Virtual Network Settings File" nasıl deploy edebileceğimizi inceleyelim.

Building Blocks olarak son serimiz olan bu yazımızda artık geliştirdiğimiz "Settings File" nasıl deploy edeceğimiz üzerinden konuşacağız. Öncelikle Azure CLI tarafında dağıtım yapmak istediğiniz hesap ile oturum açmanız gerekmektedir.

Azure CLI üzerine gelin, "Az Login" yazdıktan sonra size bir URL ve Access Code verecektir. Daha sonra bu bilgiler ile browser üzerinden oturum açın ve Azure CLI üzerinde başarılı bir şekilde hesaplarınızın geldiğini yukarıdaki gibi görün. Hesabım ile oturum açtım ve tüm subscriptionlarımı görmekteyim. Artık Azure Building Blocks çağıralım ve deployment sürecinin nasıl işlediğini anlayalım.

Resim içerisinde ilk deployment senaroyumuzu başarıyla yaptık. Şimdi yaptığımız adımları sırasıyla açıklayalım. Azure CLI üzerinde deployment gerçekleştirmek istediğimiz hesap ile oturum açtık. Daha sonra ise, Azure Building Blocks aracını parametreler göndererek ufak bir deployment senaryosu gerçekleştirmiş olduk. Yukarıdaki resimde parametleri görebilirsiniz ve oldukça basitlerdir. Deployment sonrası Azure paneli üzerindeki durum aşağıdaki gibidir.

It has been a while that I couldn't write. There have been a lot of changing. The beginning of "Azure Subscription Directory Change Steps." It was most complicated process while you were moving resource between Subscriptions. Your resources must be in the same directory when you decided to migrate resource between Azure Subscriptions. As you know, Azure Service Management Portal has been terminated.

Before you begin, you need some requirements

You must sign in with account that has RBAC Owner access to the subscription and It must be allowed to connect both the current directories

As you can see in the picture, we have permission to manage both subscriptions. If you don't know how to give permission in Azure Subscription, you must read this article. It should have permission in both directory. ( RBAC Owner). If you are sure about giving the permission, you can start to change directory. Please open the Azure Portal that you can click on to Subscription Tab. Select the subscription which you want to change.

In this picture, you must focus on to redline because there is a tip. If you choose the change directory button, it will give a sign about the beginning of a process named directory change. After you clicked, Thus, you can decide which directory will has a permission to change your subscription. In this way you can be able to move your resources between subscriptions.

When you change the subscription, it is just a directory level operation so it doesn't affect the other status. ( Billing, Account Admin. ) If you want to delete old directory, you must transfer the subscription to billing ownership to get a new Account Admin.

Now, you are able to move your resource between your subscriptions. I want to add a short note. Formerly, You won't complete this process easily because you will see too many steps