In this second post in my Continuous Delivery with TFS / VSTS series, it’s time to make a fresh start in Microsoft Azure. Whaddaya mean a fresh start? Well, for a little while now, there has been a new way to interact with Azure, namely through a feature known as Azure Resource Manager or ARM. This is in contrast to the ‘old’ way of doing things which is now referred to as Azure Service Management or ASM. As I mention in a previous blog post, ARM is the way of the future and this new series of blog posts is going to be entirely based on using ARM using the new portal (codename Ibiza) where portal interaction is necessary. I have lots of VMs created in ASM but the plan is to clear those down and start again.
However, I’m a big fan of using PowerShell to work with Azure at every possible opportunity and a further reason for making a fresh start is that there is a new set of Azure PowerShell cmdlets for working with ARM (to avoid naming clashes with ASM cmdlets). To me, it makes sense to start a new series of posts based on this new functionality.
As usual, the aim of this post isn’t to teach you foundational concepts and if you need an introduction to ARM, I have a Getting Started blog post with a collection of links to help you get going. Be aware that most of the resources pre-date the arrival of the new Azure PowerShell cmdlets. In the rest of this post, we’ll look at how to get up-and-running with the new cmdlets.
Install the New Azure PowerShell Cmdlets
First things first. You’ll need to install the new-style Azure PowerShell cmdlets. At the time of writing, these were in preview, and the important thing to note is that the new version (1.0 or later) introduces breaking changes so do consider which machine you are installing them on. In the fullness of time, we will be able to perform the installation from Web Platform Installer, but initially at least, it’s a manual process. Details are available from the announcement blog here and Petri has a nice set of instructions as well.
Logging in has Completely Changed
If you have been used to logging in to Azure using the publish settings file method, then you need to be aware that this method simply will not work with ARM since certificate-based authentication isn’t supported. Instead, you use the Login-AzureRmAccount cmdlet, which causes the Sign in to Microsoft Azure PowerShell dialog to display. What happens next depends on the type of account you attempt to log in with. If you use a Microsoft Account (typically this is the account your MSDN subscription is associated with), the dialog will recognize this and redirect you to a Sign in to your Microsoft account dialog. If you log in with an Azure AD account, you are logged straight in – assuming authentication is successful of course.
After a successful login, you’ll see the current ‘settings’ for the login session. If you only have one Azure subscription associated with your login, you are good to go. If you have more than one, you may need to change to the subscription you want to use. The Get-AzureRMSubscription cmdlet will list your subscriptions and then there are a couple of options for changing subscription:
Get-AzureRmSubscription
-SubscriptionName "Visual Studio Premium with MSDN" | Select-AzureRmSubscription
#or
Select-AzureRmSubscription -SubscriptionId "zyb4a111-7e0b-1111-df9d-x4a160567809"
If using the second version, obviously replace with your GUID. In case you were wondering, the one above is made up…
The ASM version of Select-AzureRmSubscription takes a -Default parameter to set the default subscription but this seems to be missing in the ARM version – hopefully only a temporary thing.
But I Don’t Want to Type my Password Every Time I Use Azure
When you log in using Login-AzureRmAccount, it seems a token is set which expires after a period of time – about 12 hours according to this source. This means that you are going to be logging in manually quite frequently which can get to be a chore and in any case is of little use in automated scripts. There is an answer although it doesn’t feel as elegant as the publish settings file method.
The technique involves firstly saving your password to disk in encrypted format (a one-time operation) and then using your login and the encrypted password to create a pscredential object that can be used with the -Credential parameter of Login-AzureRmAccount. All the details you need are explained here however do note that this technique only works with an Azure AD account and also be aware that the PowerShell is pre new-style cmdlets. The resulting new-style code ends up something like this:
$subscriptionId = "zyb4a111-7e0b-1111-df9d-x4a160567809"
$azurePassword = Get-Content
-Path "C\Users\You\Documents\AzurePasword.txt" | ConvertTo-SecureString
$azureUsername = "loginname@youraccount.onmicrosoft.com"
$azureCredential = New-Object -TypeName pscredential -ArgumentList $azureUsername, $azurePassword
Login-AzureRmAccount -Credential $azureCredential -SubscriptionId $subscriptionId
If you only have one Azure subscription, you can of course simplify the above snippet by removing the subscription details. Is it a good idea to store even an encrypted password on disk? It doesn’t feel good to me but it seems for the moment that this is what we need to use. The smart money is probably on using an Azure AD account with very limited privileges and then adding permissions to the account as required. Do let me know in the comments if a better technique emerges!
Cheers – Graham
The post Continuous Delivery with TFS / VSTS – A New Way of Working with Azure Resource Manager appeared first on Please Release Me.
