Chat with us, powered by LiveChat

Blog

Back

Azure Cloud Shell – Notes from the field

5 Apr 2018 by Stewart Gibbons

In my day-to-day job, helping customers deploy and configure Quadrotech solutions in Azure, I get to deploy Azure infrastructure quite a lot. This has made me a big fan of automation in Azure, and I started developing scripts to build with PS and JSON templates in the platform. I soon got to a place where I wanted to make this easier to expedite and started using the Azure Cloud Shell in the Azure portal.

So “I’m going great guns now”, I have some really ‘funky’ Script and I can build with a flick of the mouse, and then one of my colleagues asks, “Hey, can you can drop those scripts into my Cloud Shell, so I can use them?”, “Sure” I reply, and that’s when the fun starts.

I get granted access to his subscription and logon – it’s at this point I realise that our subscriptions have identical names, e.g. “Visual studio enterprise” etc., etc., (more on this later). But what I realise is your Cloud Shell is unique to the user UPN you log on with, and not the subscription – so, if I work with another subscription, I am using the shell I have created in my own subscription, not the target subscription I am working on.

As a result, I had to explain to my colleague that if he needed to execute the script himself from his Cloud Shell, then he would need to log into his Azure subscription, and set up his Azure Cloud Shell (I.e. start it), and then copy the scripts either by uploading the file to it or mapping a drive to the storage account used for his Cloud Shell.

But being the helpful “Scripty” I am, I decided I would at least deploy the build into his subscription, so he could look at it. He granted me rights in the Azure portal, so I had access. Next, I needed to set his subscription from the Azure Cloud Shell to the context to deploy to. After doing a bit of research, I realised Set-AzureRmContext was my new best friend.

It was then that I realised that the subscriptions had the same name, so I was going to need a plan B. Going back to the command reference, I decided to use the “-subscriptionId” parameter, which is a large GUID-like number and is unique to each subscription.

Retrieving the subscription ID from the portal, I can now run the command (or I could have also used the PS command Get-AzureRmSubscription which lists all the subscriptions available to me).

Set-AzureRmContext -SubscriptionId “XXXXXXXX-XXX-XXXX-XXXX-XXXXXXXXXX”

Hey presto! My build deploys to the right place! The moral of the story: words are for poets, numbers are for ‘Scriptys’.