Azure Image Builder Series - Introduction
Azure Image Builder is a virtual machine image provisioning service on Microsoft Azure based on HashiCorp Packer. It has been designed to integrate natively with Microsoft Azure to allow customers to easily create and maintain virtual machine images for consistent deployments. This post is the first of a series to introduce the Azure Image Builder and its benefits by means of showing real-world examples.
This is a multi part series for Azure Image Builder with the following articles:
- Part 1 - Azure Image Builder Series - Introduction
- Part 2 - Azure Image Builder Series - Shared Image Gallery
Table of Contents
- What is Azure Image Builder
- Core features
- Differences between Azure Image Builder and HashiCorp Packer
- Setup Azure Image Builder (Preview) in your Azure Subscription
- Create first custom image
In May 2019 Microsoft announced the public preview of the Azure Image Builder as a service “[…] that makes building Windows and Linux virtual machine (VM) images easy in Azure […]”. The main goals Azure Imager Builder should help achieve are:
- fulfilling security needs
- meeting corporate and regulatory compliance rules
- preconfiguring VMs with apps for faster deployment
Since the documentation about the Azure Image Builder is currently thin and mostly integrated in the Azure VM documentation, I will cover a few real-world scenarios of the Azure Image Builder in this series starting with this introduction post.
Standardized VM images provide an easy way to ensure consistent deployments in the cloud. They can include security hardenings, custom files like certificates and ssh public keys, software configurations and custom software installations like company applications or other custom applications. All these modifications are performed using a single configuration file and submitted to the service which then build’s the custom image.
Users who are used to working with HashiCorp Packer will notice the similarities pretty fast and can use existing Packer scripts with Azure Image Builder. Although Azure Image Builder is based on Packer, it features some distinct differences which this blog post series will focus on. All those features are integrated into Azure Image Builder to help existing Azure customers adopting the solution with minimal effort.
Azure Image Builder is currently still in public preview with the expectation of general availability (GA) in Q3 2020.
The following features are available during the public preview according to Microsoft:
- Creation of images providing a single source of configuration
- Easy integration into pipelines since Azure Image Builder can be called directly
- Integration Azure DevOps (Preview Image Builder Azure DevOps Task)
- Integration into Azure Shared Image Gallery
- Integration into Azure Virtual Networks
- Output of the images VHD to support further processing outside of the Public Cloud (e.g. Azure Stack)
Most of these features outline the main purpose of the Azure Image Builder service. Offer Azure customers an easy-to-use and easy-to-integrate custom image builder service on Azure.
The main distinction between Azure Image Builder and HashiCorp Packer is that Azure Image Builder is a service offering where you don’t configure any computing resources that processes the templates and the image building. HashiCorp Packer, on the contrary, must be setup on your client or deployment pipeline before its ready to use.
While Azure Image Builder and HashiCorp Packer share the same foundation, Azure Image Builder introduced Azure cloud platform related features which enhance the integration into Azure. The first and very important of those features is the integration of a dependency on an Azure user assigned identity. This feature was introduced in the May 2020 update of Azure Image Builder and moves authentication and authorization from Azure service principals to Azure user assigned identities. I will explain how to setup this Identity in the next section.
Another important distinction between Azure Image Builder and HashiCorp Packer is that Azure Image Builder added a “Template Storage Layer”. This change derives from the service nature of Azure Image Builder and provides the service with a possibility to access all resources that are required to create the image independent from any client files. It will download the source image and any necessary files and scripts for the build process but doesn’t start the process of building the image automatically. All resources are stored in a storage account in a separate resource group, which is created automatically.
The storage of the source image, files and scripts on the automatically created Azure Storage account generates costs! If you want to minimize cost footprint using Azure Image Builder you should delete the image template after the build!
This section highlights the steps that have to be taken to enable the use of Azure Image Builder in your Azure subscription. These steps are necessary to follow along with the next posts in this series.
The first step is to check whether the feature has already been enabled for your Subscription:
az feature show --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview | grep state
If the command returns “state”: “NotRegistered” run the following command the register the feature:
az feature register --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview
A feature/provider registration can take up to 20 minutes!
To setup a user assigned identity with basic permissions run the following commands in order. Modify values as you see fit.
### enter your details
With this setup you’re ready to create your first managed image in the specified resource group.
The previous setup now enables us to create the first custom image. The first example in this series is a basic customization where the Ubuntu Linux system will be updated to the latest packages.
Prepare the following variables:
Next step is download the basic image template and modify it with your values:
curl https://gist.githubusercontent.com/rooftop90/fde35f56338ba0fac2f26370b0de9365/raw/ce938cd5a14647df87e54e5ba7990a7b345aa951/mngImgLinux.json -o mngImgLinux.json
Two more steps are now needed to create the image, first create the template:
az resource create --resource-group $rg --properties @mngImgLinux.json --is-full-object --resource-type Microsoft.VirtualMachineImages/imageTemplates -n UbuntuImageTemplate
And the last step is to run the image build:
az resource invoke-action --resource-group $rg --resource-type Microsoft.VirtualMachineImages/imageTemplates -n UbuntuImageTemplate --action Run
The image build process time is dependent on the size of the vmProfile section of the template. If your customizing tasks need more computing power, consider changing the size to a bigger one to meet your performance requirements.
I hope this post gives a basic understanding of what Azure image builder is, tries to achieve and how it differs in its approach from HashiCorp Packer. The next post in this series will cover a real-world scenario where we will create a set of custom Azure images based on CentOS and deployed to a Azure Shared Image Gallery. The configurations will comprise service configurations and security hardening. Stay tuned for the next post in this series!