In today’s day and age where a lot of companies are migrating to the cloud or having a mix of on-prem and cloud deployments, automating the deployment of infrastructure is essential. Not only does it speed up the time of deployment because you don’t have to waste time clicking around GUI’s, but it also reduces the chances of human error, since it’s all in a template. In this blog post I will walk you through deploying a Windows VM, NSG, Azure Bastion, and a storage account using a Bicep Template. Azure Bicep is a domain-specific language for deploying Azure resources and offers a streamlined approach to IaC.
Firstly, here is my template: https://github.com/arnoldadlv/bicep-template-homelab
Lets go through parameters and variables I have set:
Parameters:
- Location – For our location parameter, we set it to default as the same location as our resource group. To do this we simply did resourcegroup().location
- vmName – This parameter simply names our VM
- adminUsername – this parameter is our administrator username for the virtual machine
- adminPassoword – this paramter is our administrator password for the virtual machine, and is set to secure string
- vmSize – this parameter is our virtual machines size, which we set as Staqndard_B1s
- osVersion – this parameter is the Windows Version of our VMs Operating System, we set it to 2019-Datacenter-smalldisk
Now let’s go through each resource this template deploys:
Network Security Group – A network security group is a set of rules that controll inbound and outbound traffic to network interfaces (NIC) and subnets within Azure. By defining these rules, you can block or allow traffic based on specific criteria, kind of like a firewall. The deployment of a virtual machine requires a NSG.
Virtual Networks – VNets allow connectivity between azure resources. The deployment of a virtual network in Azure requires you to make subnets. The deployment of a Virtual machine requires a VNet.
Azure Bastion – Azure Bastion gives you a secure way to connect to your Azure VMs without exposing them to the public internet. Traditionally, you would need to expose port 3389 (RDP) and give your VM a public IP Address. But, with Azure Bastion you don’t need to do that. The deployment of Azure Bastion requires a subnet named AzureBastionSubnet. And this subnet must be created in the same VNet that you want to deploy Bastion to.
Azure Virtual Machine – Self explanatory. This is a virtual machine in Azure. This template creates a Windows VM, with the size of Standard_B1s. It also has a managed disk of Standard_LRS.
Storage Account – Here we set the Storage Account SKU to StorageV2 and set supportHttpsTrafficOnly to true.
Here we deploy our template via az cli:
az deployment group create –resource-group rg_sb_eastus_165803_1_170338102386 –template-file main.bicep –name demoDeploy
Then we head over to the Azure Portal to verify deployment. And sure enough, here are the resources we deployed.
Now, lets access the VM via Bastion.
First, we click on the Virtual Machine.
Then, we click on Bastion on the left hand side.
Next, we type in our admin credentials we created when we deployed the Bicep template. Then click Connect.
A new tap will open up and you will be RDP’d into your virtual machine via Bastion.
Here I run ipconfig in a Powershell terminal to demonstrate that we are NOT accessing the VM via a Public IP (which would be a security risk), $env:computername to show the name of the virtual machine follows what we specified in our template, and then Get-ComputerInfo just to look at the specs the computer.
In conclusion, Bicep offers a powerful and efficient way to deploy azure resources.