Category: Powershell

Packer kullanarak ile Azure üzerinde VM Image Yönetimi – Bölüm 2

Packer ile Azure üzerinde VM image yönetimine devam ediyoruz. Bir önceki yazımızda Service Principal ve Packer tanımlaması için JSON dosya oluşturup Variable tanımlarını yaptık fakat karşılarına değerler girmedik. Şimdi dilerseniz bizden istenilen tanıımlamaları tek tek girelim. Aşağıdaki resim içerisinde göreceğiniz gibi Variables olarak adlandırılan bölümde, Azure Subscription detayları, Service Principal bilgileri ve son olarak oluşturulacak olan image için saklanacak resource group ve image name bilgileri yer almaktadır. Bu bilgileri doldurduktan sonra, daha sonra onları ilerki tanımlamalarda kullanıyor olacağız. Adından anlaşılacağı gibi, bunlar sadece bizim abonelik ve packer için kullanılacak bilgileri içermektedir.



Packer kullanarak ile Azure üzerinde VM Image Yönetimi – Bölüm 3

Packer serimize Provisioners’ ile devam ediyoruz. Packer Image Template’leri içerisinde, ‘Provisioners’ bölümü en çok dikkat çeken kısım olarak karşımıza çıktığını daha önce belirtmiştim. Packer ile oluşturmak istediğiniz imaj için öncesinde içerisinde olmasını istediğiniz yazılımı yüklemek veya işletim sistemini yapılandırmak için kullanması gereken bir özelliktir. Basit olarak bunu kullanmanızda birçok aşama var. Öncelikle bildiğiniz gibi bir imaj alırken, Sysprep önem arz eder, bunun dışında belki o imaj içerisinde belirli bir yazılım olsun, Registry içerisinde şu şekilde bir kayıt olsun, bunu değeri bu olsun, hatta Package Management üzerinden bir yazılım yüklensin gibi her türlü detayı belirtebiliryorsunuz. Öncelikle ‘Provisioners’ isteğe bağlıdır. Bir şablon içinde hiçbir hazırlayıcı tanımlanmamışsa, sonuçta ortaya çıkan makine görüntülerine varsayılanlardan başka hiçbir yazılım yüklenmeyecektir. Bununla birlikte, bu tipik değildir, çünkü Packer’ın değerinin çoğu önceden yapılandırılmış yazılımın çoklu özdeş resimlerini üretmektir. Provisioners genellikle bir Powershell Script, bash script vb. nitelikler ile tanımlanır.



Powershell Scriptlerinizi Test Edin –Pester Modülüne Giriş – Bölüm 2

Yazımızın ilk serisinde neden Powershell – Pester Modülünü kullanmamız gerektiğinden bahsettik. Şimdi ise nasıl kullanmalıyız ve ne tür bir kullanım modeli olduğunu inceleyelim. Basit bir Powershell function geliştirdik ve bunun içerisinde bir takım kod bloklarımız olsun. Aşağıdaki detaylara ufak bir göz gezdirme ile neler yaptığını anlayalım.



Powershell Scriptlerinizi Test Edin – Pester Modülüne Giriş – Bölüm 1

Bildiğiniz gibi, herkes altyapılarını otomatik bir hale getirmek için birçok powershell scriptler yazmakta ve daha sonra bunları bir şekilde otomatik çalışacak hale getirip, devamlı çalışarak birçok iş yükünü azaltmaktadır. Fakat yine herkesin bildiği diğer bir konu ise geliştirilen tüm kodların test edilmesi gerektiğinin önemi. Tüm altyapınızı otomatize ettiniz, fakat test süreçlerinizide otomatize etmeniz gerekiyor. İşte bu yazı serisinde Powershell Modülü olan Pester incelemesini gerçekleştireceğiz.

Günümüzde artık Automation özellikle burayı altını çizerek söylemek istiyorum, Altyapı yönetiminin bel kemiği haline gelmiş durumdadır. DevOps kültürüde bizlere bu kültürün bir parçası olan iyi bir automation stratejisi gerektiğiniden bahseder ve anlatır. PowerShell’in gücünü göz önüne aldığınızda, çalışan bir arkadaşınız veya proje yöneticinizin veya benzer otoritede olan bazı kişiler sizlere temel sorularla size geldiğini hayal edin. Çok basit birkaç soru ile bunları toparlayalım.



Visual Studio Code ile Azure Resource Manager şablonları oluşturma

Bir süredir zamanımın çoğunu Azure Resource Manager Template’leri geliştirerek gelişmiş ve çok karmaşık deploymentlar yapmaktayım. Bu kısımda ilgili Azure Resource Manager Template’lerini geliştirirken benim için ilgili IDE üzerinde konfor ve esneklik sağlaması çok önemli. Azure Resource Manager daha önce nasıl kullanıldığını ve yönetildiğini açıklayan yazıya şu adresten ulaşabilirsiniz. Yazının tarihine baktığım zaman üç yıl önce yazdığımı farkettim fakat yinede güncel başlıklar için Microsoft sayfasından göz gezdirmenizde fayda var.



YAML kullanarak Azure Resource Manager Template Deployment Nasıl Yapılır? – Bölüm 2

Yazımızın ilk serisinde Azure Resource Manager Template dağıtım modelini ( JSON Template ) kullanırken yaşadığımız zorlukları ve JSON formatının göz yoran zorluklarından bahsetmiştim. Şimdi ise, YAML formatını kullanarak geliştireceğimiz Azure Resource Manager Template arasında farklılıklara bakıp daha sonra geliştirdiğimiz YAML template dosyasını tekrar nasıl JSON formatına kolay bir şekilde nasıl dönüştüreceğimizden bahsedeceğim.

Öncelikle YAML-CLI aracını github üzerinden indirelim ve ne tür parametreler göndererek kullanıldığına bakalım. Bunun için aşağıdaki Powershell Script çalıştırabilirsiniz, Script belirli parametreler almaktadır.



YAML kullanarak Azure Resource Manager Template Deployment Nasıl Yapılır? – Bölüm 1

Bu yazı serisine başlamadan önce Azure Resource Manager Template Deployment modelini neden ve niçin kullanıldığını çok iyi anlamamız lazım. Bu yüzden blog üzerinde bunun anlatan yazıları yazmıştım, fakat kısa bir hatırlatma yapmak için kısaca tekar üzerinden geçmek istiyorum. Azure Resource Manager’ın Template Deployment özelliği bize sağladığı en büyük özellik, Infrastructure as code kültürüne ayak uydurmamız ve Azure üzerinde hizmet veren kaynakları devamlı kontrol altında tutup, incremental şekilde değişiklik yapmamıza olanak sağlamaktadır. Çok fazla organizasyon Azure Resource Manager – Template Deployment modeline mevcut ortamlarının template geliştirerek deployment süreçlerini CI/CD içerisine dahil etmektedirler, özetle bu bize JSON formatında sunulan ve Azure üzerinde tüm kaynaklarınızın detaylarını bu template içerisine belirterek çok hızlı bir şekilde deploy edip, aynı şekilde değişen bir şey var mı yok mu diye kontrol altına alabiliyorsunuz, biraz daha farklı bir süreçten örnek vermek gerekirse, DEV/TEST ortamların çoğu Resource Manager Template modeline yazılmış ve deploy edilmeye hazır halde bekliyor. Bu template geliştirmenin bir çok yöntemi var, JSON formatında olan bu dağıtım modeli, Visual Studio Code ve Visual Studio aracılığı ile kolayca geliştirilebilir durumdadır. Dilerseniz Mevcut kaynaklarınızın template detaylarını Azure Portal üzerinden export etme şansınıza sahipsiniz, biraz fikir vermesi için aşağıdaki kısa görüntü size açıklayacaklar.



Access to Azure Cloud Shell from Visual Studio Code

Nowadays, I’m greatly passing the time with Visual Studio Code. I’m a huge fan of Visual Studio code. As you know, Azure Cloud Shell was published a years ago by Microsoft. When the Azure Cloud Shell announced a years ago, I had given a webcast. You can watch that webcast on this link. Azure Cloud Shell has been giving a chance to managing your Azure Resources on web-based support shell. It is supporting Bash and Powershell. In this context, you will be able to manage your resource web-based and you do not need to configure PowerShell module and version. In this article, I’m going to share with you useful feature which is Azure Cloud Shell on Visual Studio Code.



Powershell ile WMI ve CIM Kullanımı – Part 3

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.



Powershell ile WMI ve CIM Kullanımı – Bölüm 2

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.