...building hybrid clouds that can support any device from anywhere
At this point, you know the drill…This is Part 3 of the Automating Hybrid Clouds with Windows Azure and PowerShell blog series – which is kind of the same thing as Part 2, but this time the deliverable is a set of PowerShell Workflow Examples.
For reference, here is Part 1 (Intro & TOC), and here is Part 2 (Public Cloud Environment Provisioning PowerShell Examples).
Let’s get to it.
As covered in Parts 1 and 2 of this blog series, the following is the list of high level concept commands that will be covered in this post:
These are the same as they were in Part 2, but again for reference, here is the short list of pre-requisites for this example solution:
Okay, there are three new pre-requisites for this post:
Here is a short list of differences and notes based on my experience creating the Public Cloud Environment Provisioning Example Solution with PowerShell Workflow:
Other than these few things, you should be good to go!
I decided it would be neat (pardon the pun) to break this blog post into these 5 regions as well. Seems like a pretty organized and symmetric idea anyway… ;)
This section of the blog posts covers (references, rather) the necessary steps for an Established Windows Azure Subscription Connection.
This region is covered 100% in Part 2 of this blog series.
For reference, here is the link: Automating Hybrid Clouds with Windows Azure and PowerShell (Part 2): Public Cloud Environment Provisioning PowerShell Examples
This section of the blog post will cover all the PowerShell Workflow scripts required for the Public Cloud Environment Provisioning example solution.
Note I am breaking them up into individual scripts so that you can leverage them one at a time if desired. The complete script exists at the end of this blog post.
Now the fun can begin. This is the part of the PowerShell Script where I call all the above Workflows required to create the New Windows Azure Environment – called in a particular order, with specific logic. If you have your Orchestrator hat on, you can think of the Workflows as Sub-Runbooks, and the follow script (when compiled together) is the Process Runbook. In fact, the same exact concept exists in SMA – Process Runbook and Sub-Runbooks.
Note Once again, I am breaking up the main process script into multiple parts. This is so that it is easier to consume, and you can leverage it a piece at a time if desired. The complete script exists at the end of this blog post.
Note Just like in Part 2 of this blog series, $ProjectName is the over-arching variable that will be used (in part or whole) throughout the example. Many other variables are set based on this value. Be sure to modify this value to fit your project.
Note Again, like in Part 2 of this blog series, $AGLocation is the Location the Affinity Group for this Environment/Project is associated with – be sure to modify this value to fit your project.
Note No changes (unless desired) to the example variable values is required in this section.
Note Again, no changes (unless desired) to the example variable values is required in this section.
The following are some screen shots I took based on the execution of Region 2 above:
The fun continues! Now that we have a new Windows Azure Environment, we can upload an “On-Prem” VHD.
Note This region is pretty small and self-contained, so I have not broken it into pieces. Either way, the complete script exists at the end of this blog post.
Note I am executing the Upload-LocalVHDtoAzure Workflow with the -AsJob option. This allows me to use the Receive-Job command, to track and monitor the Job’s status.
The following are two screen shots I took based on the execution of Region 3 above:
Note The output here is not as verbose as it was when directly executing the Add-AzureVhd command. I chose this for the example to keep things simple. You can certainly extend this with more script logic and output.
On, and on! Now that we have the “On-Prem” VHD uploaded into the Generic Windows Azure Storage Container as a Windows Azure Blob, we can copy it over to the Project Specific Windows Azure Storage Container.
Note Again, this region is pretty small and self-contained, so I have not broken it into pieces. Either way, the complete script exists at the end of this blog post.
Note Because some time passes during the upload, I be sure to get the Azure Blog Info as a simple check. You obviously can do a more rigorous test, but this is what I went with for the example.
The following is a screen shot I took based on the execution of Region 4 above:
Finally - We have arrived! Now that we have a copy of the Uploaded “On-Prem” VHD (copied from the Generic Windows Azure Storage Container to the Project Specific Windows Azure Storage Container), we can Create a new Windows Azure VM Image, and then a Windows Azure VM (again, all based on that originally Uploaded “On-Prem” VHD).
Note Finally, while this last region is small, it does have two distinct parts. I have broken the script up by these two parts. And as you know, the complete script exists at the end of this blog post.
Note Once again, like in Part 2 of this blog series, there are a few variables that you will want to change to fit your project: $VMName, $AdminUsername, $Password, $Windows, $VMInstanceSize, $WaitForBoot. For more information about these variables, see Part 2 – Create Windows Azure VM.
Note I am executing the Create-AzureVM Workflow with the -AsJob option. This allows me to use the Receive-Job command, to track and monitor the Job’s status.
The following are some screen shots I took based on the execution of Region 5 above:
Note The output here is not as verbose as it was when directly executing the New-AzureQuickVM command. I chose this for the example to keep things simple. You can certainly extend this with more script logic and output.
It’s that time again – time to extend the length of this blog post beyond what was thought possible, by adding all the PowerShell Regions above into one script. Either way, here are all the above PowerShell script portions, rolled up into one script example (a cool 402 lines of PowerShell):
I covered a bunch of “post deployment” topics in Part 2. I will not be repeating them in this part of the blog series. If you are interested, be sure to check out the following sections of Part 2:
So, what’s next? This time, decreasing complexity! – Part 4 of this blog series lets you wipe the slate clean. It will be a pretty simple (in comparison) blog post that provides Windows PowerShell Examples to Deprovision all what you have created here (or with Part 2). You may be surprised how simple it is to “delete” everything!
I know, I know. This blog post doesn’t say much about SMA. That is intentional. It is really about providing the Windows PowerShell Workflow version of the example solution, to get you thinking. How might this be leveraged? I mean, how might it be leveraged over the straight Windows PowerShell examples from Part 2? All great questions.
If there is interest, I am happy to put together another blog post where I actually leverage the above script(s) in SMA. At this point, this blog post is already entirely too long. So, until then, keep your comments and ideas coming. And feel free to leverage the Building Clouds Blog Forum (http://aka.ms/BuildingCloudsForum) for questions/comments/discussions/ideas/etc.!
I broke this “Automating Windows Azure” topic up into four posts – primarily to make it easier to reference externally (based on varied interest levels).
As promised, the following is the link to the TechNet Contribution and Download for the examples (from all parts of the blog series).
The download (Hybrid Cloud Automation Toolkit - Windows Azure and PowerShell.zip) includes the following (4) files:
Download the Hybrid Cloud Automation Toolkit - Windows Azure and PowerShell from TechNet Gallery here:
Thanks for checking out this blog series! For more information, tips/tricks, and example solutions for Automation within System Center, Windows Azure Pack, Windows Azure, etc., be sure to check out the other blog posts from Building Clouds in the Automation Track!
Please can you help me, When i for example only run the Create-AzureAffinityGroup workflow as described i get the following error "Get-AzureAffinityGroup: value cannot be null" It looks like the param variables are not used.When i removed the param section and change the variables in the value i want, the AffinityGroup is created.Kind Regards,Arie Heukels
@Arie - When calling the Create-AzureAffinityGroup workflow, as long as the following command has valid variables, the workflow execution should work:Create-AzureAffinityGroup -ProjectName $AGName -AGLocation $AGLocation -AGLocationDesc $AGLocationDesc -AGLabel $AGLabelEach of these are defined above the command: $ProjectName = "BCBWFDemo" $AGName = $ProjectName $AGLocation = "West US" $AGLocationDesc = "Affinity group for $ProjectName VMs" $AGLabel = "$AGLocation $ProjectName" The actual workflow is defined above these calls (because it has to exist before it is called). If that is what you changed, then it would work, just not in the way this example intended. Either way, you can change these variable definitions and workflow examples as you wish.-Charles