Azure Image Builder Series - Shared Image Gallery
Continuing the Azure Image Builder Series, we take a closer look at performing image network security customizations using an externally hosted Shell script, enforcing a password policy, installing a specific docker version and finally deploying the image to a Azure Shared Images Gallery.
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
- Azure Shared Image Gallery
- Preparing permissions
- Create the template
- Building the image
As mentioned in the first post of this series we will take a real-world scenario where we will perform basic security and service configurations on a CentOS 7.8 image. You can take this example and modify it, to fit your specific needs. Although taken from a real-world scenario, the customizations made in this blog post are straight forward to help you to get started with Azure Image Builder, especially if you are new to VM image customization.
The scenario were covering comprises the need for developers to easily deploy their own docker hosts since company policy forbids to run docker locally. Company policy also dictates the security configurations that have to be performed.
To ensure the developers easily can deploy a docker enabled virtual machine, which also allignes to company standards, we will provide them with customized VM images using the Azure Shared Image Gallery.
Azure Shared Image Galleries have been introduced by Microsoft to provide Azure customers with the possibility to streamline the custom image provisioning process. The core features comprises the following:
- Sharing across subscriptions
- Global replication of images
- Versioning and grouping of images
In our scenario we use a Azure Shared Image Gallery to provide our developers with a simple way to deploy CentOS pre-configured virtual machines. Although not part of this blog post series, with Azure RBAC and Azure policies its possible to enforce the usage of the Shared Image Galleries for Deployment.
To create a new Azure Shared Image Gallery we need to run the following command(s):
After creating the Shared Image Gallery we need to create an image definition which holds the information and requirements for using it. As the name suggests, it basically defines the image we are going to create. We specify the following parameters:
- Image definition name: The Name for the image definition.
- Publisher: Usually your Company or Department name.
- Offer: Name of the offer. Can be freely set, usually points to the operating system.
- SKU: Stock keeping unit. If youre offering different specializations of your image you use the SKU parameter to separate them.
The Azure Shared Image Gallery and permissions prepared in this blog post assume everything is created in a single resource group. If you need to use an existing Azure Shared Image Gallery make sure you extend the scope of the Azure role definition to ensure sufficient permissions for your image builder identity that was created in the introductory post.
The Azure role definition for our image builder identity has to be updated to enable distributing the image to a shared gallery. Therefore we update our role definition with the following actions:
Since we want to update our currently existing role definition we need to get the name of it:
# Get your role definition name from previous setup
After retrieving the value we need to write it to a variable:
# Fill in your role definition name
With this step, all prerequisites are met to update the role defintion in Azure. To get a quick look at the role definiton click here. Run the following commands in order to complete the role definition update:
# Update the role definition for publishing images to Azure Shared Image gallery
The template that has been pre-created for this post can be found here. Since this blog post aims towards highlighting features of Azure Image Builder the operating system configurations made wont be explained in detail. A short summary of the custom CentOS configurations made in this template:
- Enhance basic network security with kernel settings
- Enforce a password policy
- Install and enable a specific docker version
Running the following commands in order creates a local copy of the template on your computer ready for submission to the Azure Image Builder service:
# Create new template for deploying image to Shared Image Gallery
There are various ways to apply certain configurations to virtual machines. Find the ones that works best for you. A set of configurations that achieve a common goal are often grouped in scripts and executed together while a single configuration often can be applied using a simple oneliner. In our example we created two Shell scripts and one inline customizer to perform the required configurations. They scripts can be found here:
Take a good look at the template before moving on to the next section. It will help you to understand how Azure Image Builder templates are constructed. Follow this Link to get a detailed description about the sections of a template.
With the template created we can submit it to the Azure Image Builder service:
az resource create --resource-group $rg --properties @sigImgLinux.json --is-full-object --resource-type Microsoft.VirtualMachineImages/imageTemplates -n cosDockerDefaultSig
and finally, start the image build:
az resource invoke-action --resource-group $rg --resource-type Microsoft.VirtualMachineImages/imageTemplates -n cosDockerDefaultSig --action Run
The image build can take up to 20 minutes!
Dont forget, that Azure Image Builder creates a resource group where it stores the template and template-relevant resources. This storage usage occurs small costs so make you delete the resource group if you dont want to persist this data.
Deploying an image to an Shared Image Gallery is just as easy as deploying as managed image or as vhd. Azure Image Builder in combination with Azure Shared Image Galleries allow Azure customers fine-grained control which images are deployed in their Azure environments and which configurations are made beforehand to support company policies.