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 start, you need to tell your Image Template resource to kick off a build. I've seen 3 different ways you can accomplish this:
1. Invoke the Run action
The first way is to invoke the "Run" action against your Image Template Resource.
With the Az PowerShell Module, you can use Invoke-AzResourceAction:
With the Az CLI, you can use az resource invoke-action:
2. Az CLI
The second way I've seen is to use the Az CLI and run az image builder:
3. Azure Portal
The last way is also the easiest. Go to your Image Template resource in the Azure Portal. Then, simply hit the button for "Start build."
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. Which resources that get created will vary, based on settings you chose in your Image Template resource. Specifically, there are 3 possible scenarios:
Do not use your own Virtual Networking at all
Use your own Virtual Networking for the Packer VM only
Use your own Virtual Networking for the Packer VM and the Azure Container Instance (ACI)
In all 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 (and everything inside it) will automatically be deleted as well.
Option 1: AIB uses its own Virtual Network for everything
This is the simplest option. It creates an Azure Container Instance (ACI) which runs all of the Azure Image Builder logic. It also creates a VM which will run the build. To support all of this, it creates a Virtual Network, a couple of Subnets, and a Network Security Group. It places the ACI in the 'aci' subnet, and the build VM in the 'remote' subnet.
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: AIB uses your Virtual Network for Packer, and its own Virtual Network for ACI
There is a lot more going on in this option. Azure Image Builder creates a lot more temporary resources. This option utilizes 2 different Virtual Networks: one of your existing Virtual Networks, and a temporary Virtual Network that it creates in the 'Staging' Resource Group.
The automatically created Virtual Network is used to holds the 'brains' of AIB (the Azure Container Instance). Your existing Virtual Network is used to hold the build VM (therefore it has access to private resources). But, the ACI needs a way to communicate to the build VM. So, AIB will also create a Private Link Service, Load Balancer, Proxy VM, and a Private Endpoint. All of this is outlined in the diagram above.
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 Managed Identity being used by AIB 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.
To use this option, you must do the following in your Image Template:
Include the vnetConfig.subnetId option
Do NOT Include the vnetConfig.containerInstanceSubnetId option
Option 3: AIB uses your Virtual Network for Packer and ACI
This is very similar to Option 1. The difference is that you are using your own existing Virtual Network, and therefore, your build can access private resources. For this option, you must use 2 different subnets in your existing Virtual Network. One subnet will be used for the build VM. The other subnet must be delegated to 'Microsoft.ContainerInstances/ContainerGroups' and will be used for ACI. Your NSGs must allow traffic on ports 22 and 5986 from the ACI subnet to the build subnet.
The managed identity needs the same RBAC permissions as outlined in Option 2 above.
To use this option, you must do the following in your Image Template:
Include the vnetConfig.subnetId option
Include the vnetConfig.containerInstanceSubnetId option
Note: this option is available starting with API version 2024-02-01, so make sure to update your Bicep or ARM Templates for this new version.
Note: as of the time of this update, Option 3 is not supported when creating an Image Template by using the Azure Portal. The Portal simply doesn't give you an option to specify a subnet for ACI.
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.
Comments