In a recent post I discussed a case for multiple Azure automation accounts depending on the environment that is being targeted. In this post, I would like to expand on some process considerations for developing on the Azure automation platform.
1) I prefer the ISE add-on modules over the built-in editor
While there are probably many methods of creating Azure Automation runbooks, the two most common are to use the build-in portal editor or the Powershell ISE Authoring Add-on. From a development perspective, I much prefer the ISE add-on. It has a very easy workflow for creating and testing runbooks. When I am doing development, I am usually connected to the dev version of my automation account. I can then do something like the following:
- Edit runbook locally (Puts runbook in EDIT)
- Upload runbook via built-in command (Puts runbook in EDIT)
- Use the built-in test to run a job
- When I'm satisfied, click on the publish command (Puts runbook in PUBLISHED)
What I really like about this method is that intellisense works on all child runbooks (provided you have them downloaded). I have always found the intellisense in the portal version to be lacking in almost all usecases.
There are a few things that I would love to see improved in this add-on. First of all, when you open a runbook it automatically gets put in "EDIT" mode in the portal. I really don't like this as it should only be in edit once I have actually started editing or on first "upload" to Azure. The second thing that is tricky is that you cannot "sync to source control" from the ISE plugin. You can sync from, but that isn't the use case.
In order to keep github in sync, I generally log into the portal after my edits are complete (and I'm happy with them). From there
- Edit the runbook via the UI
- Click the Github sync button
- Click the publish button
This process is painful, and I'm hoping to build some code to create a better process. The main blocker is the fact that the runbook used to sync automation to github (and vice versa) is not a "callable" runbook.
2) Use ARM templates to keep multiple Automation Accounts in sync
When I am doing work in Azure automation, especially when we are trying to automate IT operations, I am always trying to determine the best location for variables and credentials in the system. Obviously Azure Automation credential store is a no-brainer, but variables can be placed in several locations depending on the need and ability of the team supporting it. In order to keep automation accounts in sync, I find ARM templates to be the best way. The process would look like the following:
- Make edits by hand using the portal until a pattern/process has been established
- Use the "automation script" functionality of the portal to export an ARM template
- Deploy the ARM template to test and production as required
Automation has pretty rich ARM template support, as you can see here.
3) Use workflow where possible, where not possible, use workflow anyways
I'll be honest, most of my powershell scripting these days is starting to go down the path of workflow. While workflow can have it's challenges, I find it a much better way to write my IT automation scripts. There are two main reasons why I tend to write workflow over regular scripts
- Parallel processing saves money
Remember that Azure Automation charges by the minute that a job is running. In many cases, parallel processing can greatly increase the speed at which your runbooks finish.
- Easier to enforce order
I find the sequence/parallel tags in workflow a convenient way to enforce order of operations in IT automation processes.
If you are interested in learning more, there is a great resource that details some of the considerations for writing workflow in Azure Automation.
No comments:
Post a Comment