Automating DR using PowerShell and Azure DevOps pipelines

We recently started a project to set up automated deployments of Azure resources using Azure DevOps pipelines. The first service we folded into ADO was an extremely high profile one for the business. It’s used by all the employees and contractors for capturing project capitalization and expense hours by asset and resource. After having successfully accomplished setting this all up and confirming the various pieces were working post-deployment (hoorah!), my thoughts quickly turned to how disaster recovery could be handled. The solution I ended up implementing uses an Azure Automation PowerShell runbook to fire off a couple Azure DevOps pipelines to provision the needed resources (app service plan, web app, application insights, etc.), deploy the website code, and lastly fail over to the SQL replica in the West US region.

I’m going to try my best to keep this post as brief as possible. Let’s dive in and get started, shall we?

The PowerShell script can be found here. I’d like to point out a few things.

  • The script runs under the context of an Azure Automation Run As account.
  • The script accesses the appropriate ADO pipelines via the REST API using Invoke-RestMethod.
  • You need to add several pieces of information to the script:
    • Azure subscription ID
    • Azure DevOps organization name
    • Azure DevOps project
    • Azure DevOps personal access token
    • Release pipeline definitionId
    • Release pipeline stage environmentIds
    • Primary/secondary Azure SQL server and database names along with the appropriate resource groups

Terminology

  • definitionId – The ID of the release pipeline to which the current release belongs.
  • releaseId – The ID of the release, which is unique across all releases in the ADO project.
  • environmentId – The ID of the stage in the corresponding ADO release pipeline.

You can get the values for definitionId and releaseId from the ADO job log as follow.

Add the value for definitionId to the script like so.

The $environmentIds variables dictates which stage of the release pipeline to run. For example, in my pipeline I have the following stages.

If I want to run the Destroy stage, I would add 0 (zero) between the square brackets in the url. Deploy Dev would 1, Deploy QA would be 2, etc.

Create the runbook in your automation account, add the script, and make sure it’s set to published.

Thanks for reading this post, I hope it helps! Feel free to reach out in the comments section if you have questions.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.