As the kids go back to school this September, the Azure learning continues and I’m pleased to be contributing once again to the Azure Back to School event. There’s so many great sessions this month and I’ve already learned a lot from the community contributions. My thanks to Dwayne Natwick and Derek Smith for organising.
In this post, I wanted to write about the Azure Compute Gallery. This service used to go by the name ‘Shared Image Gallery’ in the past but there were several limitations with the service and it never really received any new features over time.
The service was rebranded a few years ago now and since then we have seen some new features added and better support.
Today, this service can be used for storing both custom OS images and VM application images. With some important features like:
- Global replication
- High scalability (up to 1,000 VMs in a scale set)
- Version history
- Zone redundant storage support
- Confidential Compute VM support
- Trusted Launch (Generation 2) VM support
- Cross-tenant sharing (this is a big one!)
- Azure Image Builder support (another big one!)
The concept is pretty straightforward. The Azure Compute Gallery (let’s refer to it as ACG going forward), is a regional service that acts as a repository for all of your images. This services looks after the orchestration of the image replicas. You will need at least one image replica for every Azure region where you will use these images.
In other words, if you have for example Azure Virtual Desktop host pools in multiple regions like North Europe and West Europe then you will need to have at least one image replicated to both of these regions so that you can deploy from that image in that region.
Speaking of replicas, you may want to consider having more than one image replica per region. The reason? Scalability. If you will be re-imaging a lot of VMs from the same image the recommendation is to allow for a maximum of 20 concurrent deployments per replica. Otherwise, you may run into throttling issues.
The below graphic demonstrates how 5 image replicas can be used for 100 concurrent VM deployments.
Cross-tenant image sharing options
If you are providing a hosted desktop service to multiple customers then unless your are an ISV (Independent Software Vendor) providing a SaaS solution from a single tenant, you are instead going to need to access multiple customer tenants. This is because Azure Virtual Desktop does not currently have external identities support, meaning that you can’t provide access for guest (or B2B) users from external organisations.
Managing multiple customer tenants adds complexity and additional overhead at scale and although each customer may have unique requirements, it is likely that you will have many similar types of customers with broadly the same requirements in terms of applications and configurations.
Rather than creating a baseline OS image for every single customer, you may find that you can build a master OS image that will suit the needs of most of your customers with perhaps just a little customisation required for each. This saves time and money as it will only be hosted once. Furthermore, if you are doing your deployments manually then you are likely running into inconsistencies in your deployments – it’s human nature!
The concept here would be to build your master OS image and maintain this in an ACG that you host on your own organisation’s management tenant. This image could then be shared out to your customer tenants and the deployment initiated from those tenants.
The ACG supports several sharing mechanisms to other tenants:
RBAC – simple RBAC assignments to guest users in another tenant. When deploying in the customer tenant you will need to authenticate to both the management tenant (hosting the image) and the customer tenant. You will also require the imageID for deployment which must be performed via a scripted deployment. This means that an Azure portal deployment is not possible as you will not be able to browse the shared gallery images.
App Registration – create a multi-tenanted Entra ID application and give this access to your ACG. This works in a similar way to RBAC sharing except you are sharing (and authenticating) via an application rather than a user account. Similarly, you will require the imageID for the deployment which cannot be performed through the Azure portal.
Direct Share (Preview) – this feature is currently in preview and requires a subscription registration before you can avail of this option. This feature gives full access to the shared tenant/subscription but does allow for browsing the gallery, therefore an Azure portal deployment is possible here. The downside here is that there is no way to scope the access to individual identities on the tenant you have shared with and you must share the entire ACG as you can’t scope access to individual images. There are also some other limitations to this option whilst in preview such as it only supports a maximum of 5 shared tenants which would be quite limiting.
Azure Lighthouse
An alternative option and a better one in most scenarios I believe, is a service that I advocate for very much for anyone who provides managed services is to use Azure Lighthouse. This service provides delegated access from your management tenant to your customer’s Azure subscriptions on different tenants. This means that you can authenticate to your management tenant and perform a deployment directly to your customer tenant but accessing resources such as your ACG images hosted on your management tenant. In other words you would not need to explicitly share the images using this method. Deployments can of course be performed through Infrastructure-as-Code or scripted deployments but below are a few screen captures of what this would look like if performed through the Azure portal.
The real benefits of Azure Lighthouse are in the ongoing management of your customers however and something I have blogged about extensively previously. You can read more on that here.
Azure VM Image Builder
Azure Image Builder has been around for a while but it is complex and requires knowledge of Infrastructure-as-Code, scripting and likely DevOps to automate the whole process. Now, we have a template builder experience in the Azure portal. This service allows you to take your base OS image and customise it during a ‘build’ process where you run scripts on the OS to tailor the image to your requirements. These scripts might install new applications, perform OS and application updates or customise various settings on the OS.
The advantages of using this build process is primarily in automation and consistency, removing the overheard of a manual process which can often lead to mistakes and inconsistencies brought about by human error.
As is the case with ACG, your image build version history will be available so in the event that you ever need to roll back to an earlier build release, this will be easy to perform.
VM Applications
Another great feature of the ACG is the support for VM applications. For your Azure Virtual Desktop deployment, you may want to separate out the tasks of keeping the OS updated and the application maintenance. So rather than updating the entire OS image periodically you could instead maintain the individual applications by uploading the .exe or .msi installers to your ACG. These can be shared out in the same way as the OS images and Azure Lighthouse can also be used for a delegated deployment to customer tenants allowing you to manage the same applications across multiple customers at scale.
I think this is really nice option to have especially if you are already using the ACG for your image management. Otherwise, there are plenty of great application package managers out there like Chocolatey and Winget with the latter now integrated into Intune for deploying apps via the Microsoft store.
So which approach do I use?
The decision for your organisation in how you might manage a muti-customer scenario will largely come down to your current methodology and level of expertise. If you are still new to the world of Azure then you are likely primarily using the Azure portal for your deployments with possibly some scripting for automation such as PowerShell.
If this is the case, then the most straightforward method in my opinion would be to first implement Azure Lighthouse – I would recommend this step anyway for MSPs or anyone with multiple tenants to manage.
You can then set up an ACG in your management tenant and perform your deployments via the management tenant using an identity from your management tenant. This approach gives you visibility to browse your gallery images and continue to deploy via the Azure portal if this is what you are comfortable with. Over time, you can look to automate this by using the likes of deployment scripts, Azure Image Builder and possibly go full IaC and deploy through CI/CD via GitHub Actions or Azure DevOps.
The ACG built-in sharing feature might be more useful for scenarios where you want (or need) to manage your customer tenants in total isolation. In this case, you will be authenticating to the customer tenant directly for the deployment and then also to your management tenant so that you can access the shared resource from your ACG. This rules out Azure portal based deployments but ideally you will want to ultimately move away from this method of customer deployment. The downside to managing multiple customers in isolation is monitoring and management. These tasks become more complex and repetitive at scale without a centralised solution so do consider this when determining your strategy.
azurealan.ie 