In the introduction to this series, I introduced you to my not-so-fictitious Client, which was using different toolsets for image creation and replication.
The question we are trying to answer (or at least provide clarity on), is: Should we create a custom image, or use the Azure Marketplace image?
We’ve already considered the value, steps, and things to be aware of, in relation to using Custom Images. Now we will dive into considering the Marketplace Images.
Before we go into the steps that are involved with using Marketplace Images in Azure, let’s first level-set on the value.
When you create a Virtual Machine from an Azure Marketplace Image, you are already using a sysprep’d and generalized image. You don’t need to manage and maintain it across your Azure subscriptions and regions, and you don’t need to perform the ‘rinse and repeat’ work to support multiple Operating Systems.
And with that, Microsoft maintains all the images with the latest patches and provides automatic and programmatic methods for including security/monitoring/management agents.
So, let’s say we’ve decided/determined that we want to use an Azure Marketplace Image for all of our Azure Virtual Machine deployments. Now what?
Well, to follow the same pattern described in the Custom Image part of this series, we’re not going to list the step-by-step, but cover the general steps in a summarized way.
Basically, in Azure, you choose the OS you want, provide some details (i.e. VM name, what network to connect to, ports to open, etc.), and then hit GO! Here’s a quickstart link to help you get started.
But this does not include items that you would have in your Custom Image, like tools, applications, agents, etc. But what we do have, is a programmatic and scriptable way to include some of those, via Azure VM Extensions. So, instead of having to include, say, a Chef Agent in a custom image, you could leverage the Chef VM Extension instead, and effectively install and configure it all at once. Couple this with other tools like Terraform, Chef, PowerShell DSC, etc. and we no longer have to maintain an image with software, OS hardening, we can just apply it as part of the VM creation process, keeping our base OS image as small and light as possible.
Keep in mind also, that the Azure Marketplace Images will already include all of the necessary optimizations specific for an image in Azure (which we have to perform manually before we upload the VHD to Azure). This also removes the need for creating (and maintaining) a Managed Image.
What we also get, that we don’t have with our custom image approach, is OS disk sizing options. In Azure, we can select the ‘SmallDisk’ option for an OS, and reduce our costs on storage; whereas with a custom image, we are locked-in to the size we built and captured it as. Sure, we could create a ‘SmallDisk’ version of our custom image, but that would also mean additional operational overhead.
For a comparison, a Windows Server 2016 Datacenter VM with a “normal” disk comes with a 127 GB OS Disk, whereas the ‘SmallDisk’ option comes with a 30GB OS Disk.
So all in all, it’s very easy and simple to build a VM from an Azure Marketplace Image, and we have a lot of flexibility for in-line customizations.
To Be Aware
This doesn’t mean that using an Azure Marketplace Image is perfect. There are still some caveats that we need to take into consideration.
For example, the Azure Marketplace Images are maintained and updated by Microsoft. This, of course, can be viewed as a positive thing, but let’s consider it from a different perspective.
What if you have a business-critical application that is affected negatively by a specific OS patch? You would then exclude that system from receiving that specific patch. But, in the Azure Marketplace, each image is fully patched, so you’re starting with a base OS image that contains a patch that will cause your application to crash/fail.
Now, of course, you could argue that the application should be updated to overcome the patch conflict (especially if it’s a Security/Critical patch), but the scenario is still something that should be considered.
The other element to all of this is that you must give at least some level of trust to Microsoft for the maintenance of the image. This includes your Corporate Security team signing-off that they are comfortable with using a Microsoft provided base image (and then, of course, layering on OS hardening, monitoring, etc. as needed).
The final piece I thought was important to call out, was around image versions. When you deploy a VM using the Azure Marketplace Image, you are automatically utilizing the latest version of that image. That in itself is not a bad thing. But, let’s say you wanted to standardize on a specific image version.
Notice the output of the following PowerShell command:
Get-AzureRmVMImage -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2016-Datacenter" -Location "CanadaCentral"
Even though we’re only targetting the Windows Server 2016 image, we can see a long list of versions. If you look closely, you can deduce the naming pattern: [os version].[os disk size].[year month day].
So this means that you could deploy a VM using the Azure Marketplace Image of “latest”, but have multiple different versions depending on the date that the deployment occurred.
Not a big deal, unless you need to account for the patches of a specific month (as previously mentioned).
So we’ve considered a lot of information on both the use of Custom Images and the Azure Marketplace Images. Let’s wrap this series up with an easy to digest summary.