Execute local scripts as a part of bicep deployment

[stewartadam]

Is your feature request related to a problem? Please describe. I would like to be able to execute scripts on the host triggering a deployment as a part of the deployment sequence. Complex deployments usually have some portions of infra that depends other infra + some data plant configuration, so some 'glue' scripts that interact with dataplanes or manipulate local data are required in order to facilitate the subsequent infrastructure steps.

While these steps can be facilitated by breaking Bicep into several stages, it requires creating multiple stages of Bicep templates with outputs (or key vault secrets), mapping those to variables in the shell scripts, and then running the shell scripts in between each Bicep stage -- that's a lot of boilerplate and fragmentation for consuming the data outputs that are immediately and readily available within the bicep templates.

Say you go ahead and do that, then you run into a bunch semi-related and frustrating issues like:

• 4917

• 1410

• 4023

• 387

• 2163

• 893

Tangent: And even if you work around/solve all that, you might be tempted to use a common parameters file to ensure existing resources from prior stages can be referenced exactly without having to declare a parameter file for each bicep stage and risk making a typo - except that cannot be done because parameters must exactly match the bicep file - the parameters file cannot contain extraneous parameters that are not declared in a bicep file. So at this point you look loading JSON but it seems insane to completely circumvent the native parameter functionality.

Terraform handles this neatly with local-exec to provide script execution inline with IaC declarations and to be able to consume available resource properties directly. Some use cases I've bumped into in the past that local-exec helped with:

• Calling external APIs using output from the deployed infra (e.g. often by pulling a connection string from a newly deployed resource).
• Similarly; if a solution is hosted in Azure but leverages some 3rd party services unmanaged by ARM, local-exec can bootstrap those resources managed externally by calling a CLI or HTTP API
• Generating PAT tokens in DataBricks after a cluster is deployed

Describe the solution you'd like I'd like a resource type that executes a local script similar to local-exec:

• Executes a script or binary on the host running the deployment
• Resource dependencies are evaluated to kick off the script at the right time (i.e. I might want to run the script after deploying a new Key Vault, and pass an output like the new Key Vault's resource ID to the script)
• Other resources can depend on the local script resource, and will wait until it has executed

[stewartadam]

Note that such a feature might also require something similar to a null_resource.

[alex-frankel]

Duplicate of #417, but going to close that one as this is a bit more detailed

[slavizh]

+1

[taehokangithub]

It seems it'll take more time - has anyone found workaround for this? I'm converting Terraform to Bicep and this is one big missing part

[alex-frankel]

Just for context, Bicep/ARM Template deployments are evaluated service-side today, so there is no physical way to do something like TF's local-exec which is a client-side operation. In theory, we can transition to running the deployments engine locally, but we are not close to being able to do that.

In the meantime, the only workaround is either to break your deployment into different parts and run your scripts locally in between deployments, or you can use a deploymentScript resource which will run the script service side.

[aczelandi]

@alex-frankel - thanks for providing some workarounds. Deployment scripts are problematic when it comes to accessing resources that are running in a VNET because the container instance (in which the PS script is ultimately executed) can't be placed within the VNET. The same thing has been discussed in #6540 - would you have some pointers to that?

[alex-frankel]

I would follow #6540 for any updates. We have been working on adding support for it recently, so I'm hoping we have an update in the next 2-3 months.

[cw-andrews]

Any updates on this?

[alex-frankel]

@cw-andrews - in the short term, we don't have a way to enable this because Bicep/ARM Templates are evaluated service side. See: https://github.com/Azure/bicep/issues/7259#issuecomment-1230529105

[ghost]

Hi stewartadam, this issue has been marked as stale because it was labeled as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thanks for contributing to bicep! :smile: :mechanical_arm:

[stewartadam]

/reopen

[stewartadam]

What is the author feedback required?

[alex-frankel]

I think that label was stale. Thanks for bumping the thread.

[khowling]

+1 use-case -> trying to provide devs a single az deployment group create to create, build & deploy an Azure Container Apps app. All resources provisioned by bicep fine, ACA uses bicep as its deployment api, to that's great. But unfortunately, couldn't get a bicep ACR build tasks to work, couldn't get deploymentScripts to access my locally cloned repo. So now I need to give devs a script or set of commands, to (1) provision Infra (2) run the az acr build, then (3) run the bicep to deploy the container app. Really want to reduce friction where possible

[marsontret]

@stewartadam I wonder if this will be satisfied by #14243.

The spec doesn't seem to be publicly released as yet so I'm not sure what the goal/implementation is, but looks very interesting!

One of my questions for local-deploy is are you going to have to choose between normal server-side deploy at run time? Basically, will you have to create specific local templates?