TL;DR – Deployment Scripts is now Generally Available, and as part of this release we’ve made deployment scripts more reliable and easier to use with an improved permissions model.
Why do I need Deployment Scripts?
Often during an ARM Template deployment, there is an operation that needs to be performed that cannot be done natively in the template – either because there is no explicit support or because the operation takes place outside of Azure. For example, you may need to populate data in a database, deploy a Kubernetes manifest, or get a new IP address from an IPAM system. Customers will often fill this gap by running a script in a release pipeline or manually performing the task before or after the deployment occurs.
Deployment Scripts allow you to complete these “last mile” scenarios as part of your ARM Template deployments by running your bash or PowerShell script in a native Deployment Scripts resource. Deployment Scripts has been available in public preview for a few months, and today we are making Deployment Scripts generally available.
What’s new for GA?
With our GA release we are adding the following features and capabilities:
- You are no longer required to provide a User-assigned Managed Identity for the script to be executed. This is for use cases that do not require authentication to Azure, such as a data transformation or communication with a non-Azure API or if you’d rather use a service principal to authenticate to Azure instead of a Managed Identity. This makes executing deployment scripts much lower friction with less prerequisites.
- The underlying resources that are required for a deployment script to execute (Azure Container Instance and Storage Account) will no longer be created with the Managed Identity. Instead, we use the permissions of the AAD principal that created the deployment to create them. For a principal to create a deploymentScript they will now need the following permissions:
"Microsoft.Resources/deploymentScripts/*",
"Microsoft.ContainerInstance/containerGroups/*",
"Microsoft.Storage/storageAccounts/*"
We will use the permissions of the AAD principal executing the deployment to create these resources and register the underlying ContainerInstance Resource Provider. As a result of this change, the permissions granted to the managed identity can be more limited as it only requires what the script needs to run successfully.
- Better error handling for RBAC replication issues. You should now be able to reliably assign permissions to the Managed Identity in the same template that creates the deployment script without any authentication issues. This makes it easier to create a “self-contained” template deployment script template. During the preview, we noticed issues to do replication delays that prevented from working well.
How do I get started?
If you are already familiar with ARM Templates, getting started with Deployment Scripts is easy. Simply add a resource of type Microsoft.Resources/deploymentScripts to your ARM template:
{
"type": "Microsoft.Resources/deploymentScripts",
"apiVersion": "2020-10-01",
"kind": "AzurePowerShell",
"name": "[parameters('dsName')]",
"location": "[parameters('location')]",
"properties": {
"azPowerShellVersion": "3.0",
"scriptContent": "
$DeploymentScriptOutputs['test'] = 'test this output'
Write-Host 'I am a deployment script'
",
"forceUpdateTag": "[parameters('timestamp')]", // utcNow()
"retentionInterval": "PT4H"
}
}
Once the script has executed I can view the details of the script execution in PowerShell, CLI, or in the Azure Portal
For more details, take a look at the below guides and examples.
- How to: Deployment Scripts
- Additional samples:
We have seen a lot of awesome use cases be developed for deployment scripts during the public preview and we are looking forward to hearing how these new GA capabilities improve the experience even further. As always, if you have any questions or problems with deployment scripts, don’t hesitate to reach out at alfran@microsoft.com, on twitter or on GitHub.
Happy Deployment Scripting!