Azure Cloud Shell Tips for SysAdmins Part III - Using Azure CLI

As an Azure Advocate, one of the things I spend my time doing is learning the easiest ways for beginners to use Microsoft Azure. Today I want to share with you a few ways to utilize some tools that are built right into Azure.

In my last blog post Azure Cloud Shell Tips for SysAdmins Part II - Using the Cloud Shell tools to Migrate, I use some of the tools that are part of the Azure Cloud Shell for bash. This time, I'll give you some quick tips on working with the Azure Resource Manager for information and to modify a newly created VM. I will be using the Azure CLI tool that's ready in Azure Cloud Shell.

First Steps

First, open a cloud shell, this can be done by going to the cloud shell logo in the portal, right of the search bar or navigate directly by going to https://shell.azure.com/.

The Azure Cloud Shell contains all the tools used in this tutorial. You can install the Azure CLI locally by following the instructions for your operating system.

Using Azure CLI

Let's run through a series of tasks you may need to do to create a new Linux server using Azure CLI.

Create a resource group.

I like to think of a resource group as a big box where you can put all of your Azure resources. When I am finished with the box, I can throw it away into a dumpster and move on. I won't have to spend time deleting each individual resource when I am finished.

Creating a resource group requires you provide at a minimum two pieces of information required to create the group.

• Name - Literally what you want the resource group's name to be
• Location - This is where metadata about your resource group will be stored. This could be important for those who may require all of your infrastructure's data be stored in a specific country due to compliance.

Another optional setting is Subscription that permits the user to state which billing subscription the resource group will belong to.

To create a resource group named "devtoapp" in the East US region of Azure, I will execute the following command:

az group create --location eastus --name devtoapp

The Azure Resource Manager will then create your group and provide you with a JSON output of what was created:

{
  "id": "/subscriptions/fakefakefake-54cc-0000-a58b-87afakefakefake7ad/resourceGroups/devtoapp",
  "location": "eastus",
  "managedBy": null,
  "name": "devtoapp",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": null
}

Looks like I forgot to set a tag to say this is my "dev" environment - let's update that:

az group update --name devtoapp --set tags.Details='{"Environment":"dev"}'

I've told Azure Resource Manager to update the metadata associated with my group to include a tag about my environment.

{
  "id": "/subscriptions/fakefakefake-54cc-0000-a58b-87afakefakefake7ad/resourceGroups/devtoapp",
  "location": "eastus",
  "managedBy": null,
  "name": "devtoapp",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": {
    "Details": "{'Environment': 'dev'}"
  },
  "type": null
}

Done! Let's put some resources in this group!

Create a VM

In my last blog, I did all the work for the reader by providing you with a script that handled all the creation of the VM. This time around, I'd like to show the command and explain what's being passed to the Azure Resource Manager.

Before I run this, I want to explain what I am doing by executing the command in my Cloud Shell.

az vm create
I want to create a VM
--resource-group devtoapp
I want to put this new VM in the devtoapp resource group
--name devtoappvm
The name of my new VM should be devtoappvm
--public-ip-address-dns-name devtoappvm
I want a fully qualified domain name available with the hostname devtoappvm
--image UbuntuLTS
I want to use the Linux Ubuntu Long Term Support Image
--admin-username azureuser
I want my username for the server to be azureuser
--generate-ssh-keys
I want Azure to create a new ssh key pair for the new VM. The key files are stored in the ~/.ssh directory unless specified otherwise with the --ssh-dest-key-path option.

I'll run the command with "time" just for fun so I can see how long it takes to provision my new VM in the Cloud Shell.

time az vm create --resource-group devtoapp --name devtoappvm --public-ip-address-dns-name devtoappvm --image UbuntuLTS --admin-username azureuser --generate-ssh-keys

I will get the - Running .. response from Azure Resource Manager until the new VM is created. When the VM is ready, the resource manager will output a JSON document with details associated with the VM.

{
  "fqdns": "devtoappvm.eastus.cloudapp.azure.com",
  "id": "/subscriptions/fakefakefake-54cc-0000-a58b-87afakefakefake7ad/resourceGroups/devtoapp/providers/Microsoft.Compute/virtualMachines/devtoappvm",
  "location": "eastus",
  "macAddress": "00-0D-3A-15-0A-5C",
  "powerState": "VM running",
  "privateIpAddress": "10.0.0.4",
  "publicIpAddress": "13.90.240.117",
  "resourceGroup": "devtoapp",
  "zones": ""
}

Looks like the server is up, I'll ssh in and take a look!

Great, time to add a new network rule to the server.

Create Network Rule

Now that I have this new server, I'd like to add network rules so that I am able to access ports 80/443 which are standard for web traffic. Let's take a look at one of the rules I'll be using and break it down on what exactly is happening:

az vm open-port
I want to open a port to a VM
--port 80
Name the rule "port 80" and open port 80 on the server
--priority 101
Rule priority 101, between 100 (highest priority) and 4096 (lowest priority).
--resource-group devtoapp
The resource group the server lives in.
--name devtoappvm
The name of the server.

I'll run the command

az vm open-port --port 80 --priority 101 --resource-group devtoapp --name devtoappvm

and get the output from Azure Resource Manager:

 {
      "access": "Allow",
      "description": null,
      "destinationAddressPrefix": "*",
      "destinationAddressPrefixes": [],
      "destinationApplicationSecurityGroups": null,
      "destinationPortRange": "80",
      "destinationPortRanges": [],
      "direction": "Inbound",
      "etag": "W/\"dcb63769-502e-4e8b-ad93-b909cff97e9e\"",
      "id": "/subscriptions/fakefakefake-54cc-0000-a58b-87afakefakefake7ad/resourceGroups/devtoapp/providers/Microsoft.Network/networkSecurityGroups/devtoappvmNSG/securityRules/open-port-80",
      "name": "open-port-80",
      "priority": 101,
      "protocol": "*",
      "provisioningState": "Succeeded",
      "resourceGroup": "devtoapp",
      "sourceAddressPrefix": "*",
      "sourceAddressPrefixes": [],
      "sourceApplicationSecurityGroups": null,
      "sourcePortRange": "*",
      "sourcePortRanges": [],
      "type": "Microsoft.Network/networkSecurityGroups/securityRules"
    }

I will run the the following rule with the priority incremented to 102 and a rule for port 443:

az vm open-port --port 443 --priority 102 --resource-group devtoapp --name devtoappvm

Now I have a server that I have ready for me to begin installing any specific configuration management agent I may need or to perform a manual install of an application.

Wrapping Up

I've been putting together these starter tips for manual work to show the baby steps one may need to take to begin working with Azure. I will continue to work through these "getting started" tasks to help users who may be still working to understand what's the big difference between their datacenter and the cloud. I will continue to find you new ways to do work you may already be doing! Always feel free to reach out to me if you need more info or just want to say thanks on twitter, you can find me there as @jaydestro. Be sure also to check out my podcast, On-Call Nightmares and hear stories from other Ops professionals who've spent time on-call in tech!