PowerShell for taming Azure

Have you got your subscription under control particularly if you are on MSDN or a smaller budget and it’s just you or a small team using it?  If you aren’t sure  then read on; else Coffee.

Here’s the problem we all forget to turn stuff off or kill it when we don’t need it which can be because it can be a hassle to recreate.  So in my simple world I want to make sure that expensive resources like VMs and my Azure SQL Data Warehouse aren’t burning costs (as I have mentioned before). The answer to this is hidden away in Azure - Azure Automation.

It pretty much does what it says it does, but frankly this used to be a bit of a pain partly because of the disjoint between the kind of PowerShell around at the time which is based on Azure Service Management and what we have now with Azure Resource Management.  There have also been changes to how subscriptions can be controlled and this comers into the mix too.

So what do you need to do manage these services with a firm hand?

First I am going to assume you have access to an Azure subscription.  All you need to do is track down Azure Automation and set your account up. 

This is essentially a container for all of the assets needed to control resources in a subscription, so that they can run when we aren’t around to click on the portal.  When we create one of these are asked for the usual setting for any Azure service and we also get the option to create a run as account. 

Once we have our account we can see that it is essentially a container for the resources we need to manage services:

On the left blade we can see my runbooks which are the scripts themselves and then I have expanded the assets to see the other stuff I need to make my runbooks work :

Schedules to determine when to run jobs for example my nightly schedule runs every night at 10:30 and will do so for ever..

Modules are the PowerShell modules I can use just like I would have set up on any machine..

Connections which is that Run as account I created when I setup the account..

Credentials to authenticate against what we are trying to manage and I have one of those to connect to my MSDN subscription

Certificates to enable trust between our script and what we are managing

Variables that can be consumed and updated in our scripts for example here I have a variable ResourceGroup of type string..

So let’s see write and publish a run book and put it into production.  For this worked example I am going to do nothing more than pause my Azure SQL Data Warehouse every night as it has cost serious money in the past because I left it on.  To create a Runbook click on the Runbooks icon.  Here you can see what I have done already and if I click on the Browse Gallery icon there is a long list  of  examples from Microsoft and the wider community to help us get started..

If I filter on warehouse there is a script to pause and restart it based on the parameter it is passed.

To use that script i could setup credentials but I wanted to save time and use the built in run as account for this so I tweaked the sample script as follows..

It’s just a matter of clicking on it to import it , naming it and then editing, it all form the portal (by clicking on the edit button) ..

however to use this script I am going to have to create a credential where I just want to use the run as account. Not a problem other example in the gallery do this so all I need to do is substitute this in place of line 3-13..

$connectionName = "AzureRunAsConnection"

$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName
"Logging in to Azure..."
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

Notice that in sharing this I haven’t compromised my subscription where in my old style PowerShell passwords and credentials were embedded all over the place which is not a good story for production

The next cool thing is we can test this by clicking on the Test Pane in the editor blade in the portal, and if the script need parameters we’ll be prompted for those..

Now we have tested it can be published (another button on the editor. Once that’s done we can setup a schedule e.g. I have a nightly (10:30 every night) schedule that never expires.

If you have a job that needs parameter like this script to stop all VMs for the specified Resource Group and whether to shutdown the VMs then we can set these as part of this process..

The blades for Azure automation also show us how the overnight runs are doing as per the screenshot at the top of this post  and hopefully yours will be nice and green too .

So Azure Automation makes managing service a little bit easier and is something us data professionals need to know.  However for a deeper dive into this world you’ll want to track my good friend Marcus Robinson who is really hot on this.