Image Factory – Part 4: Set Retention Policy and Run Cleanup Steps


This is the 4th and final post in a series focused on leveraging DevTest labs to automate the creation of Custom Images in Azure.  Please refer to the 1st post for an overview of the solution, Introduction: Get VMs ready in minutes by setting up an image factory in Azure DevTest Labs, the 2nd post, Image Factory – Part 2! Setup VSTS and Factory Lab to Create VMs and the 3rd post, Image Factory – Part 3: Save Custom Images and Distribute to Multiple Labs.

Today we will cover setting a Retention Policy, cleaning up the Factory and retiring old images from all the other DevTest Labs in the organization. (Highlighted section in the diagram below)

Important note:  Any orchestration engine will work!  VSTS is not required, it’s just happens to be what we’re using for this blog series but the Image Factory is run using Azure PowerShell scripts, so it could be run manually, with Windows Task Scheduler, other CI/CD systems, etc.

Quick Review

If you’ve been following along with the prior posts, the following items should already be in place:

  • An Azure DevTest Lab for the Image Factory
  • One or more “target” Azure DevTest Labs where the factory will distribute golden images
  • A VSTS Project used to automate the image factory
  • Source code location containing the scripts and configuration (in our example, in the same VSTS Project used above)
  • A build definition (in our VSTS example) to orchestrate the Azure Powershell tasks

If you’ve already gotten this far, it means you have created and distributed your images and all that is left now is to clean up the environments.

Setting the Retention Policy for Distributed Images.

Before we configure the Clean Up steps, we need to define how many historic images we wish to retain in the DevTest Labs. Back in the 2nd blog post, Image Factory – Part 2! Setup VSTS and Factory Lab to Create VMs, we configured various Build Variables. One of these was ‘ImageRetention’. We set this to ‘1’. This means that the DevTest Labs will not maintain a history of Custom Images, only the latest distributed image will be available. If we change this to “2” then the latest distributed image plus the previous one will be maintained. You can set this value to define the number of historic images you wish to maintain in your DevTest Labs.

Cleaning Up the Factory.

The first step in Cleaning Up the factory is to remove the Golden Image VMs from the Image Factory. We have a script to do this just like our previous scripts!  The first step is to add another “Azure Powershell” task to the build definition as shown in the image below.

Once you have the new task in the list, click the item so we can fill in all the details!

Script Parameters

-DevTestLabName $(devTestLabName)

Retire Old Images from the DevTest Labs

This task removes any old images, keeping only a history matching the ‘ImageRetention’ Build Variable that we set at the start of this blog post. Using the same steps as above, we need to add an additional “Azure Powershell” build task to our build definition.  Details on what to fill in are listed in the image below.

Script Parameters

-ConfigurationLocation $(System.DefaultWorkingDirectory)$(ConfigurationLocation) -SubscriptionId $(SubscriptionId) -DevTestLabName $(devTestLabName) -ImagesToSave $(ImageRetention)

 

Verify it works - Queue the Build!

Now that we have completed the build definition, queue up a new build to make sure that everything is working!  After the build completes successfully the new custom images will show up in the destination lab and if you check the Image Factory DevLab you will see no provisioned VMs. Furthermore if you queue up further builds you will see the clean up tasks retiring out old custom images from the DevTest Labs in accordance to the retention value set in the build variables.

Note:  If you have executed the build pipeline at the end of the last post, please manually delete the virtual machines that were created in the Image Factory DevTest Lab before queuing a new build.  We did not have the ‘cleanup’ steps configured so errors may be presented if you do not manually clean up. The manual cleanup step is only needed while we set everything up and verify it works.

Recap and next steps

Now you have a running Image Factory that can generate and distribute custom images to your labs on demand. At this point, it’s just a matter of getting your images set up properly and identifying the target labs. As mentioned in the previous post, the Labs.json file located in your Configuration folder specifies which images should be made available in each of the target labs. As you add other DevTest Labs to your organization you simply need to add an entry in the Labs.json for the new lab.
Adding a new image to your factory is also very simple. When you want to include a new image in your factory you simply open the Azure Portal, navigate to your factory DevTest Lab, click the button to add a VM and choose the desired marketplace image and artifacts. Instead of clicking the Create button to make the new VM, click on “View ARM Template” and save the ARM template as a .json file somewhere within the GoldenImages folder in your repository. The next time you run your Image Factory it will create your custom image.

Here are some things you might do next:
1. Schedule your VSTS build/release to run the Image Factory periodically. This will refresh your factory-generated images on a regular basis.
2. Make more golden images for your factory. The process was described above, but you may also consider creating DTL Artifacts to script additional pieces of your VM setup tasks and include the artifacts in your factory images.
3. Create a separate VSTS Build/Release to run the DistributeImages script separately. You can run this when you make changes to Labs.json and get images copied to target labs without having to recreate all the images again.

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.

 

Nathan Jones, IT Service Manager

Nathan is part of the AI + Research organisation. He has been at MSR Cambridge, UK, for 13 years, working alongside and supporting researchers across multiple projects.

image Peter Hauge, Principle 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.

Comments (0)

Skip to main content