RFC: Azure Resource Manager support

Published on: 20 Nov 2015 by: Michael Richardson

At some point in the past, the Azure team made a definite change in direction regarding the way resources are managed in Azure. The result is, of course, Azure Resource Manager.

As a consequence, there are now two distinct interfaces for interacting with Azure. The original interface is known as Azure Service Management (ASM), with Azure Resource Manager (ARM) being the new. The split is profound; there are two HTTP API's, two sets of PowerShell modules, and even two web portals.

Currently, Octopus Deploy interacts only with the Service Management interface.

When you create a new Azure account in Octopus you attach a certificate, which is used to authenticate with Azure. This mode of authentication can only interact with the Service Management API's. To consume Resource Manager requires authenticating via Azure Active Directory.

To provide support for Azure Resource Manager, a number of changes are proposed:

Azure Service Principal Account

We are proposing adding a new account type to Octopus: an Azure Service Principal account (the existing Azure accounts will be known as Azure Management Certificate accounts). The creation process for an Azure Service Principal account will include creation of a Service Principal in your Azure Active Directory (see this post for context), and capturing the required fields (Application ID, Tenant ID, password). We would make this experience as smooth as possible.

Create Azure Service Principal Account

A new "Deploy Azure Resource Group" step

With Resource Manager, resources can be provisioned and deployed as a group using JSON templates.

We are proposing a new deployment step which can provision/deploy a resource-group using a JSON template.

Choose step type

Editing the step may resemble:

Deploy Resource Group step

Things to note:

  • The "Parameters" section is dynamic. The form adjusts to match the parameters defined in the template.
  • Octopus variables may be bound to any of the fields, including parameters. In the example above, the siteName parameter is bound to a variable. This is powerful, as it allows your parameters to be adjusted based on environment, channel, etc without modifying the step.
  • The "Validate" button will allow your deployment to be validated against Azure Resource Manager. This is nicer than having to create a release and deploy only to find your JSON is invalid.

In our current thinking, these steps do not include a NuGet package. The use-case we imagine for these Resource Group steps is more around provisioning resources, rather than deploying them. For example, you may have a "Deploy Resource Group" step which creates an Azure Website (and possibly a SQL database, etc), followed by a "Deploy Azure Web App" step which would take the NuGet package containing your application and deploy it.


ARM Deployment Process

Azure PowerShell scripts

Currently, for "Run Azure PowerShell Script" steps we automatically import the Azure PowerShell module and authenticate against the subscription. But this does not allow use of Resource Manager cmdlets. We would do something similar for Resource Manager: if the account is a service-principal account, we would automatically authenticate. Whether or not to automatically load the resource-manager modules is an open question, as they have been made much more granular.

At this moment, service-principal accounts cannot access the Service Management API's (including PowerShell modules). This means you would be unable to combine Service Management and Resource Manager cmdlets in the same step. To use Service Manager cmdlets, you would need to have a step which selected an Azure Management Certificate account, while to use ARM cmdlets you would need a step which selected an Azure Service Principal account. Given it appears Microsoft has effectively ceased development on the Service Management side, we imagine this will be an ever diminishing problem.


Something we are also considering is allowing the template to be retrieved from a Git repository. This may or may not happen, and if it does may not be included in the initial release of this functionality. We'd be interested to know if this is of interest.


Tell us what you think?