If you don’t already have an Automation account, create a new Automation account in the Azure Portal, by navigating to New > Management > Automation and completing the required details.
Once you’ve created an account you’ll see it listed in the Automation Accounts blade.
Clicking on the Automation Account shows all of its details, allowing you to view and create the various resources, and see monitoring information for jobs.
In order to execute PowerShell scripts, whether they are regular scripts, Workflows, DSC or graphical runbooks, you need some form of credential. There is now a specific Automation resource for defining Credential assets. In the older post on this subject, certificates were used for authentication, but Azure Active Directory could also have been used to create a user with access to the subscription.
In this guide we will use an Azure RM AD service principal. With this you can assign fine grained role based access to the resources in your Azure directory. For example the service principal could be assigned the “VM Contributor” role for a specific resource group only. Or it could be assigned full access to an entire subscription. There are many built-in roles and you can define custom roles as well.
To learn how to create the service principal, follow the steps from a previous post.
Once you have a service principal, you can assign it to a particular resource with a particular role. For example navigate to the Subscriptions blade, and click on the Subscription you want it to have access to. Near the top right of this blade, there is a set of icons. Click on the “Access” icon (looks like two people and is highlighted red in the image). This allows you to assign user access.
From there select a role and add the service principal user. You can use the search box on the Add Users blade to find your service principal.
Now that the service principal has been given access to the subscription, an Automation Credential can be created. From the Automation account blade, navigate to Assets then Credentials and click the “Add a credential” button. Enter your service principal details.
Time to create the Runbooks! From the Automation blade in the portal navigate to Runbooks then click the “Browse Gallery” button. We’ll be using pre-existing graphical runbooks available in the gallery, built by the Automation product team. If you search for the text “azure arm vms” you’ll see the two Runbooks we’ll be using for this guide.
Clicking on the “Stop Azure ARM VMs” brings up a view that shows the graphical runbook in all it’s glory.
Clicking the “Import” button will bring this graphical runbook into your Automation account and allow you to alter, test and publish it.
Clicking the “Test pane” button will allow you to fill in the parameters the runbook requires and start the runbook and see the output. The parameters this runbook needs are:
- Resource Group name
- Azure Subscription Id Asset name
- Azure Credential Asset name
- VM name
The Credential Asset was made in a previous step. You’ll need to create a new Variable Asset for the subscription id.
If you successfully enter the parameters and test the runbook, you should see output that says it is Completed and that the VM has been stopped.
Once you’ve successfully tested the runbook, you can hit the “Publish” button.
Now that we have a published runbook to stop a virtual machine, we need to link it to a schedule, so the runbook starts automatically when we want it to.
From the Runbook blade, click the “Schedule” button, then “Add a Schedule”. First you need to set up a schedule to link to the this runbook. You can use an existing schedule or create a new one. When creating a new schedule you need to enter a name and when it should run e.g. daily at 20:00.
The parameters that will be given to the runbook on this scheduled run then need to be populated as well.
Once the schedule has been created, you’ll see that schedule on the runbook blade.
No comments:
Post a Comment