An early look at what is coming very soon with Deployments Stacks in Azure, how to use them, and how this further empowers your Bicep templates! Spoiler alert: it's awesome! 💪
💪 What is the challenge?
Azure deployments at scale also introduce life cycle management issues at scale. Ideally all resources within a resource group share the same life cycle and updates to that life cycle are limited to resources within that resource group only. When your Azure deployment increases in size, there is a good chance your deployments are going to span across multiple resource groups, multiple subscriptions and possibly even multiple management groups. This can make the life cycle management of Azure resources complex. Further more, there currently is no easy way to remove (destroy) all resources that are part of a logical collection in Azure. And lastly, it would be great to have the ability to ensure resources from a such a logical collection are protected (locked) from being removed individually. Azure Deployments stacks FTW!
💪What is a deployment stack?
A deployment stack is a new Azure resource type. (You can expect a public preview very soon!) It allows you to perform operations on a logical collection of resources in Azure. The resource type of a deployment stack is defined as Microsoft.Resources/deploymentStacks. The aim of a deployment stack is to simplify the life cycle management at scale mentioned before.
All Azure resources created using a deployment stack are managed by the deployment stack. This means that to update a resources, you update the deployment stack rather that individual resources, and removing resources can (should) also be done by updating the deployment stack.
And since a deployment stack is a Azure resource itself, you can also perform any familiar action on it like e.g. protecting access using RBAC.
You might also be familiar with 'complete mode' as a deployment method. (I've personally never been a big fan of it). This (legacy) deployment method is going to be replaced by deployment stacks.
This article covers how to get started with deployment stacks. It walks through the creation of a new deployment stack, deploying resources to it, and updating the deployment stack. Note: at the time of writing this, deployment stacks are in preview.
💪 Creating Bicep files to deploy with deployment stacks
As a first step, below is a sample main.bicep file. It contains a few parameters, points to a existing Resource Group and leverages a Bicep module to deploy a few resources related to Microsoft Azure Virtual Desktop (AVD) inside the referenced Resource Group.
Next, consider the file below. This the Bicep module that is leveraged by the main.bicep file containing the declarations to create a AVD Workspace, 2 Host pools, and 2 Application Groups. It does of course not configure all possible properties of those resources. To keep this walkthrough easy to follow its limited to setting a few properties only.
💪 Deploying the deployment stack (that did sounds a little weird 😊)
Now, use the 2 Bicep templates above and deploy the main.bicep to Azure attached to a new deployment stack. In this case we'll use AZ CLI, but you can also use PowerShell by making use of the CmdLet New-AzSubscriptionDeploymentStack.
The AZ CLI command outputs the result and shows resources that are attached to the Deployment Stack as well as the Deployment Stack Properties that are configured, covered in greater detail later on in this article.
These details can also be retreived using AZ CLI at a later stage, using the following command.
When switching to the Azure Portal, the Resource Group that was referenced in the main.bicep, shows the resources are created usefully. More importantly, they are attached to the deployment stack.
Inside the resource group we provided as part of the AZ CLI command, the Deployment Stack is now visible. Note the new section Deployment Stacks on the left hand side as well.
💪 How to tell which resources are linked to a deployment stack
Upon deleting to Deployment Stack in the portal (which can of course also be done using AZ CLI and PowerShell), notice that we get an overview of all resources attached to this deployments stack (marked red) as well as a couple of update behavior actions (marked green).
- Detach resources and resource groups means that the Deployment Stack resource will be removed and all currently attached resources and resource groups will no longer have a relationship to the Deployment Stack, but will not be removed from Azure.
- Delete all resources and detach resource groups means that the Deployment Stack resource will be removed and all attached resources will be deleted as well, the resource groups themselves will no longer have a relationship to the Deployment Stack, but will not be removed.
- Delete both resources and detach resource groups means that the Deployment Stack resource will be removed, and all attached resources including the resource groups we be removed as well.
💪 Modifying resources that are part of a deployment stack
Besides delete actions on the deployment stack, you can of course also modify resources that are attached to this Deployment Stack. You do this by modifying the deployment stack, rather than modifying individual reources. For this example, let's make a few changes to our main.bicep file.
- The load balancing type is changed from BreathFirst to DepthFirst
- A new parameter AVDHostPoolfriendlyName is introduced, and the corresponding Bicep module is also updated to accept the parameter and pass it to the creation of the AVD Host pool
- ValidationMode is changed from false to true
To update the resources that are part of the Deployment Stack, simply rerun the AZ CLI command from before. You will see the notification below. Note the confirm that the deployment stack already exists. A comparison will be performed and all changes that are needed will be applied to resources that are part of this deployment stack.
Switching back to the Azure Portal, all 3 changes are visible.
💪 Removing resources that are part of a deployment stack
Similar to updating resources that are managed by the deployment stack, resources can also be removed. Lets take drastic measures and remove a few resource declarations from our bicep module. The host pool and application group for RemoteApp have now been removed. This essentially leaves 1 workspace, 1 host pool and 1 application group as shown below.
Again, run the same Az CLI command. Note the warning. This shows what exact action will be performed on attached resources that are not part of the bicep template (anymore). In this case the action is to detach. This means the resources will be detached (removed) from the Deployment Stack, but will still remain in Azure.
The output of the command confirms the detached resources
And the Azure Portal also confirms this as shown below.
If needed, you can also change the default behavior of detach to remove resources or remove resources and resource groups. To change the behavior to delete resources that are detached, use the delete-resources option as shown below.
If we now redo the previous action again, removing 2 resource declarations from the Bicep template and rerunning the Az CLI command, the following output is shown, deleted resources.
And by looking at the Resource Group, the deletion of resources can be confirmed. Only 3 resources are left since the host pool and application group that were removed from the Bicep module are now also removed from Azure.
💪 Securing resources that are part of a deployment stack
There is one more interesting option to cover regarding deployment stacks and that is protecting resources from deletion. Using the deny-delete parameter, you can set a special type of lock on resources that are attached to a deployment stack to prevents them from being deleted by unauthorized principals.
In this case we enable the denyDelete and only make an exception for 1 principal by proving the application ID.
The result is that even you have permissions to remove the resources, you are blocked from doing so based on this remove lock. A great way to make sure that resources that are part of a logical grouping are not accidentally removed.
💪 Conclusion
I recall seeing very early architectures and ideas on deployment stacks, and I must say I'm really impressed with the implementation to date!
- Although the feature is currently still in private preview, I think working with deployment stacks is very intuitive.
- Deployment stacks unlock lots of great scenarios like removing resources from a deployment that reside across various different resource groups, subscriptions, and management groups providing similar functionality like the destroy option that e.g. Terraform has.
- Deployment stacks improve the overall life cycle management of Azure resources, it can prevent accidental deletion of a single resource that is part or a stack of resources that depend on each other and have the same life cycle, and it provides easy ways to rollback to a good known state.
The deployment stack feature will reach public preview VERY soon. I hope this early walkthrough was valuable to you. Stay tuned for more!💪
Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure
No comments:
Post a Comment