Introduction to Azure Automation
Azure Automation: Runbooks
Azure Automation: Desired State Configuration (DSC)
Join Trevor Sullivan, Microsoft PowerShell MVP, for this demonstration on integrating a GitHub source control repository with your Microsoft Azure Automation Account! By leveraging this feature, you can keep track of changes to your Azure Automation Runbooks over time, and as a fringe benefit, ensure that you have a backup copy! If you aren't using source control for your Runbooks today, and are tracking version changes through file names, you'll most likely want to reconsider your strategy!
Hello. In this demonstration, we are going to set up source control integration with Azure automation. The benefit of setting up source control integration with Azure automation is that you can synchronize runbooks from a GitHub account, and you can also synchronize them back from Azure automation, back into your GitHub repository.
So before we get started, you're going to need to have an automation account already created, and you'll also want to have the PowerShell ISE available, and you'll also want to have the GitHub desktop application. You can use a different Git client if you'd like, but this example is going to use the official GitHub desktop client.
The first thing we're going to do is open up the resource group that contains our Azure automation account. Under the resource summary, we'll click on the automation account to open up the automation account's blade. Inside the automation account's blade, if you scroll down below monitoring, you'll see a heading called source control integration, and there will be a button to set up source control. In order to set up source control, you'll already need to have a GitHub account. So, if you haven't already signed up for GitHub, go ahead and sign up.
Under the source, we'll choose GitHub, and then we'll go under authorization and click the authorize button to authenticate and connect to GitHub. As you can see, we've got an authorization dialog here and because I'm already signed into the GitHub website, I can simply click the authorize application button. I'll have to confirm my passwords to ensure that I am authorizing this action.
Now, we've successfully authorized GitHub. However, we need to choose a repository. Because we haven't actually created a repository yet, we need to actually go ahead and create one before we can proceed. Let's go to the GitHub desktop client and create a new repository inside of our GitHub account. I'm going to call this AzureAutomationCA. I'll go ahead and click create repository.
Now we need to add a couple of Azure automation runbooks into this repository. So, let's right click it and say open it in Explorer. As you can see, we do not have any runbooks inside of this directory right now. We simply have the skeleton for a Git repository. So, we need to switch over to the PowerShell ISE and create a couple of runbooks.
I'll create basically a couple of stub runbooks by simply adding a very simple get-process command to them. I'm going to switch over to the directory where we created the Git repository, and call it "RunbookCA1." I'll close that file and create a new one. Again, I'll just put in a stub command called get-process, and save that as "RunbookCA2." Now, we've created two runbooks inside of our Git repository. But we need to commit those to our Git repository and then push the code up to GitHub.
So, let's click on the changes button, where you'll see that changes have been made. As you can see, there's two new files that are added to the repository, so let's just call this "Initial Commit." We added two runbooks to our Git repository." Okay. So now, we're going to make our initial commit into our repository. Now that the initial commit has been created, we need to push it to GitHub, so we'll simply click the publish button. As you can see, GitHub is going to create a new repository on GitHub, and we're going to just click the button to publish.
Now that the changes have been published up to GitHub, let's go to the GitHub website and confirm that they've been made. So, I'll come out to my repositories and sure enough, there's a repository called Azure automation CA. The two runbooks, RunbookCA1 and RunbookCA2 show up in the list here. So, let's switch back over to the Microsoft Azure portal, we'll go ahead and close out that source control tab, and reopen it. Because we've already authenticated to GitHub, we don't need to reauthenticate. We simply click the authorize button, and it will automatically pass through our existing token.
Now we have to choose the repository that contains our runbooks. So, let's scroll down here and find the AzureAutomationCA repository. Next, we need to choose the branch inside the repository and because we haven't created any custom branches, we'll simply have the master branch. We also need to configure the runbook folder path, and in this case, we just put our runbooks under the root, so we'll just provide a forward slash. However in your repository, you may have a subfolder in your repository called, Runbooks. So, you can specify /runbooks. Okay.
Now, we've configured all the settings for setting up source control, so we'll click the okay button. The source control integration button changes and it shows that a repository synchronization is going to occur. Let's go ahead and click the sync button in the repository synchronization screen to ensure that the synchronization occurs. As you can see, a new job has been queued up, and it will run momentarily.
The synchronization job is now completed. So, let's go ahead and close out the synchronization blade, and then we'll go up to our Azure automation account blade and click on Runbooks. If you click the refresh button, you'll refresh this view, and you can now see that RunbookCA1 and RunbookCA2 have now shown up inside of our automation account.
Now that the synchronization has occurred, we can also make edits to these runbooks directly in the Azure automation service. If you select one of the runbooks and then click on edit, you can edit the runbook directly in the portal. Let's add another command, called get-process again just to make some change to the file. Click the save button, and then you'll see that because we have source control integration configured, there's actually a GitHub check-in button here. So, click the check-in button, and then click yes to confirm.
Let's go back to our automation account blade and we'll take a look at the source control integration. Because we made a check-in from the Azure automation service, to make a change to one of our runbooks, we're doing a synchronization job that will sync the updated runbook inside our automation account, back to our GitHub repository. As soon as that job completes, we'll be able to go to the GitHub website and see that the change is reflected in our repository. If we want to continue authoring the runbook locally on our system using the PowerShell ISE, we can use the GitHub desktop utility to perform that synchronization, and then start editing in the ISE.
Now that the synchronization job is completed, let's go out to GitHub to confirm that the changes have been reflected there. We'll pull up the Azure automation CA repository and sure enough, you can see that the RunbookCA1 was updated from Azure automation. If you click on commits, you'll see all of the different change sets that have occurred since we created the repository.
Now, let's go over to the GitHub desktop client and we'll check for changes. So let's click the sync button. We can see that there is a change. So now, let's go ahead and open the file locally. Because of the Windows file associations, the file is going to open in the PowerShell ISE, and you can see that the changes we made inside of Azure automation were synchronized to GitHub, and then from GitHub down to our local system by using the GitHub desktop client. And we can now continue editing that runbook inside of our local environment.
That's all there is to setting up source control integration with Azure automation.
About the Author
Trevor Sullivan is a Microsoft MVP for Windows PowerShell, and enjoys working with cloud and automation technologies. As a strong, vocal veteran of the Microsoft-centric IT field since 2004, Trevor has developed open source projects, provided significant amounts of product feedback, authored a large variety of training resources, and presented at IT functions including worldwide user groups and conferences.