If you haven't already, please check out Part 1 of this series where I discuss how to create an Image Template.
In this article I will be discussing how to kick off an image build using your newly created Image Template. I'll also discuss what Azure does under the hood during a build.
To kick off a build you have to run a command against your Image Template resource. In the documentation, I've seen two different ways you can accomplish this.
The first way is to invoke the "Run" action against your Image Template Resource.
If you're running the Az PowerShell Module, then you can use Invoke-AzResourceAction:
If you're running the Az CLI, then you can use az resource invoke-action:
The second way I've seen is to use the Az CLI and run az image builder:
Under the Hood
What is Azure doing behind the scenes when you kick off a build? Well, it's doing quite a bit, actually. It automatically creates some resources that are needed to complete your build, and then automatically deletes them after your build is complete. The resources that get created will vary based on settings you chose in your Image Template resource. Specifically, there is a setting that tells Azure Image Builder to either use your own existing Virtual Network for the build, or to use a Virtual Network that it will automatically create and then destroy afterwards.
In both scenarios, Azure Image Builder will create a 'Staging' Resource Group (with a name that begins with IT_imageTemplateRG_imageTemplateName) where it will temporarily create all of the new resources. Once the build is complete, all of the resources will be deleted from the Resource Group, except for the Storage Account. The Storage Account is kept because it contains logs, and if you chose 'VHD' as one of your Distribution targets then it will also contain your new VHD file. It's important to note that if you delete the Image Template resource, then this 'Staging' Resource Group, as well as anything inside of it, will automatically be deleted as well.
Option 1: Azure Image Builder uses its own Virtual Network
This is the simplest option. Azure Image Builder creates a Virtual Machine which will run the build. It also creates a Virtual Network and Subnet, and places the VM's Network Adapter in the new Subnet. The Azure Image Builder service needs a way to communicate with this VM, so it creates a Public IP, attaches it to the VM's Network Adapter, and then creates a Network Security Group on the Subnet which allows inbound communication from Azure Image Builder's Public IP.
One drawback of this option is that the VM won't be able to access any private resources. For example, if you attempt to use a Shell Customizer in your Image Template that tries to access a private server, then it will fail as this auto-created Virtual Network has no communication path to your private server.
To use this option, simply omit the vnetConfig option in your Image Template.
Option 2: Azure Image Builder uses one of your existing Virtual Networks
There is a lot more going on in this option. Azure Image Builder creates a lot more temporary resources. One benefit of this option is that no Public IP Addresses are used. Azure Image Builder talks to the resources in the 'Staging' Resource Group by way of Azure Private Link.
You must ensure your existing Virtual Network is configured properly before running your build. The Subnet that you select must have Private Link Network Policies disabled. By default this is enabled on Subnets, and there currently is no way to disable this setting from the Azure Portal. See this link from Microsoft for various ways to disable Private Link Network Policies on your Subnet. Next, you must make sure the User-Assigned Managed Identity being used by Azure Image Builder has the proper permissions to your Virtual Network. At a minimum, it needs the following two permissions:
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
Here is a link to my GitHub repo where you can find an RBAC role definition that you could use to build a custom role in your tenant.
Lastly, if you have a Network Security Group attached to your Subnet, you must ensure that it allows inbound traffic from the AzureLoadBalancer Service Tag on TCP ports 60000 and 60001. The default security rules that are configured for every NSG allow this traffic already. So, a custom rule will only be needed if you override the default rules and block traffic from AzureLoadBalancer.
Well, I think that just about covers everything that I wanted to discuss regarding Azure Image Builder. I hope you have a better understanding about the service now and can appreciate everything that's going on under the hood.