AZURE DEVOPS PIPELINES WITH AZURE AUTOMATION
Writing is fun especially when you have free time and you want to spend it productively. This week, I was configuring governance for Azure subscription. One of the requirement was to implement policy that shutdown VMs in sandbox subscription everyday at 7 o'clock. It can be done in several ways but I planned to implement using Azure Automation as I like to work with PowerShell script. Azure automation is a robust, cross platform and powerful automation engine for script based process automation so why not Azure Automation.
I don't only wanted to implement runbooks in Azure Automation but I also wanted to implement automation pipeline. So in future, I don't have to do manual steps to deploy changes in Automation Account. During the implementation, I came across some nice features and limitations of Azure Automation Account which I though would be good to share with others. As you know, Sharing is caring :)
In this blog, I am going to discuss following below topics.
- Azure DevOps Repos as source control for runbooks
- Azure Automation source control sync using custom script
- Azure DevOps CI/CD Pipelines for Automation
- Automate AzureRunAsCertificate renewal using script
Architecture
Visual presentation is always good to understand the overall picture so I decided to draw the basic architecture diagram which I am going to explain below.
Source Control
Source control is a vital component to anyone who is authoring scripts and runbooks today. Not only does it provide you with history tracking of who made changes and what the changes were, but it also gives you one centralized source for all your code, which can save you hours of rework and troubleshooting if something goes wrong.
Azure Automation has native support for GitHub and Azure DevOps (vsoGit) repositories used as source control for runbooks. The basic setup of source control integration is a quite simple and easy. However, the concept behind this out of the box functionality might not fit a CI/CD concept. Azure Automation source control sync jobs are built to sync code changes either automatically or manually into the runbooks container. This can be problematic when you have to deploy runbook changes to multiple environments using CI/CD pipelines. Let's see how you can make Azure Automation source control sync job as a part of your CI/CD pipeline in next step.
Azure Automation Custom Source Control Sync Script
- Create Source control in Azure Automation account and select source control type Azure Repos (Git) as we are going to use Azure DevOps for CI/CD pipleines.
- Make it sure that Auto Sync is off.
- You can test the sync functionality by manually pressing Start Sync button. This will copy all the runbooks from Azure Repos (Git) in Azure Automation Account.
- Download script runbook Start-SourceControlSync.ps1, which will be use to trigger the manual synchronization in later stage.
Service Connection
Create service connection in Azure DevOps that will be used during CI/CD pipelines configurations.
- Create new service connection: Project Setting -> Service Connection
- Select Service principle (automatic)
- Select Subscription and Resource group
Azure DevOps Pipelines
Build Pipeline
During the build pipeline, you can add some validation and unit tasks. To make it simple, I am not adding any additional tasks at this moment but there can be other tasks e.g. Validate Powershell Syntax etc.
Set Build trigger to Enable continues integration
Release Pipeline
During the release stage, runbooks can be deploy into multiple environments but here I am only deploying into one sandbox environment.
In Sandbox stage, there is one task "Azure Powershell" in which I have provided Inline code that will run Start-SourceControlSync runbook in Azure Automation. This runbook will start the source control sync. Inline code is mentioned below
#Define constants
$automationAccountName = "SandboxGovernanceAutomationAccount"
$resourceGroupName = "SandboxGovernance"
#Get automation account object
$automationAccount = Get-AzureRMAutomationAccount -Name $automationAccountName -ResourceGroupName $resourceGroupName
#start sync runbook
$job = Start-AzureRMAutomationRunbook -Name "Start-DevOpsSourceControlSync" -AutomationAccountName $automationAccount.AutomationAccountName -ResourceGroupName $automationAccount.ResourceGroupName -Parameters $runbookParameters
#Get Job Status, wait for completion or failure
$jobResult = Get-AzureRMAutomationJob -Id $job.JobId -AutomationAccountName $automationAccount.AutomationAccountName -ResourceGroupName $automationAccount.ResourceGroupName
while ($jobResult.Status -eq 'New' -or $jobResult.Status -eq 'Running'){
$jobResult = Get-AzureRMAutomationJob -Id $job.JobId -AutomationAccountName $automationAccount.AutomationAccountName -ResourceGroupName $automationAccount.ResourceGroupName
write-output "waiting for job to complete"
start-sleep -Seconds 3
}
$jobResult.Status
Now we have fully integrated Azure DevOps CI/CD pipeline. Whenever someone push changes to master branch, CI/CD pipeline will be trigger and deploy latest changes in Azure Automation Account.
Renew AzureRunAsCertificate
The self-signed certificate for Run As Account expires after one year from the date of creation. At some point before your Run As Account expires, you must renew the certificate. This can be renew at any time before it expires. At this moment, there is no OOTB automated way to renew the certification or increase the certificate expiry duration.
To automate certificate renewal for Run As Account, I have created a Powershell runbook "RenewRunAsCertificate" that will renew the certificate. This runbook can be schedule in Azure Automation account E.g. Run once in 6 months. In this way, every six months self-signed certificate will renewed.
To execute runbook, it requires some additional permissions to be in place as Service Principle does not have permissions to read Azure AD by default. You will need to grant the permissions on the service principle under API permissions.
Comments
Post a Comment