In today’s Ask the Admin, I’ll take a look at what Azure DevTest Labs has to offer developers and sysadmins.
For organizations that don’t have the luxury of a private cloud, platforms like Azure allow quick and flexible deployment of test and DevOps environments. It wasn’t that many years ago that I remember deploying twelve physical servers for a development environment that needed to be procured and then configured and managed manually; all of which are time-consuming and resource intensive tasks.
Azure DevTest Labs brings together many of Azure’s existing features, and some new ones, in a package providing self-service automation for the deployment of sandboxed test and development environments, isolating lab resources in a subscription so that access, costs and change control can be managed effectively.
Virtual machine deployment
Azure DevTest Labs utilizes Azure Resource Manager (ARM) templates to automate the deployment of virtual machines (VMs). VMs can be deployed in advance, using the latest gallery or custom image, so that they’re ready to go the next day and be claimed by a DevTest labs user. Auto start can also be set up to make sure there’s no waiting around for VMs to be started. As you configure a new VM, an ARM template is generated to represent the deployment and can later be exported and shared with other teams using a public repository.
There’s an audit log that keeps a track of lab deployment and configuration events, although currently the information there is limited. For example, it doesn’t show which user performed an action. There’s also a handy Cost by resource table showing a breakdown of the estimated lab cost by resource for the month.
Formulas and Artifacts
Formulas (reusable bases) are ARM JSON templates and are used to save you having to manually configure VMs each time using the Azure management portal. For more information on ARM templates, see “Provision a domain using a Microsoft Azure Resource Manager template” on the Petri IT Knowledgebase.
Artifacts allow components to be added automatically to VMs. For example, Office or the Azure PowerShell module are available in the list of default artifacts. Or you can run your own PowerShell or Chef script, and parameters can be specified. Artifacts can be used in conjunction with Formulas to provide an extra level of flexibility.
Cost thresholds and quotas
In a bid to help control costs, VMs can be set to automatically shut down at a specified time every day. There’s also the option to exclude VMs from auto shut down policy if needed. Each DevTest Lab can be configured with a monthly cost limit, and Azure will generate a warning when you’re approaching that figure. A limit can also be set for the number of VMs that each user can create, which can be overridden per user if required.
Role-Based Access Control (RBAC)
One issue I’ve found with Azure is that until now it hasn’t been possible to give users access to use and create resources, but also prevent them from accessing resources in a subscription that might not be connected to the project they’re working on.
DevTest Labs users have all rights to the Azure subscription removed, with just the ability to use resources that have been deployed in a lab. There are five roles in total to choose from, including Contributor (manage everything except user access to resources) and User Access Administrator (manage user access to resources).
While not unique to DevTest Labs, locks allow sysadmins to apply read-only access or delete protection for all users on a particular resource or resource group (RG).
Support for containers and development tools
Labs can be provisioned from within Visual Studio. There’s also support for containers and a healthy GitHub community that provides Artifacts and ARM templates for use in DevTest Labs.