Managing Azure Subscriptions and Resources (Part 2)
Preface: This is the second/last part of a two-part series on Managing Azure Subscriptions and its underlying resources. If you haven’t seen nor read the first part of this article, you should head over here before proceeding.
Disclaimer: This blog post is out-rightly meant for folks starting to get their hands dirty with Azure, or preparing for the Microsoft Azure Exam AZ-103, and it does not cover advanced concepts. If you’re a Microsoft-certified Azure DevOps Engineer Expert, or a Microsoft Azure Most Valuable Professional, you should literally close this window now, as you wouldn’t want to be bored which might cause you to smash the lid of your PC or Mac against your keyboard :)
Here we go,
The Very Basics of Networking for Azure VM
Quite similar to the way on-premise servers work, you could also configure both Public and Private IP addresses on your Azure VMs. Azure resources such as Virtual Machines, Cloud Services, and Azure App Service Environments can communicate privately with each other through an Azure Virtual Network (VNet).
In Azure Resource Manager, a public IP address is a resource that has a specific set of properties independent of the VM. You can associate a public IP address with a Windows or Linux VM by assigning it to its network interface.
Public IPs are for Internet-facing services like a web-server. Private IPs are for communicating with other Azure VMs in your Azure Virtual Network (VNet).
You can add as many private and public IP addresses as necessary to a network interface, within the limits listed in the Microsoft Azure limits article. Note that, you cannot use the Azure portal to add an IPv6 address to an existing network interface (though you can use the portal to add a private IPv6 address to a network interface when you create the network interface).
A virtual network is a resource that you can create using the Azure Resource Manager, as shown in the next screenshot.
Public IP addressing on Azure Virtual Machines
This is a bit different to how you may be relating this back to a dedicated Windows server. The concepts of static and dynamic IP addresses still exist, but you may be surprised to note that in the case of a public IP address, a dynamic IP is not associated with a DHCP server. Below is a quick explanation of how IP addressing is handled in Azure.
Protecting your VM with Network Security Groups
Similar to a dedicated firewall, Azure can create a network security group that protects your VM from network traffic on the public internet. You can also open specific ports to allow ingress traffic to your VM, or set outbound rules to restrict outgoing traffic.
A network security group can be associated with the network interface of your VM, or with an entire subnet. If it’s associated with a subnet then the inbound and outbound rules you specify on the NSG apply to the entire subnet.
Private IP Addresses for Azure VMs
There aren’t a lot of differences between static and dynamic IP addresses in Azure and what you’re used to in your datacenter or IT environment. Dynamic IP addresses are allocated via a DHCP service that is provided by Azure.
Static IP addresses are also provided via DHCP, working like a DHCP reservation, meaning these IP Addresses are persistent, meaning they will not change when the VM is restarted or shut down. The gotcha here is that you should never manually change the IP Address settings within the VM to static, keep it as Dynamic IP Assignment, and Azure will always assign it the same IP address.
Managing Azure VMs
As you may have guessed, management of an Azure VM isn’t that different from remotely managing on-premises Windows or Linux VMs and dedicated servers. There are a couple ways you can do this:
Remote Access
- Remote Desktop (RDP) — This is the most common method. Simply fire up your RDP client and connect to the public IP of the Windows Server based Azure VM.
- SSH — This is the most common method to remotely connect to a Linux server.
Cross platform (Linux or Windows) management options
- Command Line Interface (CLI) — This is an open source, shell-based commands for creating and managing Microsoft Azure VMs. This is a great option for administrators as these scripts will work across various personal systems like Windows, Linux or Mac.
- VM Extensions — These are agents you can install on Azure VMs, either during deployment or post-deployment of the VM. These agents allow you to use automation tools like Chef, Puppet or Desired State Configuration for Windows or Linux. In the case of DSC, it allows you to describe the desired state of your Windows or Linux OS for automated configuration of your VM. DSC files can be stored in an Azure Storage account. This is great for re-using already created on-premises DSC configurations that can be applied to Azure VMs.
- Custom Script extensions — This method allows you to run scripts on the Azure VM depending on the OS type. For Windows, you would use PowerShell, and for Linux, you could use scripts that are compatible with the Linux OS like python or bash. These scripts reside outside of your VM in an Azure Storage account or in Github. The scripts may be used to outline a set of instructions to automate the configuration of your VM.
Monitoring Azure VMs
Monitoring and diagnostics can easily be enabled from the Azure portal. There are a number of diagnostic logs you can monitor such as Windows event system logs, Windows event security logs, Windows event application logs or Diagnostic infrastructure logs.
This process is similar to the Windows Event Log on your dedicated server, where events on the server are stored locally in various log files, which you can then analyze to pinpoint issues. In Azure, the log files are stored in an Azure Storage account that is automatically associated with your virtual machine.
As an admin, you are also able to set alerts on specific metrics, like the example below. This alert will trigger when the CPU on a server runs at more than 75 percent for over five minutes.
Alerts can be configured to send email notifications to administrators on the account, or you can also use webhooks to trigger workflows in third party systems.
That. Is. A. Wrap!
We have just come to the end of this two-part series on managing Azure subscriptions and its underlying resources, and how an Azure Virtual Machine is different from a dedicated server.
In this two-part series, I did scratch the surface of the Azure technology as the sole goal of this crash course is to be as comprehensive as it ever could be. I am very enthusiastic about the Azure Compute Engine, and I’d like to point fellow enthusiasts to other great resources — curated by engineers that are more qualified than I am on this subject topic — in order to learn more (check here, here, and here).