2

My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.

However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.

The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.

The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.

The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.

Is there any recommendation of best practices to follow for this kind of scenario?

Thank you.

Link to the equivalent discussion on TechNet

José Maia
  • 310
  • 5
  • 21

2 Answers2

1

It is possible to update only via ARM templates. For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves. Ex. Account storage connection string.

Only first time creation of your web sites will take a bit more time, something like 30 sec.

ARM will not destroy your WebApps if they exist already. it will update only. If there are no changes, then the deployment is very fast.

If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository. and next deployment will pick up and update the WebApp.

So no need for anyone to log-in and update.

Dorin
  • 524
  • 3
  • 12
  • 2
    That would be the ideal solution. Unfortunately, from my tests and investigation, the app settings get completely replaced (see https://www.reddit.com/r/AZURE/comments/59vpuy/arm_template_is_supposed_to_be_incremental_but_it/) even in Incremental deploy. – José Maia Dec 22 '16 at 09:08
  • From the thread I understand that only modified sites got their Appsettings overwritten. So if you define all Appsettigns in ARM, then you should be fine. Unless all those connection strings are passed as a variable rather than picked from listKeys function. TBH it took me a while to figure out how to list required Connection strings in ARM. not quite straight forward. – Dorin Dec 22 '16 at 10:51
  • 1
    I do define all appSettings, but there are some that depend on user input on initial deploy - for example, configurations to connect to sendGrid. It will not be feasible to have the user remember these parameters and input them all again every time they want to update their installation. – José Maia Dec 22 '16 at 11:05
0

Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?

The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.

José Maia
  • 310
  • 5
  • 21