Acknowledgement: This series of posts is contributed by Peter Hauge, Senior Software Engineer in Customer Success Team. He’s been driving a solution to help our customers to adopt Azure DevTest Labs.
We were recently working with a large enterprise customer planning on using Azure to host their developer desktops. This customer had a challenging set of requirements:
- Complex environments (lots of software + configuration)
- Need to save on compute hours (shouldn’t be running 24/7)
- Need a simple experience for teams to ‘request’ a new developer desktop
- The time from requesting a new Developer Desktop (Virtual Machine) to having it running must be less than 10 minutes
- They do NOT want to take on the cost of manually creating and maintaining custom images
Each of these requirements are easy to handle in isolation but once we put them all together it gets challenging!
We already have several great things built-in to Dev Test Labs that dramatically reduce the amount of time required to set up and manage infrastructure – we’d rather you were focused on the hard problems! Policies and thresholds dramatically reduce the time required to ensure you’re on budget with your costs. Artifacts and Formulas reduce the time required in setting up and configuring the Virtual Machine once it’s created. (If you haven’t tried DevTest Labs yet, click here to create your first lab. DevTest Labs is a free service!)
Introducing this Blog Series
In several upcoming blog posts, we’ll cover the following topics to enable anyone to setup, configure and run an image factory based on DevTest Labs:
- Introduction: Get VMs ready in minutes by setting up image factory in Azure DevTest Labs (THIS POST)
- Configure VSTS (GIT Repo + Release Pipeline) to Automate DevTest Labs with an image factory
- Create Virtual Machines in a DevTest Lab with an image factory
- Save Custom Images from Virtual Machines in a DevTest Lab with an image factory
- Scripting to Distribute Custom Images from a DevTest Lab with an image factory
- Scripting to Implement a Retention Policy in a DevTest Lab with an image factory
- Conclusion: Complete the image factory
In this blog post we’ll introduce the image factory, design considerations and reasoning behind the overall design. The following posts will go into detail on setting up the image factory so you can do it too!
What is Image Factory?
So, what is an image factory? How can it help get VMs ready faster? Simply speaking, An image factory builds and distributes images automatically on a regular basis with all the desired configurations baked in. The images in the image factory are always up-to-date, and the ongoing maintenance is almost zero once the whole process is automated. And, because all the required configuration has been baked into the image, it saves the time from manually configuring the system after a VM has been created with the base OS.
The big accelerator to get a Dev Desktop to a ‘ready’ state in DevTest Labs is using custom images. The downside of custom images is that there’s something ‘extra’ to maintain in the lab (trial versions of products expire over time, newly released security updates aren’t applied, etc) forcing us to refresh the custom image periodically. With an image factory, we have a definition of the image checked in to source code control and have an automated process to produce custom images based on the definition.
High-level view of the solution
The solution we’ve implemented enables the speed of creating Virtual Machines from custom images while eliminating additional ongoing maintenance costs. With this, we can automatically cook up custom images and distribute them to other DevTest Labs. We are currently using Visual Studio Team Services as the orchestration engine for automating the all the operations in the DevTest Lab.
We already have a VSTS Extension for DevTest Labs that enables users to execute these individual steps: “Create VM”, “Create Custom Image”, and “Delete VM”. Using the DevTest Labs extension is an easy way to get started with automatically creating custom images in DevTest labs! You can find more information about this process here: https://blogs.msdn.microsoft.com/devtestlab/2016/06/15/azure-devtest-labs-vsts-extension/ .
We also have an alternate implementation using PowerShell scripts for a more complex scenario (the focus of this blog series) – this is for fully automating an image factory based on DevTest Labs that can be used in your favorite Continuous Integration and Continuous Delivery toolchain. We followed several principles when we designed this alternate solution:
- Common updates should require no changes to the image factory. (for example, adding a new type of custom image, automatically retiring old images, adding a new ‘endpoint’ DevTest Lab to receive custom images, etc.)
- Common changes are backed by source code control (infrastructure as code)
- DevTest Labs receiving custom images may not be in the same Azure Subscription (labs span subscriptions)
- PowerShell scripts must be reusable so we can spin up additional factories as needed
In several upcoming blog posts, we’ll cover the following topics to enable anyone to setup, configure and run an image factory based on DevTest Labs.
Please let us know how we can continue to improve DevTest Labs by sharing your ideas and suggestions at the DevTest Labs feedback forum.
If you run into any problems with the features or have any questions, we are always ready to help you at our MSDN forum.
|Peter Hauge, Senior Software Engineer
Peter is part of the Visual Studio and .Net engineering team focused Visual Studio and Azure customers. He has been at Microsoft for 15 years, working on developer technologies throughout that time.