Skip to main content

76 posts tagged with "PowerShell"

View All Tags

· 5 min read
Hasan Gural

There are several ways to connect Azure Subscriptions. Before, we were using VPN gateway for connecting different subscriptions Virtual Network to Virtual Network. We can use VNet Peering to connect virtual networks in the same Azure region or different Azure regions. The virtual networks can be in the same Azure subscription or in different subscriptions, as long as they share the same Azure AD tenant. Also now, we can use VNet Peering to connect different Azure AD Tenants. VNet Peering also allows you to connect two virtual networks created by using different deployment models. In this article, I'm going to explain how can we implement VNet Peering across different Azure Active Directory Tenants.

Before we start this article, what exactly we need to implement for this feature. We can configure VNet Peering by using the Azure portal, Azure PowerShell, Azure CLI and also Azure Resource Manager templates.

As you can see the above picture, need requirements which will be used for VNet Peering to connect Azure subscriptions.

Contents of this article;

  • Clarify VNet to VNet Peering
  • Creating and Configure VNet in the CompanyA with Powershell
  • Creating and Configure VNet in the CompanyB with Powershell
  • Configuring VNet Peering for each Virtual Network.
  • Conclusion

Clarify VNet to VNet Peering

As we mentioned before, If you want to use VNet peering for your project or production environments, you can find below requirements which should have for each user.

  • At least one user who has got access on all subscription.
  • If you want to use multiple users for each subscription, each user should have to reach all subscriptions
  • Users should verify to access each subscription on the different Azure AD Tenants.
  • Take notes subscriptions.

In this article, I'm going to use just one user which has got permission for each subscription. On the best practices case, you should use specific users which have got permission for each subscription. Note that, in this article, we use the AZ Powershell Module which is new.

Creating and Configure VNet in the Company-A with Powershell

Now I have one user and it has permission for each subscription which placed different tenants. We are going to build new infrastructure resources because I want to show you step by step how can we manage this action. In this example, we have two companies. We call them Company-A and Company-B. The first Step is needed to login Powershell with the accessed user. Thereafter, We will create new resources, Virtual Network. We will do these actions each subscription. Because As I said before, we will be created new infrastructure resources.

Connect to Azure Connect-AzAccount

Create Resource Group for Company-A

New-AzResourceGroup -Name "RG-Company-A" -Location "West Europe" -Tag @{Company="A"}

# Create Virtual Network for Company-B

New-AzVirtualNetwork -Name "companyA-VNET" `
-ResourceGroupName "RG-Company-A" `
-AddressPrefix "192.168.10.0/24" `
-Location 'West Europe' -Tag @{Company="A"}

As you can see the results say us, we have executed our command lets for creating Resource Group, Virtual Network. We did all the steps into the Company-A Subscription.

Creating and Configure VNet in the Company-B with Powershell

Now we can log in to "Company-B Subscription". We are creating same resources which are Resource Group and Virtual Network. Afterwards, now we are ready to peer two different Virtual Network.

# Create Resource Group for Company-A

New-AzResourceGroup -Name "RG-Company-B" -Location "West Europe" -Tag @{Company="B"}

# Create Virtual Network for Company-B

New-AzVirtualNetwork -Name "companyA-VNET" `
-ResourceGroupName "RG-Company-B" `
-AddressPrefix "10.10.10.0/24" `
-Location 'West Europe' -Tag @{Company="B"}

As you can see clearly, we have created Resource Group and Virtual Network on each subscription. Now can skip configuring VNet to VNet Peering steps. I think that it is the easiest way to implement Azure subscriptions which placed on different Azure Active Directory Tenant.

Configuring VNet Peering for each Virtual Network.

We are going to use two command-lets which are "Get-AzureRmVirtualNetwork" and "Add-AzureRmVirtualNetworkPeering". Also As we said before, we have to take a note each subscription Id. Because We will use them into the Powershell Command-Lets.

# Peer company-A-VirtualNetwork to company-B-VirtualNetwork
# Select Company-A Subscription - Select-AZSubscription.

$vNetA = Get-AZVirtualNetwork -Name companyB-VNET -ResourceGroupName RG-Company-B

Add-AZVirtualNetworkPeering \`
-Name 'companyA-VNET' \`
-VirtualNetwork $vNetA \`
-RemoteVirtualNetworkId "/subscriptions/26e1b27f-\*\*\*\*\*\*\*\*8829-cacfc62/resourceGroups/RG-Company-A/providers/Microsoft.Network/virtualNetworks/companyA-VNET"

In the script lines, I did mention red lines which should be referred to Resource Group, Virtual Network, and SubscriptionId. We should use the above script for Company-A side. You have to execute the same scripts for the company-B site before you should be sure using "Company-B". If you used to the same script for the Company-B side now we can test peering connections status. Also, you can see the above picture, "PeeringState" column which explains to us peering status.

Conclusion

End of the article, we are going to test what is connection status for VNet Peering. There are two ways to control status VNet Peering. As you may know, the first one is Azure Portal also we can check with Powershell Command Lets. We used to Powershell Scripts for VNet Peering because Azure Portal does not support this implementation. You can see the below picture two ways.

· 3 min read
Hasan Gural

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.

Yukarıda görüleceği gibi basit bir haliyle mevcut imaj için tanımladığımız JSON dosyamızın son bölümüne, 'Provisioners' adında yeni bir nitelik tanımladım ve artık bunun içerisinden Powershell, Shell gibi komut satırları aracılığı ile istediğimi yapabileceğim. İstediğim derken? Hayal gücünüze kalan bir detay burası, tamamıyla size ait, isterseniz, bir Web Server install edebilir, isterseniz Scale Set kullanıyorsanız, Scale Set sonrası image içerisinde yapılması gerekenleri script içerisinde yazarak hızlı bir şekilde image haline getirebilirsiniz. Şimdi ise basit bir Powershell Script tanımlaması yapalım ve neler olduğunu görelim.

Kırmızı alan içerisine aldığım satırlarda örnek olması için Provisioners bölümünü ekledim ve 'type' olarak Powershell yazdım. Tekrar söylemek gerekirse, Provisioners olmadan bir imaj yaratmanız neredeyse imkansız, biz Builders içerisinde Microsoft kütüphanesi içerisinden hazır bir imajdan faydalandık. Fakat bizim için sadece clean bir Windows Server vermekte, fakat biz bunun üzerine bir ihtiyacımız olan kısmı ekleyerek imajımızı kurumumuza göre geliştirebiliriz. Şimdi sizinle bir Powershell Script dosyası oluşturup içerisine birkaç satır yazacağız. Bunun amacı tamamen image içerisine yapılması gerekenleri belirtmek. Örneğin bu image'ın adını WebServerIIS olarka vermiş idik ve anlamlı hale gelmesi için Windows Server içerisindeki IIS ve birkaç daha features ekleyecek script geliştirelim.

Features.ps1 isimli bir script geliştirdik. Şimdi bu Script içerisinde Windows firewall kapatmak için bir cmdlet yazdık ve bununla beraber Windows Server Feature aracılığı ile" Web-Server, Telnet-Client" vd role ve features kurulumunu yapması için gerekli Powershell Script yazdık. Peki şimdi bunu mevcut image template içerisine nasıl koyacağız. Bir önceki resim içerisinde bir Powershell satırlarını direk template içerisine yazmıştık. Şimdi ise bizim Powershell Scriptimizi ekleyeceğiz. Bunun için hemen template içerisine belirleyelim.

Yukarıdaki resim içerisinde görüleceği üzere, yeni bir satır ekleyerek Powershell ve mevcut scriptimizi tanımlamasını yaptık. Sizinle beraber yazmaya başladığımız bu Image dosyası ( JSON) oldukça karmaşık ve istediğimiz seviyelere geldi. Bir sonraki yazımızda packer aracının kullanım şeklini ve nasıl çalıştığına değiniyor olacağız.

· 4 min read
Hasan Gural

Packer, HashiCorp tarafından sunulan tek bir kaynak konfigürasyonı ile birden fazla farklı platformlar için Virtual Machine veya konteyner imajları oluşturmak için kullanılan bir araçtır. Bu yazı serisinde Azure özelinde custom image'lerin nasıl oluşturulacağını açıklayacağım ancak önce Packer nedir kendisi tanıyalım. Kısacası Packer, Microsoft Azure'da spesific image oluşturmak, tanımlamak için kullanılabilen açık kaynaklı bir araçtır. HashiCorp tarafından bizlere sunulan bu araç ile Ansible, Powershell DSC etc. İle birlikte kullandığınız zaman Infrastructure as code yönetimini başka bir boyuta taşıyor olacaksınız. MsHowto üzerinde bulabileceğiniz, Mustafa Kara tarafından yazılan Ansible yazı serisi okumanızı tavsiye ederim. Packer, birden fazla platformda çalışır, Bu yazı serisinde Microsoft Azure üzerinde custom image'ler oluşturmak ve saklamak için örnekler gerçekleştirip, Packer'in Azure Resource Manager (ARM) bütünleşip, Azure Managed Image ile harika ve sorunsuz bir uyum içinde çalıştığına şahit olacaksınız.

Öncelike yazı serimize başlamadan önce, sürecin nasıl ilerleyeceğini aşağıdaki adımlar ile özetleyelim. Bu örnek senaryo içerisinde Windows Server bir image oluşturup içerisinde Web Server hizmetini aktif hale getireceğiz. Neden ve niçin böyle bir senaryo yaptığımızı ilerleyen kısımlarda anlatacağım. Sırasıyla adımlara göz gezdirelim.

  1. ) Packer aracının yüklenecek. ( HashiCorp sayfasından elde edilebilir.)
  2. ) Azure Active Directory Hizmet üzerinde Service Principal Name oluşturulacak.
  3. ) Mevcut bir Azure Marketplace içerisinde bulunan OS imajı referans alınıp, özelleştirecek ve imaj için şablon kullanılacak. Bu şablon JSON formatında olacak.
  4. ) Imaj oluşturmak için JSON formatı belirtilen nitelikler sayesinde imaj oluşturun (İhtiyaç duyduğunuzda deploy edilebilir durumda sizi bekliyor olacak.)
  5. ) Packer ile ilk imaj oluşturma sonrası test amaçlı deploy üzerinden yeni bir VM deploy ederek sonucu görmek.

Packer Edinme ve detaylı dökümantasyon için HasciCorp sayfası bizlere çok güzel ve detaylı açıklamalar vermektedir. Packer edinmek için şu sayfa üzerinden ilgili 'Packer.exe' indirebilirsiniz. Download Link : https://www.packer.io/downloads.html

Packer aracını artık edindik ve bir sonraki adımımıza geçebiliriz, bunun için Azure Active Directory üzerinden Service Principal oluşturmamı gerekmektedir. Service Principal kısaca, Azure uygulamanız için bir identity tanımlamak veya oluşturmak ve doğal olarak subscription içerisinde yetki alarak işlemler yapmak olarak tanımlayabiliriz, Packer, bir imaj oluştururken Azure aboneliğinizdeki kaynakları oluşturmak ve silmek için bir takım izinlere ihtiyaç duyar. İşte bunların tamamı için, Azure Active Directory üzerinden Service Principal oluşturup Service Principal'a gereken hakları atayarak elde edilir. Bu genellikle tek seferlik bir şeydir, bu adımı bir kez yaparsınız ve yeni bir imaj oluşturmak istediğinizde Service Principal'ı yeniden kullanırsınız.

Bu işlemleri için süreci kolaylaştırmak adına sizinle bir script paylaşıyor olacağım. Bu sizin için koaly ve hızlı bir şekilde yeni bir Service Principal oluşturmanızı sağlayacak. Makale serisi boyunca, tüm yazdığım kod bloklarının hepsini Visual Studio Code üzerinden gerçekleştiyor olacağım. Bu yüzden Visual Studio Code üzerinde bulunan çalışma dosyamın hepsini son seride indirebilir olacaksınız.

Yukarıda çalıştırdığım "MsHowto-PackerPrep.ps1" adlı Powershell Scripti sayesinde Azure Active Directory üzerinden Service Principal oluşturma işlemini tamamladık, Ekranı ortadan ikiye böldüm, sol tarafta Powershell Script içerisindeki satırlar içerisinde yaptığımız adımları özetlemek gerekirse, Bir takım değerleri parametrik hale getirerek, Resource Group Name, Location, Image Name, Role Assignment ve Service Principal Password gibi değerleri istediğiniz gibi değiştirebilirsiniz. Script çalıştıktan sonra, Ekranından sağ tarafında en alta bulunan yeşil alan içerisinde, oluşan Service Principal Name için, tüm detayları görebilirisiniz, gizlilik açısından bazı alanları ben kapattım, siz çalıştırdığınıza size özel değerler üretecektir. Bu değerli daha sonra Packer ile oluşturmak istediğimiz image için geliştireceğimiz JSON içerisine yazıyor olacağız. Bu değerleri not alalım ve saklayalım. Ayrıca yukarıda yaptığımız tüm işlemleri isterseniz Azure CLI ile yapma şansına sahipsiniz, bu yüzden tamamen sizin tercihiniz.

Makalemizin adımlarına tekrar baktığımızda Packer ve Azure Active Directory üzerinde, Packer özelinde bir adet Service Principal oluşturma sürecini tamamladık. Visual Studio Code içerisinde görebildiğiniz üzere projemin içerisinde 'Packer.exe' görebilirsiniz.Şimdi ise proje dosyam içerisinde imaj dosyamı tanımlamak için bir adet JSON dosyası oluşturup bir takım tanımlamalar yapacağız ve bunları tek tek açıklamaya çalışacağım. Makale boyunca kullanacağım JSON dosyasının adı, "packerimage.json" olarak kullanmaya özen göstereceğim ve bunun yazım şeklinden tutun ne gibi özellikler göndererek kullandığımıza değineceğim.

Yukarıda görüldüğü üzere packerimage.json adında bir dosya oluşturdum ve içerisinde bir JSON formatında key-value şeklinde tanımlamalar yaptım fakat JSON formatından anlıyacağınız gibi, ikinci satırda görebileceğiniz üzere Variable nesnesinin alt kısmına bir takım key-value şeklinde tanımlamlar yaptım ve bu tanımların hepsi değişken olarak JSON dosyasının ilerleyen aşamalarında kullanılıyor olacak. Bu tanımlamalar içerisindeki tüm satırları nasıl dolduracağımızı bir sonraki yazımda bulabilirsiniz.

· 3 min read
Hasan Gural

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.

Yukarıda gördüğünüz beyaz alan içerisinde tüm istenilen key-value ilişkisi içerisindeki değerleri doldurdum. Packer kendi içinde Azure ARM API üzerinden istek yaptığı zaman Service Principal kullanarak yani ClientId ve ClientSecret ile erişim sağlayıp, ilgili subscriptipon üzerinde işlemlere başlayacak. Şimdi JSON dosyası içerisinde geliştirmelere devam edeceğiz. Bir özellik daha ekleyeceğiz JSON içerisine ve bu sefer adı 'Builders olacak ve alt kısmına 'Builders bize sunduğu özellikleri girebileceğiz. Basit haliyle Builders ne iş yapar derseniz, çeşitli platformlar için sanal makineler oluşturup bunlardan image üretmekten sorumludur. Örneğin, EC2, VMware, Azure, Citrix, VirtualBox, vb. İçin ayrı geliştiriciler vardır. Packer, varsayılan olarak birçok üretici ile birlikte gelir ve ayrıca yeni geliştiriciler eklemek için geliştirelebilir ve geliştirilebilir.

Şimdi ise Builders için bir tanımlama yapalım ve nasıl kullanıldığını anlamaya çalışalım. Öncelikle 'builders' tanımlaması aşağıdaki gibi yapılmaktadır.

Yukarıda görüldüğü gibi 'Builders' nesne içerisine oluşturacağımız image için gerekli key-value değerleri girebiliriz. Bu kısımda anlaşılacağı gibi benim gireceğim değerleri nereden öğreneceğinizi merak ediyorsanız, bunun için Packer sayfasını ziyaret edebilirsiniz. Takdir ederseniz her hizmet sağlayıcısının ( Azure, AWS, Vmware, Hyper vd ) hepsinin kendine özel terimleri ve adlandırmaları var. Bu yüzden bunları key – value şeklinde tanımlarken, reference alabileceğiniz tek sayfa Packer Builders sayfası olacaktır. Şimdi ise, Azure için örnek bir 'builders' tanımlarını inceleyelim.

Artık 'Builders' içerisine yaptığımız tanımlamaları görmektesiniz. Aslında çok zor ve anlaşılmayacak bir tarafı yok. Hemen 'Builders' tanımın altında "Type' ( 13.Satır ) yazan kısımda hangi provider için kullanacağımızı belirtmek zorundayız. Bunun sebebi yazımızın başında söylediğimiz gibi, Packer birçok provider üzerinde image yönetimini destekliyor. Turkuaz alan içerisine aldığım 15 – 20 satır arasına dikkat ettiğinizde, Variables Nesne içerisinden onları değişken şekliden çağırıp kullandık. Aslında JSON dosyasımızın ilk kısmında, Variable alanları tanıtıp, 'Builders' içerisinde kullandık. En son olan kırmızı bölgemizde satır 22 – 40 arasındaki alan ise Packer sayfası üzerinden image yönetimini için gerekli tanımlamalar olarak söyleyebiliriz. Bu tanımlamalar olmadan herhangi bir yönetilen imaj oluşturma şansınız yok. Bu kısımda, 'Azure Tags' nesnesinin karşına key-value olarak bir takım Tagler tanımladım. Bunlarıda kaynak için atamasını yapıyor olacak. Bunun dışında imaj özelinde yaptığımız tanımlaların karşısındaki değerlere baktığınız zaman sizde çok kolay bir şekilde anlayacaksınız. Bunlar sırasıyla, "ImageSku,ImagePublisher,Image_Offer" gibi değerler, bunun yanı sıra, WinRM gibi hizmetlerin açılması ve tanımlamaları yaptım. Son olarak size makine boyutu ve region detaylarını belirttik.

Aşağıdaki ekran görüntüsünde, Packer sayfasından bir alıntı yapmak istedim. Bu görüntü içerisinde sizlere Packer sayfası üzerinde ne kadar basit bir şekilde yapmanız gerektiğini anlatıyor. Bir çok insan image yönetimini klasik ya da alıştıkları yöntemler ile yapmakta ısrarcı davranıyor. Mevcut kuralları yıkmak gerçekten çok zor, kurum kültürü organizasyon hareketleri malasef bu değişikliğe çok çabuk izin vermiyor. Ama makalemizin ilerleyen kısımlarında, Packer'ın yeteneklerine alışacağınıza inanıyorum.

Bir sonraki yazımızda, Packer için farklı bir konu olan "Provisioners" adlı kısmı inceleyeceğiz. Burası benim en çok sevdiğim ve neler yapabileceğimizi tamamen kavracağımız nokta olarak söyleyebilirim.

· 3 min read
Hasan Gural

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.

Gerçekten yazılan kodun gereksinimlerini karşılıyor muyuz? veya Geliştirilen tüm scriptlerin yaptıkları şeyleri bize nasıl kanıtlarsın? Günün sonunda evet sistem tarafında aksiyon aldığını göreceksiniz fakat yine bunların testlerinin yapılması ve başkası tarafından bu testlere ulaşılması gerekmektedir.

Pester Nedir?

Öncelikle modülün detaylarına girmeden önce, herkesin ortak bir noktası olacaktır. Yazılan tüm Powershell kodları test ediyorum veya ediyorsunuz. Ama aslında sizin test etmeniz önemli olduğu kadar, bu test sürecinizi otomatikleştirmeniz gerekmektedir. İşte bu noktada Pester Powershell Modülü yardımımıza koşmaktadır. Benim gördüğüm hali hazırda bir çok büyük firmaların hepsi hala test süreçlerini manuel bir şekilde gerçekleştirmektedirler. Ufak çaplı yazılan Powershell Scriptlerinde sorun yok, oldukça kısa ve sürec kolay bitiyor olabilir. Fakat ya çok uzun ve iç içe Powershel scriptler veya Powershell Modüle kullananlar ne yapacak?

Pester, PowerShell ile yazılan ve PowerShell için bir test framework'ü olarak tasarlanmış bir open-source tabanlı bir projedir. Open-source olduğu için source code gözden geçirebilir, hatta katkıda bulunabilirsiniz. Bütün projeyi GitHub'da bulabilirsiniz. Kısacası Pester'i kullanarak, PowerShell kodunuzu test etmek, PowerShell komutlarının PowerShell içinden yürütülmesi ve doğrulanması için birim testlerini çalıştırmak için bir framework sağlar. Kod yazılmadan önce test senaryolarımızın yazılması ve tüm yapılacak senaryolara ve süreçleri dahil ederek kodun yazılması ve tekrardan düzenlenebilmesi tekniğine kısacası TDD diyoruz. TDD kültürü, yaklaşımını bize Powershell Pester Modülü kazandırmaktadır.

Pester, Powershell Version 2.x'dan 5.x' a kadar Windows 10,8,7, Vista ve Server 2003'a kadar desteklemektedir. Pester ayrıca, Windows 10 ile built-in gelen neredeyse sayılı open-source araçlardan biri diyebilirim. Ayrıca Powershell Core 6.0 ile Windows, Linux ve MacOS desteği vardır bazı limitler ile beraber.

Pester Modülü Nasıl Kurulur?

Bildiğiniz gibi Powershell Package Management Modülünün bize verdiği yetenek sayesinde artık Powershell Modüllerimizi Repository üzerinden indirebilir durumdayız. Yukarıda belirtiğim gibi Windows 10'da direk pre-installed olarak gelmekte fakat modül devamlı geliştiği için bizlere update etmeyi önermektedir. Aşağıdaki Cmdlet bizlere yardımcı olacaktır.

Module başarılı bir şekilde kurulmuş olacaktır. Şimdi ise Module ile gelen komutları listeleyelim, ve hepsine bir göz gezdirelim.

"Get-Command – Module Pester" yazarak module ile gelen tüm komutları listelemiş olduk. Şimdi ise, Cmdlet baktığımızta, bir çoğunun tek bir kelime ile yazıldığını göreceksiniz. Normalde Powershell üzerinde tüm Scriptler, Functionlar Verb-Noun olarak tasarlanmışlardır. Bu kısımda kullanırken biraz değişik gelebiliyor ama zamanla alışacaksınız, sebebi ise çok basit kullanım şekilde olması ve tek amaç için. Örneğin "Describe ve It, Should" bunlar zaten hemen hemen hakim olduğumuz kelimeler.

Bir sonraki yazımıda artık Pester ile Powershell Code'larımızın test süreçlerini nasıl otomatize ettiğimize değineceğim.

· 3 min read
Hasan Gural

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.

"Get-Month" adında bir Powershell fonksiyonu geliştirdim. Bu fonksiyon bize bir yıl içerisinde bulunan ayları geri dönüyor olacak. Parametrik olarak vererek ise tüm aylar arasında filtreleme yapabilme şansınız var. Şimdi ise Pester içerisinde bulunan komutları tanıyalım ve görelim. Öncelikle 'Describe' ile başlayalım. Describe bize, test etmek istediğiniz Powershell Script Block başlangıcı sağlar. Örnek kullanım şekli aşağıdaki gibidir.

Yukarıda görüldüğü gibi, Test sürecinin başlaması için 'Describe' fonksiyonu ile tanımlamayı yapıyoruz. Yani Pester ile Test sürecine başlamak için 'Describe' ile ilk tanımınızı yapıp Script block (süslü parantez) ile tamamlıyorsunuz. Peki daha sonra ne yapmamız gerekiyor, artık test'e başlamak için bir isim verdik. Ama hangi testlerden geçmesi gerektiğine düşünüp yazmaya karar verdik. Bunun için ise devreye Pester Modülü içerisinde olan 'It' fonksiyonu giriyor olacak. 'It' fonksiyonu öncesi istersen 'Context' adında bir fonksiyon daha çağrıp extra yapacağımız testlere isim verebiliriz. Aşağıda bulunan örnekte detaylara bakalım.

Öncelikle, daha öncede söylediğimiz gibi bütün Powershell Pester Testleriniz kesinlikle Describe bloğuna sahip olmalıdır, Describe bloğu diyorum çünkü bildiğiniz gibi zaten kendiniz bir cmdlet-powershell function olarak kullanıyoruz. Aynı şekilde diğerleri 'It', 'Context'. Basit olarak bu Script blockları arasına istediğinizi yazmakta özgürsünüz. Şimdi ise geliştirdiğimiz function üzerinden hemen bir test süreci yazalım ve tekrar üzerinden beraber okuyalım.

Script satırlarına bakıldığı zaman aklımızda olan satırları tek tek inceleyelim. Öncelikle 'Describe ve Context' neden yazdığımızı anladık. Zaten çok basit bir şekilde gözlemleyebiliyoruz. Fakat 'It' script block kısmı dilediğimizi özgürce yazdığımız kısım idi. Daha doğrusu test süreçlerimizi adım adım belirttiğimiz yer. Ben kolay ve anlaşılabilir olması için, iki adet 'It' script block içerisinde bir takım kontroller yazdım. Bu kısımdaki kontrollerimize hızlı bir şekilde dikkat edelim. Yazdığımız fonksiyon bize yıl içerisindeki tüm ayları geri döndürüyor ve bununla beraber parametre alarak eğer gönderilen parametre değerinde bir değer belirtilmiş ise bu ve bu değer herhangi bir ay ile match edilir durumda ise sadece o ay bilgisini bize geri döndürüyor. Fonksiyon içerisinde yaptığımız işlemlerin bir kısmını Pester ile kontrol etmeye çalıştık. Bunlar neler kısaca,

  • Bütün aylar toplam sayısı – 12'ye eşit olmalı.
  • Gönderilen parametre değeri eğer ayarlar içerisinde herhangi bir değer ile match olmuyorsa.
  • ( Devamı eklenebilinir. 'It' script blockları ile belirtebilirsiniz.)

Artık tüm adımlarımızı yazdığınızı varsayalım ve test sürecine geçelim. Bu kısımda yazdığımız Pester – Powershell Script kaydediyoruz. Test sürecinin nasıl çalıştığını ve ilerlediğini anlamak için devreye 'Invoke-Pester' adında bir cmdlet çıkmaktadır. Bu Cmdlet içerisine parametrik olarak mevcut Powershell Pester-Test Scriptinizi gönderip sonuçları görebilirsiniz. Aşağıdaki detaylara beraber bakalım.

Invoke-Pester isimli cmdlet içerisine '.\Pester.ps1' yazmış olduğu script'imi gönderdim ve çalıştırdığım zaman bir sonuç ekranı çıkardı. İşte bu ekran üzerinde hangi test sürecinin ne kadar süre sürdüğünü, hangi test sürecinin başarılı olduğunu veya başarısız olduğunu anlayabilirsiniz. Son olarak ise tüm bu sürecin bütün halinin detaylarını son satır detayında görebiliyorsunuz. Sizde artık tüm scriptlerinizdeki test süreçlerinizi Powershell – Pester Module ile kolay bir şekilde gerçekleştirebilirsiniz.

· 4 min read
Hasan Gural

Before reading the article, you have to know that I'm not going to explain what are Docker and Container etc. On the internet, you may be able to find a lot of article series to understand Container and Docker structure. Basically, in this one, we will comprehend how can we create docker host on Azure via Docker Machine CLI. I could say, One brief (and incomplete) description is that Docker creates something similar to Virtual Machines, only that Docker containers run on the host machine's OS, rather than on a VM. Each Docker container should ideally contain one service and an application can comprise multiple containers.

As you know, when you install the docker on your machine, it provides command line interface for using and managing your docker hosts. Docker Machine supports to create new docker hosts also contains a lot of parameters when its a deployed which that is why I'm using Docker-Machine CLI to launch new docker host on my hypervisor. I've been testing the deployment of a new docker host on various platform such as Linux, Windows. It gives the easiest way to create new docker hosts. For instance, you are testing your container on your docker host and you want to scale your application. You want to involve your docker application in cluster environments. Also, you may need getting a new docker host to create cluster environments. Here it is, an easy way to get new docker host using Docker-Machine CLI and join to your cluster environments. Before we start, you can find requirements for creating new docker hosts.

Before you begin, you need to know your subscription-Id which will be used by docker-machine. Here it is, the easiest way to find your Azure subscription Id.

After running these lines, you will get your subscription id and to keep it. Because we will use it when we are using docker-machine cli. You can find below.

Create new docker host on Microsoft Azure

We are going to learn Docker-Machine CLI and what are its parameters also how can we use it. We should know Docker-Machine CLI parameters and what type of parameters need to use. Docker-Machine CLI uses 'create' and 'driver' options when we are creating new docker host on Azure After that we remark these commands, it will give you chance to use some operational parameters.I have added the detail of parameters of Docker-Machine CLI.

As you can see the above on the picture just one line is red. It means the parameter should not be blank. Let's have a look example of docker-machine create command.

docker-machine create --driver azure ` --azure-subscription-id $SubscriptionId[0] ` --azure-subnet-prefix 192.168.10.0/24 ` --azure-open-port 22 ` --azure-private-ip-address 192.168.10.10 ` --azure-resource-group 'RG-DockerNodes' ` --azure-location 'West Europe' ` 'dockernode-azure'

As you see above, the picture shows an example of Docker-Machine CLI parameters. The first parameter should have to be your provider. As you know, our provider's is Azure. We can put this line 'Azure'. However, Second Line should not be blank or null, you know this parameter is required. Because we have to remark our subscription Id which will be placed our resources. Let's complete our docker machine commands.

I have executed Docker-Machine Command which is in the above picture. So, It did create a new Docker Host on Azure. Now, We can manage our new docker host with Docker-Machine CLI like we can create a container, network etc. Here is screenshot of our new docker host on Azure that I wanted to show you.

On the Azure Portal, we can see our new docker host. Let's now we can get details of the node on Docker-Machine CLI. For these details, we should use Docker-Machine ls command.

In this article, we have done to create new docker host on Azure. We have a lot of ways to create a new one. We have selected to create with Docker Machine CLI. For Azure perspective, we can use Powershell, Template Deployment.

· 2 min read
Hasan Gural

Bir süredir zamanımın büyük bir bölümünü docker ile container yönetimine harcamaktayım. Gün içerisinde zamanımın çoğunu docker-compose, docker image yazarak ve bunları VSTS ile buluşturmama rağmen yine bir şekilde "Docker command line" ihtiyaç duymaktan alı koyamıyorsunuz. Tüm süreçlerin sonunda kendinizde test edip görmek istiyorsunuz. Fakat bu Docker command line benim gibi Powershell üzerinden erişip ve tab completion yapmak isterseniz, yardımımıza tam bu noktada GitHub üzerinden keşfettiğim güzel bir Powershell Module koşmaktadır. Eğer sizde çok fazla DockerCLI üzerinden, Network, Container, Image yönetimi yapıyorsanız ve bunların tab completion özelliğini kullanmak isterseniz, bu module tam size göre.

Posh-Docker Module GitHub üzerinde kullanıma açılmış yaklaşık en son iki yıl önce güncelleme yapılmış, fakat gayet yeterli bir şekilde işinizi göreceğine eminim. Client tarafında ön gereksinimleri aşağıda gibidir.

  1. Docker CLI 1.3 veya daha üst versiyonu
  2. Powershell 5.0 veya daha üst versiyonu

Bildiğiniz gibi Powershell ile Powershell Modüllerini PS Gallery sayesinde daha doğrusu Powershell One Get aracılığı ile repository üzerinden indirebiliyoruz, Posh-Docker bu şekilde sahip olma şansınız var. Bunların en basit yöntemi Install-Module komutuna kurmak istediğiniz Powershell Module adını göndermeniz yeterli olacak. Posh-Docker isimli Powershell Module kurmak istediğimiz için çalıştırmamız gereken komut sadece "Install-Module -Name Posh-Docker"

Posh-Docker isimli Powershell Modulunu kurduktan sonra, hemen bir kontrol gerçekleştirelim. Hızlı bir şekilde yeni bir powershell session açtım ve Get-Module yazarak Posh-Docker modülünü kontrol ediyorum. Yukarıda çalıştırdığımız komut çalıştırılan client üzerindeki tüm kullanıcılara gidecektir. İsterseniz "Install-Module -Name Posh-Docker -Scope CurrentUser" eklediğimiz Scope parametresi ile sadece Cmdlet'i çalıştırdığınız kullanıcının kendi profilin de saklayabilirsiniz. Get-Module cmdlet kullanarka Posh-Docker modulunun yüklenip yüklenmediğini kontrol edebilirsiniz.

Posh-Docker başarıyla yükledikten sonra artık Docker Command Line ( CLI ) içerisindeki tüm komutlara ve parametrelere tab-completion tadını çıkartarak tabiki Powershell üzerinden kolaylıkla erişebilirsiniz. Şunuda unutmayalım ben günlük işlerimde VSCode veya bir console emulator olan CMDER üzeinden Powershell'i kullanmaktayım. Powershell kullandığım sürece, posh-docker benim için tab-completion yapmaya devam edecek, kullanım şekli nasıl eriştiğiniz tamamen size ait.

Hemen bir örnek ile aşağıdaki görelim.

Yukarıdaki kısa bir yapılan örnekte görüldüğü gibi tab-completion kullanımı Docker Command Line kullanımında bize hız ve bazı komutları hatırlamamızda yardımcı olmaktadır. Posh-Docker, Powershell modülüne GitHub sayfasından erişebilirsiniz.

· 3 min read
Hasan Gural

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.

Yukaıdaki script sayesinde gönderdiğimiz parametreler ile YAML-CLI son sürümünü ilgili klasör içerisinde indirdik. Şimdi ise, nasıl kullanıldığına aldığı parametrelere bakalım.

Görüldüğü üzere, YARM-CLI "-input ve -output" adında iki tane parametre alarak gönderdiğiniz YAML veya JSON dosyalarını kendi içerisinde dönüştürmesini sağlayarak Azure Resource Manager Template modeline göre yapmaktadır. Bunun için geliştirdiğiniz YAML formatında Azure Resource Manager Template'ni "-i veya -- input" parametresi ile göndermeniz ve bu YARM-CLI size vereceği JSON dosyasınıda "-o veya –output" olarak belirli bir path gösterek kaydetmesini sağlamanız. Eğer dilerseniz JSON Formatında bir dosyayı input ederek aynı şekilde YAML formatında bir çıktı elde edip aradaki farklılıkları anlayabilirsiniz. Bu işlemi yapmadan önce aşağıdaki JSON ve ARM ile geliştirilen Resource'ların görünüş şekillerine bakalım.

Yukarıdaki resim içerisinde görüldüğü gibi iki farklı formatıda yan yana koydum. Çok basit bir şekilde Resource Template içersinde DNS Zone oluşturmak için gerekli değerler bulunuyor. Bu formatlardan, YAML olan biraz daha okunabilir ve anlaşılabilir olarak gözükmektedir. Şimdi hemen hızlıca bu YAML dosyasının detaylarına inelim, derine baktığımızda aradaki süslü parantezlerin gittiğini ve YAML bize daha kolay bir okunabilir kullanım sağladığını görmekteyiz. Peki, bu YAML dosyasını nasıl elde edebiliriz hemen ona değinelim.

Bunun için YARM-CLI kullanıp "input" parametresine, elimdeki mevcut JSON dosyasını göstermem yeterli olacaktır. Aşağıdaki örnekte beraber bakalım.

YARM-CLI ile çok kolay bir şekilde, JSON template dosyamızı YAML uzantıya dönüştürdük. Artık YAML üzerinden geliştirmeye devam edebilir veya genel hatlarıyla nasıl yazıldığına aşina olabiliriz. Şimdi ise tam tersini yapalımş aşağıda görmekte olduğunuz kompleks bir Resource Template var. Bu Template YAML formatında yazılmış olsun ve biz bunu JSON dönüştürelim. Neden bu işlemi yapmak zorunda olduğumuzu merak ediyor olabilirsiniz, Azure Resource Manager API üzerinden herhangi bir kaynak deploy ettiğiniz zaman bunu JSON template ile göndermeniz lazım. Bunun için Azure Portal üzerinden gösterimini yaptık, aynı şekilde Portal üzerinden, Powershell veya başka hizmetleri kullanarak Deploy başlattığınız zaman bu Resource Template kesinlikle JSON formatında olmalıdır. Bu tarafta dilerseniz YAML ile yazıp JSON dönüştürüp bunu otomatik hale getirebilirsiniz, Fikir vermesi açısından Bkz : Azure DevOps Stage.

Yukarıdaki kısa görüntüde görüldüğü üzere, çok kolay bir şekilde dönüştürme işlemini gerçekleştirdik. Bende YAML tarafında çok fazla vakit geçirdiğim için özellikle Docker Compose file yazarken, Azure Resource Manager Template geçiş yaptığımda canımı sıkan bir konuydu. Son olarak, dilerseniz Visual Studio Code üzerinde buluna "YARMtoJSON" extension kullanarakda bu işlemleri yapabilirsiniz.

· 3 min read
Hasan Gural

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.

Yukarıda resimde görüldüğü gibi, Azure Resource Manager Template ulaşmanın birkaç yolunu göstermeye çalıştım. Bu iki yöntem ile ve birkaç kaynak ile JSON Template ( Azure Resource Manager Deployment ) nasıl olduğu hakkında birkaç fikriniz olacaktır. Fakat bu konu oldukça derin ve çok büyük kurumlarda bu tarz süreçler, CI/CD kadar bağlanıp Jenkis, Azure DevOps ( VSTS) üzerinden yönetelir hale geldiler, konu sadece JSON Template yazıp onu deploy etmek değil, yazılan template içerisinde gelebilecek parametreler, variable ve function gibi detaylar var. Bunların kontrolünüde Pester adında başka bir open-source araç ile kontrol ediyoruz ki bu çok başka bir konu, başka yazımızda değinmeye çalışırız.

Esas konumuza gelecek olursa, belirli bir süredir Microsoft feedback sayfasında gördüğüm ve gerçekten çok mantıklı ve benim bile hergün kullanmama rağmen aklıma gelmeyen "zihni-sinir" başlıklar yer almakta, eğer teknolojiyi yakın takip ediyorsanız orada yazılan feedbackler gerçekten harika, sizde bir not bırakın derim. Bir süredir, JSON Template okuması zorlayıcı olması, çok fazla süslü parantezler iç içe girmesi bir kısımdan sonra çileye dönüşüyor, çok uzu deployment süreçlerinden bahsediyorum. Ansible kullanan biri olarak YAML formatı gerçekten daha okunaklı ve daha göze yakın duruyor, JSON severler olmaz öyle şey diyebilirler, fakat YAML formatını kullanarak Azure Resource Manager Deployment yapabilsek çokta güzel olmaz mıydı diye düşünürken bir open-source araç keşfetmem ile güzel bir ışık yandı zihnimde.

Özetle, "YAML CLI" adında open-source olan harika tool sayesinde YAML formatında geliştirilen Azure Resource Manager templatelerini nasıl JSON convert edebileceğimizi göreceğiz bu yazı serimizde. Microsoft bunu ne zaman offical olarak destekler/desteklemez bilemiyorum fakat görünüz açısından gözünüzün alışacağından eminim. JSON ile geliştirilen template ile hiçbir farkı olmayıp sadece süslü parantezlerden kurtulduğunuzu hayal edin, yukarıdaki resimde içerisinde zaten anlaşılır ama kompleks deployment modellerinden içinden çıkılmayan bir hal alıyor malasef, evet intellisense diye bir şey var kabul ediyorum fakat YAML ile geliştirmek çok daha kolaylık sağlayacak.

YAML-CLI Github üzerinden erişebileceğiniz ve kullanımı çok kolay bir araçtır. Aşağıda detaylarını görebilirsiniz, yazımızın devamında bu aracı nasıl kullanacağımıza değineceğim.