Bulut Çözümleri ve Ötesi Programı, Bulut bilişim ve bilgi teknolojileri dünyasında yer alan, bu alanlarda danışmanlık yaparak farklı bulut platformlarında kendilerini uzmanlaştırmış profesyonel kişilerin bilgi ve deneyimlerini objektif bir şekilde aktardığı, izleyicisine teknik bilgi vermeyi amaçlayan içeriklerden oluşmaktadır.Video içerikleri; Microsoft, Amazon, DevOps ve Open Source dünyasındaki yenilikleri ve teknik uzmanların deneyimlerini aktarmayı hedeflemektedir. Video serilerinde gerçek senaryolar üzerinden gidilerek, örnek uygulamalar yapılmaktadır. Kullanıcı deneyimlerinden çok ilgili bulut platformlarının sağladığı hizmetlere ilişkin detaylı teknik açıklamalara yer vermek, platformu kurmaktaki en birincil amacımızdır.

Cloud Solutions and Beyond Programme, which is involved in the world of Cloud Informatics and Information Technologies, consists of contents that aim to share the knowledge and experience of experts who have been consultant in these fields but also improved themselves in various cloud platforms or to provide technical informations for its own spectators.The main purpose of the contents is expounding informations and experiences of technical experts in platforms such as Microsoft,Amazon,Vmware and OpenSource. With following real scenarios in video series, instance implementations are being actualized. Rather than the end-user experiences, our first priority is to sharing technical explanations about services provided by the related cloud platforms.

Bu yazı içerisinde Azure Route Table veya diğer adıyla bilnen User-Defined Route Table konusu hakkında detaylı bir şekilde bahsetmek istiyorum. Temel olarak User-Defined Route Table yaratılmasındaki gaye, Azure üzerinde konumlandırdığınız Network Virtual Appliance (WAN Accelator, Firewall ) cihazlarına trafiğin yönlendirilmesine yardımcı olur. Bildiğiniz gibi Azure üzerinde bir Virtual Network oluşturduğunuz zaman bunun yönetimi tamamen Software-Defined Networking olduğunu (SDN) için Microsof tarafından yapılmaktadır. Her oluşturacağınız Address Space, Subnet aynı Virtual Network içerisinde ise doğuştan ( temel olarak ) birbirleriyle haberleşirler.

Öncelikle şunu çok iyi anlayalım. Neden Azure tarafında User-Defined Route tablolarına ihtiyacımız var. Artık birçok şirket artık Azure üzerindeki kaynaklarının İnternet trafiğini inbound veya outbound tamamıyla Network Virtual Appliance üzerine devretmek istiyor. Microsoft Azure bizlere Marketplace üzerinde sunduğu ve desteklediği birçok çözüm var. Bunlar sırasıyla, Fortigate, Juniper, Cisco ve Checkpoint olarak adlandırabiliriz. Bunun yanı sıra Microsoft artık Azure Firewall adında tamamıyla bir firewall as a service hizmeti sunmaktadır. Bu kısımda maliyet yönetim ve esneklik devreye giriyor. Eğer siz third-party bir Network Virtual Applaince kiraladığınız zaman BYOL ve Core başında kullandığınız kadar ödeme modeli çıkmaktadır. Açıkcası bunlar benim kafamda oturtamadığım kadar pahalı gözükmektedir. Tercih meselesi ve ihtiyaçlardan oluşan bir durum işin özeti aslında. Tek bir Network Virtual Appliance koyma şansınız ne yazıkki çok gözükmüyor bu seferde Single Point of Failure kavramına takılıyor olacaksınız. Bu yüzden en az iki adet Availbility Set içerisinde Network Virtual Appliance konumlandırmalısınız ki hizmetiniz kesinti yaşamasın. Bunun dışında SNAT ve DNAT sorunlarına detaylandırıp canınızı hiç sıkmak ve anlatmak istemiyorum, orası yeni yeni Azure Load Balancer tarafında destekleniyor.

User-Defined Route Tables – System Routes Örnekleri​

En basit haliyle, Azure tarafından atanan Virtual Network yönetiminde, Default Routes veya System Routes olarak adlandırabileceğim bir durum var. Bu Route tabloları tamamiyle Microsoft Azure tarafından yönetilir. System Route Table, temel olarak Sanal Sunucular arasındaki trafiği, On-Premises Network Trafiğini ve Internet'e giden trafik içindir. Bunları biraz daha özetlemek gerekirse aşağıdaki maddeleri şu şekilde açabiliriz.

Aynı Subnet içerisinde bulunan Sanal Sunucular Farklı Subnet içerisinde bulunan Sanal Sunucular Sanal sunucu üzerinden internete akan trafik VNet to VNet VPN kullanılarak Sanal Sunucu üzerinden akan trafik VPN Gateway üzerinden geçen Site to Site veya ExpressRoute iletişimi

Örneğin aşağıdaki bu sanal ağı iki alt ağ ile düşünün. Bunlar gördüldüğü üzere Front-End ve Back-end olarak çağrılmaktadır. Bu yüzden bunların tamamıyla yönetimi System Route ( Default Routes) tarafından yönetilmektedir.

Yukarıdaki senaryoyu biraz açmak gerekir ise, Sistem Routes hakkındaki bilgiler Route tablosuna kaydedilir. Route tablosu, paketlerin sanal bir ağda nasıl yönlendirilmesi gerektiğini belirten bir dizi yönlendirme kurallarından oluşmaktadır. Bunun dışında yine bildiğiniz üzere, Azure içerisinde herhagi bir Virtual Machine veya PaaS bir hizmetin belirli bir Next Generation Firewall ( Network Virtual Appliance ) üzerinden geçmesini istiyorsanız, User Defined Route tablolarını kullanmanız gerekmektedir. Bu Route tabloları subnet ile ilişkilendirilir ve subnet içerisinden ayrılan her paket, ilişkili route tablosuna temel alarak veya dayanarak işlenir. Paketler, hedefi kullanarak Route Tabloları eşleştirerek yön verilir. Gönderilen paket bir IP Adresi Aralığı belirtilerek gönderilen paket Virtual Network, Virtual Network Gateway, Virtual Appliance veya Internet olabilir. Eşleşen bir rota bulunamazsa, paket bırakılır.

User-Defined Route Tables Nasıl Oluşturulur?​

Şimdi süreci tekrar gözden geçirelim. Nasıl bir akış içerisinde Route Table tanımlamaları yapılmaktadır. Önce bir Route Table oluşturmalısınız, daha sonra oluşturduğunuz Route Table içerisine tanımlamak istediğiniz 'Routes' (yönlendirme tablolarının) detaylarını girmeniz gerekmektedir. Bu Route Tabloları, belirttiğiniz bir Adress Aralığı için olmalıdır. Örneğin; '192.168.10.0/24' Network üzerine bir trafik gider ise bunu Virtual Appliance yönlendir şeklinde tanımlamalar yapabilirsiniz. Daha farklı yapmak isterseniz, bütün trafiği yine yönlendirmek için '0.0.0.0/0' olarak girilebilir. Azure Portal içerisinden adımları beraber inceleyelim. Portal üzerinde oturum açalım ve 'Route Table' yazarak ilk Route Tablomuzu oluşturalım.

Route Table üzerine tıkladımtan sonra bizlere hangi Resource Group içerisinde oluşturmak istediğinizi ve Region gibi bilgileri soruyor olacak. Bu kısımda dolduracağınız bilgiler tamamen sizin takip ettiğiniz naming convention yapısına bağlıdır.

Create Route Table ekranında karşımıza çıkan alanda BGP Route Propagation kısmı var, bu kısım defauly olarak Enabled olarak gelmektedir. Ama bunun ne tür bir işe yaradığını merak ediyorsanız, en temel hali ile Autonomous System mantığına göre çalışan bir protokoldur. Autonomous System Number aralığı 1 – 65535 e kadar gitmektedir. Bu numaralardan bazıları Azure tarafından defualt olarak kullanılmaktadır. BGP Number temel olarak VPN Gateway üzerinden Active-Active senaryolarında, Express Route kullanıyorsanız ortamınızda BGP de bir hedef networke giderken atlayacağı Autonomous System sayısına inceleyerek ve en verimli olan Autonomous System sayısını kullanarak hedef networke erişmeye çalışacaktır.

Artık Route Table oluşturduğunuz ve içerisine ilk önce bu Route Table hangi subnet tarafından kullanılacak bunun tanımlamasını yapalım.

'Associate' butonuna basarak üzerinde olduğunuz Route Table istediğiniz Virtual Network içerisindeki Subnet bağlayabilirsiniz. Tekrar hatırlatalım, Route Table birden fazla subnet atanabilirler, fakat sadece subnet seviyesinde atama yapabilirsiniz. Bu yüzden bu detaya çok dikkat etmelisiniz, örneğin o subnette birden fazla workload veya başka servisleriniz varsa bu route tablo içerisindeki kurallardan etkilenecektir.

Yukarıda görebileceğiniz üzere Subnet sekmesinde 'Subnet-Internal' isimli Virtual Network içerisinde bulanan Subnet tanımlamasını yaptım. Bundan sonra oluşturacağım tüm Route tabloları için bu 'Subnet-Internal' etkileniyor olacak. Şimdi ise örnek bir route oluşturalım bakalım nasıl gözüküyor olacak. Bu kısma geçmeden önce birkaç detay aktarmak istiyorum. Senaryo gereği, Azure üzerinde bulunan Virtual Network Address Space detaylarımız, '192.168.10.0/24' olarak tanımladım ve istediğim şekilde farklı subnetlere böldüm. Bu kısımdaki tasarım size ait bir konu, bunun dışında yazımızın başında Virtual Network içerisinde bulunan subnetler kendi aralarında native olarak konuşurlar. Bizim yapmak istediğimiz bu örnek üzerinde, 'Subnet-Internal' içerisinden herhangi bir Adress aralığına örneğin, '0.0.0.0/0' bu CIDR notasyonu tüm trafik için belirleyeceğiniz Next Hop tipine göre değişebilir. Şimdi gelin beraber hangi tür tipler karşımıza çıkmaktadır bunlara bakalım.

Virtual appliance: Azure üzerinde konumlandırdığınız ve aynı network içerisinde olan Network Virtual Appliance veya Azure Firewall olabilir. Eğer herhangi bir Next Generation Firewall ( Network Virtual Appliance ) konumlandırması yaptıysanız, ilgili cihazın Network Interface özelliklerinde 'IP Forward' özelliğini açık olduğuna emin olunuz. Temel olarak göstereceğiniz IP Adresi olacak ve Network Virtual Appliance cihazının internal ip adresi olmalıdır. Bu tasarıma göre Azure Internal Load Balancer olabilir.

Virtual Network Gateway: İhtiyacınız göre belirlediğiniz network aralığının Azure Virtual Network Gateway gitmesini yönlendirebilirsiniz. Bu kısımda dikkatli olunması gereken nokta, eğer virtual network gateway VPN – Route Based tipinde ise bunu yapabiliyorsunuz fakat Express Route kullanıyorsanız BGP devreye giriyor ve Route Tabloları işlemiyor.

None:İhtiyacınız göre belirlediğiniz network aralığının Virtual Network içerisinde durdurulmasını sağlayabilirsiniz.

Virtual Network: Bu bölüm odukça önemli aslında biraz Subneting detaylarına kadar gidiyor ama en basit hali ile Virtual Network içerisindeki varsayılan yönlendirmeyi ne zaman geçersiz kılmak istediğinizi belirtin. Bazı durumlardan Network içerisinden tüm paketleri çıkarmak istersen kendi Network içerisinde dönmesi gereken paketleri bırakabilirsiniz. Örneğin yukarıda '0.0.0.0' detayında route örneğinde herşeyin Virtual Appliance üzerine gitmesi tercih etmeyebilirsiniz. ( Kendi Network aralığınız olsa bile, işte bu yüzden Virtual Network tanımı yaparak network içerisinde kalsın deme hakkında sahipsiniz.)

Internet: Tahmin edebileceğiniz gibi istediğiniz adres aralığı için Azure tarafından size sunulan gateway sayesinde internete kavuşabilirsiniz. Bir sonraki yazımıda birkaç route oluşturma örneği portal üzerinden ve Powershell ile gerçekleştireceğiz.

Yazımızın ilk bölümünde temel anlamıyla Route Tablolarını ve ne tür yönlendirmeler yapabileceğimizin üzerinden geçtik. Makalenin sonunu Route Tablosu oluşturma kısmında bitirmiştik. Şimdi ise artık beraber Route Tablosu oluşturalım ve ne tür detayları bizi karşılıyor görelim. Mevcut Route Tablomuzun üzerine gelelim ve Routes sekmesinden Add butonuna basalım ve artık başlayalım.

Add butonuna tıkladıktan sonra, bir takım bilgiler doldurdum. Bunları sırasıyla anlamaya çalışalım.

Route Name: Oluşturacağınız Route isim vermek isteyeceksiniz ve bu isimler daha sonra tanımladığınız routelar içerisinde anlamlı olmalıki karmaşıklığa sebep olmasın.

Address Prefix: Virtual Network içerisinden çıkan herhangi bir trafik bu adres ile ilişkilenir ise Next Hop Type ile belirlediğiniz cihaza, kaynakağa veya network içerisine doğru yönlenecektir.

Next Hop Type – Adress: Bu kısmı bir önceki yazımızda farklı tipler olabileceğini ve ne amaçla kullanıldığını anlattım. Bu örnekte Network üzerinde bir Virtual Network Appliance cihazımıza yönlendirmeyi seçtim. Temel amacım, tüm trafiğin Virtual Network Appliance üzerinden geçmesini sağlamak.

'Tamam' butonu ile oluşturma işlemini tamamladım. Artık Route Table üzerinde gelince özet halinde ne tür User Defined Route tanımlaması yaptığımı görebilir durumdayım.

Yukarıda görüldüğü üzere, 'Subnet-Internal' üzerinden giden herhangi bir trafik network üzerinden Virtual Network Appliance üzerine giriyor olacak ve bu cihaz sayesinde ilgili yerlere yönlendirilmesi yapılıyor olacak. Bu kısımda aklımıza gelen soru, ilgili subnet içerisinde bulunan herkes ortalam 60 saniye içerisinde etkilenmeye başlayacaklardır. Fakat bunu Subnet içerisindeki herhangi bir sanal sunucu nasıl etkilediğini veya sunucunuz arıtk nasıl bir route tablosuna sahip olduğunuzu anlamanız için Azure tarafında sizlere 'Effective Routes' adında bir kısım sunuluyor. Bunun sayesinde, ilgili sunucusunun Network Interface özelliklerinde bu alana giderek sunucu üzerinde hangi Route Tabloları işlenmiş görebilirsiniz. Bu örnek için hemen herhangi bir Network Interface üzerine gidelim ve detaylara beraber göz atalım.

Subnet içerisinde herhangi bir sanal sunucunun Network Interface sekmesine gittiğiniz zaman aşağıdaki gibi bir seçenek göreceksiniz.

Network Interface detayına gittiğimiz zaman 'Effective Routes' kısmında etki eden tüm routes detaylarını görebileceğiz. Fakat bu network kartının herhangi bir sanal sunucuya bağlı olması ve ilgili sanal sunucunun 'Running' durumda olması gerekmektedir. Aksi halde detayları göremeyeceksiniz.

Yukarıdaki gördüğünüz çıktı üzerindeki kırmızı alanda Source sekmesinde 'User' olarak yazan Route detayında bizim tanımladıklarımızı anımsayabilirsiniz. Bu Route tamamen User tarafından tanımlanmış ve Network Interface etki etmiştir. Diğer Default olarak gördükleriniz ise yazımızın başında bahsetmiş olduğum, System – Default Routes olup Azure tarafından yönetilmektedir. Microsoft Azure bizlere, Network içerisinde Routing yapmak istersek bunu bize aşmamız için, Route Tables kullanmamız gerektiğinden bahseder.

Şimdi gördülüğü üzere her süreci Portal üzerinden yaptık fakat yazımızın son kısmını Bonus olarak adlandıracağım ve Powershell ile yapmak isterseniz, aşağıdaki adımları takip ederek başarabilirsiniz.

En temel olan Azure üzerinde oturum açma işlemiyle başlıyoruz. Bunun detaylarını değinmek istemiyorum, blog üzerinden detaylı bir şekilde bulabilirsiniz. Aşağıdaki gibi komutları paylaşıyorum.

#region Login Azure Account
Login-AzureRmAccount 
Select-AzureRmSubscription -Subscription 'e39ba2ed-xx-xx-xx-xx'

#endregion Login Azure Account

Oturum açma işlemini tamamladıktan sonra, sırasıyla sürecimize devam edelim. Sıradaki işimiz yeni bir adet Azure Route Table oluşturmak ve sonuçlarını beraber görelim. Bunun için kullanacağımız değişkenler ve command-lets bulunmaktadır. Lütfen bunların karşısındaki değerlere dikkat ederek çalıştırınız. Özellikle değişken tarafı oldukça önem arz etmektedir.

#region Create User Define Route Table

#region define Variables

$routeTableName     = 'rt-prg-02'
$routeTableRGName   = 'RG-NV'
$routeTableLocation = (Get-AzureRmResourceGroup -Name $routeTableRGName).Location

#endregion define Variables

New-AzureRmRouteTable -Name $routeTableName `
                        -ResourceGroupName $routeTableRGName `
                        -Location $routeTableLocation `

#endregion Create User Define Route Table

Powershell çıktısının verdiği sonuca göre başarılı bir şekilde Powershell üzerinden kaynaığımızı oluşturduk. Azure Portal içerisinden belirlediğiniz Resource Group seçtiğiniz zaman detayları oluştuğunu teyid edebilirsiniz. Şimdi ise, Azure Route Tablosu içerisine Route tanımlaması yapalım.

#region Create Routes

#region define Variables
$routeTableName     = 'rt-prg-02'
$routeTableRGName   = 'RG-NV'
$routeTableLocation =  (Get-AzureRmResourceGroup -Name $routeTableRGName).Location
$routeName          = 'RouteAllTrafic'
$routeDestPrefix    = '0.0.0.0/0'
$routeNextHopType   = 'VirtualAppliance'
$routeNextHop       = '192.168.10.10'

#endregion define Variables

$routeConfig = Get-AzureRmRouteTable -ResourceGroupName $routeTableRGName -Name $routeTableName | `
               Add-AzureRmRouteConfig -Name $routeName -AddressPrefix $routeDestPrefix `
                                        -NextHopType $routeNextHopType -NextHopIpAddress $routeNextHop 
#setConfig to existing Resources                                      
Set-AzureRmRouteTable -RouteTable $routeConfig

#endregion Create Routes

Başarılı bir biçimde Azure Routes tanımlamasını yaptık. Yazımızın başında yaptığımız maneul işlemlerin hepsini Powershell üzernde döktük yeni bir Azure Route Tablosu oluşturarak. Son kısıma geldik, artık bu oluşturduğumuz tabloyu Subnet atamasını gerçekleştirebiliriz. Örnek olması açısından yine aynı Subnet atamasını yapacağım. Daha önce atamış olduğum Route Tablosunun bu subnet ile ilişkilendirilmesini sonlandırdım.

#region Associate a route table to a subnet

#region define Variables
$routeTableName     = 'rt-prg-02'
$routeTableRGName   = 'RG-NV'
$routeTableLocation =  (Get-AzureRmResourceGroup -Name $routeTableRGName).Location
$routeName          = 'RouteAllTrafic'
$routeDestPrefix    = '0.0.0.0/0'
$routeNextHopType   = 'VirtualAppliance'
$routeNextHop       = '192.168.10.10'
$virtualNetwork     = 'vn-prg-01'
$subnetName         = 'Subnet-Internal'
$subnetAddPrefix   =  '192.168.10.128/28'

#endregion define Variables

$getVirtualNetwork = Get-AzureRmVirtualNetwork -Name $virtualNetwork -ResourceGroupName $routeTableRGName 
$getRouteTable     = Get-AzureRmRouteTable -ResourceGroupName $routeTableRGName -Name $routeTableName

Set-AzureRmVirtualNetworkSubnetConfig  -VirtualNetwork $getVirtualNetwork `
                                        -Name $subnetName `
                                        -AddressPrefix  $subnetAddPrefix `
                                        -RouteTable $getRouteTable 

#endregion Associate a route table to a subnet

Yukarıda görüldüğü gibi son olan işlemimizi başarıyla tamamladık. Artık Powershell atama sürecini kavramış bulunmaktayız. Bunu neden göstermek istediğimi aktarmak istiyorum, çok büyük yapılarda birden fazla User Defined Route Table yönettiğinizi hayal edin ve bunların bazen update edilmesi veya zorunlu değişiklik yapılması gerekmektedir. Yukarıdaki Powershell komutları sizlere bu açıdan yol gösterecektir. Son olarak dilerseniz Effective Routes tamamen Powershell üzerinden görmek için, 'Get-AzureRmEffectiveRouteTable' cmdlet faydalanmanız mümkün.

Yazımızın sonua geldik, bu yazı içerisinde temel anlamıyla Azure Route Table yönetimini ve detaylarına değinmeye çalıştık. Bir başka seride görüşmek üzere.

These days, Lots of people want to use Terraform which is from Hashi Corp. In this article, I'm going to be writing about Terraform and Azure. The Terraform is an open source software. As a tool for building, changing, versioning infrastructure. Terraform within configuration files I can explain to Terraform the components need to run, I could say single application or multiple application. As you know, when you heard Terraform, you suppose it which was working with only Cloud Provider. However, Terraform works with Cloud Providers such as Amazon, Cloudfare DigitalOcean, or Azure etc. also works with On-Premises resources like Vmware. The Main idea is Infrastructure as Code.

Terraform manages different type of components. The components can be low-level or high-level resources. I can give an example of components. As Low-Level Resource "Storage, Network" or As High-Level Resource like "DNS Enter record or change rule on Load Balancer". Moreover, we know all that, we have used different types of tool to deploy resource on Azure. I mean, we have used Azure Resource Manager in the typical case or use Azure Portal or Azure Software Development Kit or maybe REST API something like that. We know, if you've used Amazon Web Services, Amazon Web Services do same. Therefore, DevOps Engineer loves using YAML or JSON so the Problem space is here. The Terraform which is starting to solve this problem has magic tricks. The tool is doing create a common structure or well-known format. That allow developers or DevOps Engineer for get used to the same format. DevOps Engineer will have described their resources and they will use their code on Azure or Azure. Conclusion, it allows people to develop, manage their infrastructure as code. It's enthusing. Briefing for Terraform has completely written in GO.

Firstly, we have need to setup Terraform access to your Azure Services. We have used the shared account in this demonstration. I will demonstrate in Azure CLI.

#Firstly, login to the Azure CLI using:

az login

The Subscription which will be going to demonstration.

az account set --subscription="3b40246b-ffa0-43df-a51e-0c2317b4afc3"

Next, create separate credentials for Terraform.

az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/3b40246b-ffa0-43df-a51e-0c2317b4afc3"

Now you see your AppId, DisplayName, Password, tenant.

Now, I have created Azure Service Principal for managing our Azure Resource with Terraform. The Service Principal will have used by Terraform. After, We are going to use our Service Principal Account because we need to authenticate within Service Principal Account. We have to use those lines for authenticating in Visual Studio Code. The previous picture as you can see our Service Principal Details like AppId, DisplayName, Name, Password. You have learned details in the previous picture our Service Principal Details like App Id, DisplayName, Name, Password. Now, I'm going to authenticate with them.

Now, We are ready to use Terraform. Almost we are done. Let's learn to Terraform. Do not forget, I have created a project in the Visual Studio Code, therefore, I have installed the necessary extension and client application on my computer. I will be trying to create a few resources within Terraform. When I wrote this article, I was using Visual Studio code. If you are interested in this editor, you should be able to check my personal blog. You can check this heading on the web site. "How to use Visual Studio Code".

I have written a few lines in Visual Studio Code before I'm calling Terraform Application for Azure CLI. It is not a complicated process. You must write "Terraform init" for initializing this application. After All, I have called Terraform. Let's see.

Now, I think, We are good to go. I'm going to show you our Terraform structure. As you know, It has a common structure and quite easily. You could see our Terraform structure below.

Now we can push to our code into the Terraform client application. As you can see top of the code block, I have indicated provider to "Azurerm". If you want to change it for your provider, you can have a look this website. I deployed that code block into the Terraform with parameter. The "Apply" parameter will deploy your defined-code on Azure.

provider "azurerm" {

If you want to add your Azure Service Pricipal Account details, you can manifest here.

As you know I did add before.

#subscription_id = "REPLACE-WITH-YOUR-SUBSCRIPTION-ID" #client_id = "REPLACE-WITH-YOUR-CLIENT-ID" #client_secret = "REPLACE-WITH-YOUR-CLIENT-SECRET" #tenant_id = "REPLACE-WITH-YOUR-TENANT-ID" }

Create a resource group

Create a resource group

resource "azurerm_resource_group" "network" { name = "terraform-RG" location = "West US" }

Create a virtual network within the resource group

resource "azurerm_virtual_network" "network" { name = "terraform-vNET" address_space = ["10.0.0.0/16"] location = "${azurerm_resource_group.network.location}" resource_group_name = "${azurerm_resource_group.network.name}"

subnet { name = "terraForm-VNET" address_prefix = "10.0.1.0/24" } }

Conclusion, It was successfully when we had deployed our resources on Azure Portal. The best ways for Terraform, DevOps Engineer does not need to focus which one is the best YAML or JSON. I hope so, they will have focused their business.

I did post one years ago "Azure Server Management Tools". The Post explained "How to use Azure Server Management" and it also has three different part. But, I'm willing to give you details for Windows Admin Center. Actually, Microsoft has announced this product "Project Honolulu". But İt has changed to "Windows Admin Center". I'm keen to work with this product because it's working with agentless. Indeed, Windows Admin Center is browser based management your Windows Servers without Azure or Cloud dependency. Also, Windows admin center is the future of remote server management designed to modernize and simplify the IT administrator experience. if you want to perform a management task on a machine there are almost twenty different tools. Perhaps we've consolidated all these tools into a single machine. Maybe we called it "Admin Management Server". We have almost deployed all tools

Windows admin Center think of it as the evolution of traditional inbox management tools like MMC it's great for administrators that need a lightweight management solution for smaller scale deployments or ad hoc management for large scale deployments.

How does Windows Admin Center Work?​

Basically, IT Administrator runs in a Web Browsers and manages only these type of VMs.

• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows 10

Also, The Windows Admin Centers has particularly roles. These are called to "Web Server" and "Gateway". You can install Windows Admin Center to Windows Server 2016 and Windows 10. As a matter of fact, It is quite beautiful to have a chance to install Windows 10. According to me if you are planning install that services, you should try to Windows Server 2016. I'm going to explain roles.

Gateway : The gateway administers servers by using Remote PowerShell and WMI over Windows Remote Management. Also, The gateway is included with Windows Admin Center in setup package.

Web Server : I could say, The Web Server is included same package with Gateway. In other words, Windows Admin Center in a single basic "msi" package that you can download it.

Let's have a look that picture.

Windows Admin Center defines your management environment​

Integration existing solutions, The Admin Center works with Microsoft products like System Center and Azure Operation Management Suite. It gives you "Manage your Infrastructure Single Management Console". In the other hand, Windows Admin Center contains many of the familiar tools you currently use to manage Windows Servers and clients so you don't need lost your time for adaption. In Fact, it is installed easy and you will use familiar functionality to manage your servers like "Microsoft Management Console – MMC". However, if you are implementing your firewall and DNS server, you will be able to access your Windows Admin Center on the Internet. Windows Admin Center has a lot of points of integration with Azure services, including Azure Activity Directory, Azure Backup, Azure Site Recovery, and more.

I'm quite excited to huge features Extensibility for Windows Admin Center. Microsoft and 3rd party developers to build tools and solutions beyond the current offerings. Microsoft offers an SDK that enables developers to build their own tools for Windows Admin Center. If you are excited like me, you can look at this page. Windows Admin Center- SDK

Next Article, I will be writing for "Install Windows Admin Center".