Azure Image Builder GUI – Gold-ish Disk Builder

As hard as it is to imagine the process of automating server disks being more provocative the Azure Image Builder service team has done exactly that.  At the end of March, they released a memo on the General Availability of the Image Template portal tool.  See here: https://azure.microsoft.com/en-us/updates/azure-image-builder-portal-functionality-now-available/.  Well today, I wanted to highlight some of the considerations on creating a custom build and some of the challenges.

First and foremost, this is not nearly as feature rich as the cli (meaning there are a lot more configuration options as one might expect).  This Image Template tool provides a workflow for OS team's (unless leveraging solutions like Packr are already old hat).   So how does it work and more aptly what does it build?

Azure Image Builder is ultimately a "templating" engine for building an operating system 'image'.

Before getting started first register the feature - Register-AzProviderPreviewFeature -ProviderNamespace Microsoft.VirtualMachineImages -Name MooncakePublicPreview (in Powershell but will be different for GovCloud). This permits the Resource Provider Preview Feature.  Now the real work begins in building out an image template.

The Azure Image Builder (technically in the portal this involves provisioning an Image Template) is composed of four key components:

1. Image Definition  -  Answers the questions of "what is the OS and where is it coming from", and then "how do I configure it?" These are the generic build instructions.
2. Image Customization - This defines the business requirements for the image. More specifically the tools (scripts and binaries) and environmentals in which to build from (vnet and sizing).  These customizations define the build path and require service principals, one for accessing the storage account for the scripts and secondly one for the images own identity (for the distribution target - more on that).
3. Image Validation - critical controls check to ensure that the build is compliant with the requirements.
4. Distribution Targets (or Error logging) - after the template build the end result is either an image or error output.

These components represent the general workflow for building an image.  While it seems straightforward, there are a couple of elements that left me scratching my head.  These are those surprises and the wisdom I was able to glean while building my images:

1. IMAGE DEFINITION
   1. Source (and technically Destination, or Distribution target) - what is the source of the image it can be either a Marketplace image or another image that has been pre-built see Generalizing a VM, (though technically you can build a specialized image).  Adding customizations, and then the first part is completed the Image Template Resource and creates its own Resource Group (i.e. IT_\<DestinationResourceGroup>_\<TemplateName>_\(GUID))
   2. Customizations - my one piece of wisdom in this space is regardless of the OS being templated ensure access to scripts and binaries (read-only) and please, please use the Checksum feature (to generate in Linux - sha256sum mySuperBuilderScript.sh) and then paste the checksum into the script view.  See image.

      

2. IMAGE CUSTOMIZATION
   1. Components - To build this into an image, it needs three things:
      1. A network - hopefully use an existing network, else it will take creative license and spin up a public IP address to finish the work.
      2. A location - technically moving isn't an option, but it obviously can be re-built, or if DR is your fancy replicated (with an Image Gallery)
      3. A permission(s) - deserves a bigger bullet, but considering the network and resource group that is created permissions should be fully considered here
   2. Access (bigger bullet) - From using / creating a network, a build resource group, to customizing and distributing the image consider the service principle (or more aptly user-assigned managed identity) access.  For more information see here, network security, and script / customizations.
3. IMAGE VALIDATION - another critical piece of advice please take advantage of validation.  Not only does this help ensure alignment expectations, but also will help mitigate unexpected errors. Again, take advantage of checksum if implementing a shell script!
4. DISTRIBUTION TARGETS -  So you have a bunch of new resources that pops out in the portal.  What are they?
   1. An Image Template Resource - Mentioned earlier it looks like this, if you would like to hand scrawl one for DevOps pipelines.  It's what is really being crafted by the portal.  It has the build instructions, and can be built simply by clicking on it in the portal and selecting the "Start Build" operation.
   2. The Build Creation - So everything in the auto generated resource group - IT_\<DestinationResourceGroup>_\<TemplateName>_\(GUID), can be deleted, if and when the Build has been created.
   3. The Output - Ideally create an Azure Compute Gallery.  It will provides some key features like: Image organizations by build, RBAC access, and replication (it is also leveraged by other services like Azure Batch).   Secondly and more succinctly, not to suggest that there will be failures, but errors.  A lessoned learned was that I required to disable the network policies on the auto created endpoints, I discovered this from the logs and by logs I mean the deployment logs.  An error message will appear during the template deployment and it will be straightforward in terms of finding the error (solving the error may be a different can of worms, but usually there is a referenced article).

Well I hope that this article helps point you in the right direction for getting started.  If you run into an unexplained errors or behaviors please comment below.

As always, "Grow passion by vision, knowledge through curiosity, and wisdom with compassion".

And most importantly thanks for reading!