Working with Azure Image Builder

Virtual machines have been part of cloud infrastructures since the early days of AWS and Azure. They’re key to bringing familiar workloads to the cloud, allowing existing applications and skill sets to lift and shift from on-premises to a global-scale platform. The resulting virtual infrastructures are now coming back to our data centers, running on hyperconverged hardware where dense compute and virtual storage act as a bridge between traditional architectures and cloud-native environments. Even as cloud platforms move to providing serverless functions and offering more effective PaaS, the familiar IaaS business model remains important.

Managing virtual infrastructures by managing VM images

A well-designed virtual infrastructure builds on common images, using them as the foundation for applications and services, simplifying both management and maintenance. With a standardized image you can bake in security and configuration settings, as well as define common policies and software installations. It’s a process that takes discipline and time, both in building your image creation pipeline and in training developers and administrators.

It’s important to ensure that only the images in your repositories are used, as any that don’t meet your standards could be a back door into your systems, adding unexpected weaknesses to a security model. You need to respond quickly to user demands for custom images; otherwise, they might be tempted to deploy unapproved images just to get the job done.

Increased demand for images causes a new problem: They take time to build and more time to customize. What’s needed is a way to automate the process and bake it into your continuous delivery pipelines so that applications are built and deployed on the latest images. That approach allows you to begin the shift to idempotent infrastructures, tying virtual infrastructures to builds and deployments, ensuring that every change to an application is deployed with a complete, secure, and tested infrastructure.

Introducing Azure Image Builder

Microsoft’s answer to this question is currently in public preview. General availability was originally scheduled for the fourth quarter of 2020 but is currently delayed. Azure Image Builder builds on HashiCorp’s open source Packer image creation tool, integrating it into the Azure command line and focusing on building both Linux and Windows Azure virtual machines. Packer produces both Hyper-V and VMware images for AWS, Google Cloud Platform, Azure, and Docker images. Microsoft’s version is purely for creating Hyper-V images, with support for Gen 1 VMs for both Azure and for on-premises Azure Stack instances.

The preview doesn’t have all the planned features, but it does have most of what you need to build and manage your library of images automatically. Start by using it to build baseline images that can then be modified and deployed once configured. It can patch images as updates release, ensuring that your library is up to date and that deployments have the latest security updates.

You should expect those features from any image builder. Things start to get interesting when you integrate Azure Image Builder with your existing devops environment. Here you can push configurations from Chef, Puppet, or, most importantly, from Microsoft’s own Desired State Configuration tool. With DSC you can set lower limits on configurations so that you have a base level of security and features that can only get better as systems update (of course, being careful to update your DSC definitions as well). There’s an option to integrate with any existing build pipeline, ensuring that changes to images are automatically deployed to repositories. If you’re using Azure Devops, there’s even a single simple task that handles everything for you.

Building VM images from code

Microsoft lets you work with most of the currently supported Azure base virtual machine OSes, including long-term support Ubuntu releases, SUSE Linux Enterprise Server, and Windows Server 2016 and 2019. This simplifies support, as there’s no option to use unsupported operating systems. You can use this to go from a custom OS image to application containers as part of a migration from on-premises to cloud native via Azure-hosted virtual infrastructures, knowing that your code runs on supported host OSes even in Azure’s managed Kubernetes.

It’s important to get the Image Builder permissions right. Azure uses managed identities to access resources, and you need to set up the appropriate permissions across resource groups, using an identity tag in your templates. You create the identity in the Azure CLI or in PowerShell and then add the appropriate permissions for creating, managing, and distributing images.

Under the hood, the service is based around a JSON image template, deployed and managed in the Azure CLI. This defines the VM image and its capabilities, which are stored as an artifact in an Azure Resource Group. Once the template is in place, Image Builder will download the source files for the image (either as a VM image or an installer ISO), along with any scripts needed to build your image. Images are built as they’re needed before they’re stored in your image gallery, ready for use.

The build process isn’t free. There are costs for compute, network, and storage resources, so don’t be surprised to see build charges on your monthly Azure statements. Most of the costs will come from storage and network, especially if you’re deploying images across multiple regions. Images should be stored in a Shared Image Gallery, which can be replicated globally, as well as offering redundant storage. Applications can be configured using ARM templates to build on these images, and high availability and targeted regional distribution should minimize the time needed to deploy an image.

Starting with predefined image templates

Microsoft provides sample image templates in a GitHub repository. These should help you get started, with a mix of ready-to-run quick starts and parameterized ARM templates for Image Builder. These last templates are the easiest to customize, though it’s probably best to begin with the quick starts to understand how to build and use image templates.

Once you have image templates in place and have configured Image Builder to deliver images as required, you can start to build them into your devops pipelines, triggering a VM image build as part of your application build, ready to inject application files and deploy, either to a test or a production environment.

Automating VM image creation and deployment is an important part of building a cloud-ready infrastructure for your applications. It gives you the ability to synchronize both application and VMs, ensuring that each build is on the most recent foundation, whether Windows or Linux.

This approach will change the way you build code, forcing you to rethink what a virtual infrastructure is and how you interact with it. Dynamic image generation is a logical part of any infrastructure-as-code approach to devops. Making it part of Azure’s IaaS model should encourage more development teams to deploy infrastructures as part of every build.