Azure CLI 2.0 (Part 1)

A few days ago I started to play a little bit with Microsoft Azure. I logged into portal.azure.com and felt overwhelmed with the number of buttons, options and colours. Yes… it may be that I’m 31-years-old veteran of console. Fortunately, I’m not alone and Azure supports users requiring responsible and simple interface.

I’ve tried azure-cli installation on Linux (RHEL6 and Centos 7) and Mac OS X 10.9.5. It generally went smoothly [1] (for unknown reason the web page in Polish displays in google as “Installare l’interfaccia della riga di comando di Azure 2.0.”, which is correctly recognized by google translate as Italian). The blot on a landscape is RedHat 6 which is officially not supported. This comes from the implementation in python version 2.7 [2], however, once you have it installed generic azure-cli installation script works fine.

There are multiple ways to login[3], however the default one is really simple especially for newcomers. In comparison to AWS where you have to preconfigure API keys in Azure after login command you just get the link and code, authentication is established in web browser as for regular portal.azure.com login. Behind the scenes it creates a file ~/.azure/accessTokens.json. In my case the value inside suggests that it expires after one hour, however it looks like next token is refreshed automatically without contacting company AD/office365 login service (at least in my case account being locked doesn’t preserve continuous operations with azure-cli over a few days!).

The very first thing you have to do in new Azure (with resource manager which is the modern way to manager resources) is to create a resource group. According to Azure documentation the main question to answer gathering resources in a resource group is the life cycle, because it’s quite easy to deallocate the whole resource group. Secondary argument may be administrative policies assignment which may also be done at resource group level. In azure-cli this will be:

#az group create  -l westeurope --name TestGroup

location is required, but it’s meaning is the location of resource group metadata (names of VMs, resource IDs, etc.) actual resources in the resource group can be split between different locations [4].

Azure-cli commands return by default a JSON form, however, you can change this adding "-o table" argument, which implicitly reduce amount of returned information. In case of resource group creation tabular form doesn’t return ID, keeping it in JSON we learn that it has hierarchical form: "/subscriptions/SUBSCRIPTION_UUID/resourceGroups/TestGroup". This should bring us to the question: Which subscription was used if I’m allowed to use more than one? Obviously the answer is default :), you can check your default with:

#az account  list -o table

(in this case and probably all list commands table output is something you’d appreciate)
And change the default subscription with:

#az account set -s SUBSCRIPTION_NAME

This information is stored in your ~/.azure/azureProfile.json, so if you’re switching between multiple computers with azure-cli (as I do) you have to be careful.

More than one page and I haven’t really started 🙂 In next post I’ll share my experience with Azure PaaS.

[1] https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest
[2] https://gist.github.com/cinek810/059cfd5f487f69cf727ebc22fc7870cc
[3] https://docs.microsoft.com/en-us/azure/xplat-cli-connect
[4] https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#resource-groups