Where and how to use artifactsLocation and _artifactsLocationSasToken in Arm template deployments. Are these used only for nested deployments.
Can we use these for custom VM extension of the Virtual machine as part of post provisioning activity, after VM is built or should the extension be added as part of the VM build deployment template only.
VM Custom script extension - (Initialize and format data drives, Mount file shares for instance)
Azure quick start templates, have the parameter values for these as default for artifactsLocation and type securestring for _artifactsLocationSasToken. How these values are populated in the ARM deployment runtime.
It would be great if someone can provide documentation around the same / step by step process or share an existing working custom script extension template.
There's nothing inherent in the platform that makes _artifactsLocation and _artifactsLocationSasToken special... it's just a pattern (well used) that has developed for staging artifacts needed for a deployment. The pattern is to stage all artifacts together and then use the uri of the main template as a relative location. The defaultValue generally used for _artifactsLocation is:
"defaultValue": "[deployment().properties.templateLink.uri]"
The deployment() function is inherent and contains the uri passed in for the main template.
That said, you can use those values anyway you see fit and the primary use case is for retrieving any artifact needed by any resource. For example:
Custom Script Extension
https://github.com/Azure/azure-quickstart-templates/blob/master/demos/vm-winrm-windows/azuredeploy.json#L256-L259
MSDeploy Packages for WebApps
https://github.com/Azure/azure-quickstart-templates/blob/master/demos/private-endpoint-sql-from-appservice/azuredeploy.json#L277
DSC Configuration Modules
https://github.com/Azure/azure-quickstart-templates/blob/master/demos/iis-2vm-sql-1vm/azuredeploy.json#L585
etc, etc...
That help?
Related
I am using Terraform to provision my Azure resources which works great, however, for some resources such as Logic Apps, doing this natively doesn't really work so I am using the Logic Apps ARM template and doing a Terraform "azurerm_resource_group_template_deployment" in order to provision. I know doing an ARM template deployment within Terraform is a bit of a last resort. It works ok though and deploys fine but I have a Service Bus connection defined and that is of type "securestring". By default, these are not saved as part of ARM deployment so everytime Terraform runs in my pipeline, even if the Logic App ARM template has not changed, it still does the deployment as the top level deployment state Terraform knows about previously did not have the value saved so will always see it as new. Is there any way around this other than changing the "securestring" to "string" which I obviously do not want to do given the endpoint contains the SAS key etc?
Hit same issues today - really limits what is viable. Managed to work around my two scenario's.
For things like keys and connection strings you can use the listkeys function inside of the ARM template - some examples here. I had this exact issue trying to get a log analytics workspace key in to the template - https://github.com/Azure/azure-quickstart-templates/blob/master/demos/arm-template-retrieve-azure-storage-access-keys/azuredeploy.json - Get connection strings in ARM
Another scenario I had was wanting to pass a service principal secret from TF to template as securestring, to get around this I ended up getting the secret from keyvault inside of the ARM template instead.
I need to change the Azure DSC configuration that has been previously assigned to a VM.
I'm trying to do this programatically because it's part of an automation I'm developing and because of this, I'm using ARM Templates.
However, redeploying the same VM DSC extension by ARM Template results in an error stating a VM can't have two of the same extensions, which sounds logical.
What I want to know if it's possible to, by ARM Template, "update" or "modify" the current extension with just one setting changed: The configuration name.
Is this possible?
Sure - you can update the existing VM extension by providing new configuration in your ARM template. As you have found out, you cannot use a different name for the extension - that would result in two VM extensions of the same type on the VM. Instead, you need to reuse the same name of the existing VM extension when performing the update.
I have an ARM template, which I will be using it to deploy resources (Mentioned as in Azure Portal) via Azure DevOps Pipeline. These ARM templates were created using my Dev Subscription. If I need to use this same ARM template to move to production, I need to manually update the subscription id etc in the ARM template and then run the respective pipelines. Is there any way to automate this manual updation process in ARM template.
I have tried using File Transform Agent job available under Azure DevOps Release pipeline. But since the values are available inside nested loops of ARM templates, it failed. Is there any PowerShell script that will be suitable for this process of updating values.
I don't want to manually update the ids under the ARM Template. Instead, I want to update it automatically.
Set Json Property task might help to set the property with specific value.
First in the marketplace search for "set Json property" task and install it for your organization.
Then you can set the property path and the value accordingly. check here for detail usage
Instead of hard coding in ARM templates you can use parameters file. For dev and prod you can have separate files and while deploying pass ARM Template along with parameter file whichever is required.
You can use AKV (Azure Key Vault) to access your subscription details in parameter file
subscription().subscriptionid will get you the details
I have created a Function App for Containers using ARM template deployment using Azure DevOps Pipeline job (Azure Resource Group Deployment).
After deployment added additional configurations other than default configurations for Function App through portal.
For adding new resources, I have updated my 'template.json' and redeployed again. But this removes all my manual configuration of the existing Function App and set it to the default config settings in the template file. :( . Anyone please tell me a way for sort this problem.
Is there any property that helps to retain the resources and its configuration unchanged while deployment using ARM ? I used the property
"mode":
"Incremental" .
But this didn't work for me. It removes the existing configurations that I have created manually. Please suggest a best way to deploy and manage a resource using ARM. Is there any property or 'key : value' for adding additional settings to site config other than remove the site config and recreate it as inside the template default.
I think your only option is to set those configurations into the ARM template. ARM templates are not always incremental but are some time declarative as in this case.
You can switch to bicep, which has the ability to merge app settings. However, I don't have the details at the moment.
bicep wouldn't be a valid path to take. Except you can generate bicep from your source arm templates if they are 2019 or newer. That way the arm temples still drives the pipeline.
I wonder if terraform has the same options?
Getting started with ARM templates and trying to get a better understanding of what parameters go in a separate parameters file versus in the parameters section of the template itself. Do I have to have a separate parameters file? Seems like I can 't do a deployment from Visual Studio without identifying the parameters file.
You don't have to have a parameters file to deploy via ARM templates. You can certainly hardcode everything in your ARM template file if you like.
The next part is my opinion only on ARM template construction. I like following naming conventions for resources, such as [resource type]-[app]-[environment]. For example, a Web App for app Foo for the staging environment might be named wa-foo-prod. Following such a convention means that I can look at a resource and pretty much tell exactly what it's for.
That being said, I'm a big proponent of variables for naming resources in ARM templates. I might only pass in the environment and the region as parameters in an ARM template, then use variables to concatenate up all of the necessary resource names.
If every single resource name is passed in as a parameter, parameter management gets unwieldy.
As far as a required parameters file for deploying through VSTS, you may be right. But if you did NOT want any parameters, you could either deploy your ARM template through a Powershell script in VSTS, or just pass in an empty parameters file.