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
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.
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.
Related
I am trying to deploy an on-prem instance of Azure DevOps Server to a VM in an Azure Government subscription (which by nature, seems it does not support standard DevOps).
This template is referenced within support material directly from Microsoft:
https://github.com/usri/deploy_DevOps_Server_AzureSQL
All the referenced resources were created from scratch for the purpose of getting this server running.
This requires an AAD account with the associated password stored in a Key Vault. However, every attempt I make to run the template returns the following error on the 'Write VirtualMachines' step (when all other components pass):
The client has permission to perform action 'Microsoft.Compute/images/read' on scope '(MY_SUBSCRIPTION)\(MY_RESOURCEGROUP)\(VM)', however the current tenant '(MY_KEYVAULT)' is not authorized to access linked subscription '(ID in the template with the deployment files)'
This seems to me like the password cannot be retrieved from Key Vault- is it a formatting issue with the Secret? An access control issue somewhere? I've tried many various combinations of both. Hopefully this is just a trivial issue..
I am the original author of the code in that repo. I went ahead and merged a pull request into that repo which should address your issue. I did the following:
Updated the ReadMe file to include information on creating the image
Updated the azuredeploy.json with parameters for Key Vault & image references
Updated the ps1 file to eliminate hard links for KV (a particularly bad oversight on my part, my apologies).
Updated and tested everything for the latest version of Azure DevOps Server 2020
This should fix your issue and several other related ones. I retested the entire deployment from scratch and it worked as designed. A couple of other quick notes:
The USRI and all of it's repositories including the one being utilized here are not Microsoft official repositories. They represent an open-source Azure community dedicated to regulated entity customers. The members which contribute there are mostly Microsoft employees and the repos themselves just represent interesting and sometime niche templates that might be of interest.
This particular repo shows a manner in which Azure templates could be used to deploy services when no internet connection is available or permitted. I just used Azure DevOps Server because it was interesting and regulated industry customers use it.
All the best
We would like have a DR and staging subscriptions at my Azure. Also we do not want to pay for not used resources. We have Continuous deployment server. We would like to have the same deployment process in different environments.
Process
1.We read the current live subscription configuration from Azure resource manager
2.Modify some parts
3.Create DR and Staging
4.Deactivate them when not used using API calls triggered from the Continuous deployment server
5.Activate them when not used using API calls triggered from the Continuous deployment server
From time to time we are updating the resources.
Questions
What are the best practices ?
What are the API calls we can use?
I would argue that this is not possible (I might be wrong, never tried disabling subscription with active resources and see what happens) and not viable (for sure).
First of all, most PaaS offering cannot be switched off in Azure. That means you cannot achieve what you want (well, unless you can disable the entire sub and enable it after with all the resources starting to work like nothing happened). To try and figure the REST call to disable the sub I would go and capture the rest request with fiddler and try to reproduce it. Because I'm quite sure this call is not documented
The route I would go in this case - I would create ARM templates to make deployments repeatable and use those to deploy needed resources into prod\dev\stage\whatever with a flip of a switch. This would allow you to have the same deployment process you crave for.
Is there any way to save the complete state of my azure configuration?
Basically, I just created a demo for a project I'm working on. This demo has a website/webjob, scheduler, storage queue, storage blob, redis cache and documentDB. I have configured these components in terms of size/scale/schedules but now the demo is done.
I don't want to pay for these services and I don't need them online for now. However, I don't want to have to recreate and reconfigure them if I need to relaunch the demo in a month.
Is there a way to save my current azure configurations to a file and then to be able to recreate all the services again automatically (with a script or a small program)?
Thanks!
This is a very good question, that sums up a historical problem we're in the process of making easier and more flexible. I'll answer this question with two parts.
First and foremost, you have tools like the PowerShell cmdlets now, that you can script out the creation of an entire "world" in Azure and then re-run whenever you want, against a subscription, to scaffold out a whole architecture. You can also use the management libraries for .NET to do this from a .NET application. When we embarked on the VS WebJobs tooling, for instance, I worked up a prototype for my developers on using MAML to create WebJobs and scheduler job collections. You can see the demo code for that here: https://github.com/bradygaster/maml-demo-scheduled-webjob-creator
We've also recently embarked on new mission of re-creating a lot of the management APIs so that they support the notion of templates and resource groups, to marry up with the new portal experience. Here's a great MSDN article that discusses how the PowerShell cmdlets for the Gallery could be used to pull down a list of the various templates that could then be pushed back up as fully-baked architectures running in Azure. You have the capability of building these templates yourself, then you could use these cmdlets to fan out and create things that you write up in your own custom templates. http://msdn.microsoft.com/en-us/library/dn654596.aspx
Hope this helps!
For Azure websites you can use the Back and Restore option to store the site and restore it back when you want to demo again, But all you have to do is Stop the services and you should be able to keep the demo without incurring cost.
Would like to know how can i upgrade a single role of deployment application on hosted service using REST API.let say I have 2 web and 1 worker role and i would like to update/upgrade only one webrole out of 2 .I know that we can do it Azure Management Portal.
Would also like to know how rollback works in Azure.If I like to rollback deployment application to previous state, can i rollback?
You cannot modify the number of roles using the Service Management API. This is only possible by doing a new deployment (this is possible using the API).
The only thing you can do is modifying the number of instances by using the ChangeConfiguration request: Change Deployment Configuration
Rolling back a deployment to a previous state is possible using the REST API. What I tend to do when deploying a new version is by using a VIP swap:
I deploy the new version of my app to staging
I do a VIP swap (new version becomes production, old version becomes staging)
I shut down the staging version (without deleting it), this way the old version stops processing messages from queues etc.. in case my logic changed.
If I want to roll back, I simply turn the old deployment back on and do a VIP swap again. This way of working comes with 2 remarks:
You can only "revert" to the previous version of your app
You need to take into account that you might have changed external resources (like SQL Azure) and rolling back the application could break because of this change
Edit: Modified my rolling back answer with a link to the REST API
Good answer by #Sandrino. Just wanted to expand on in-place updates a bit. The Upgrade Deployment REST API call is what you'd use for updating a role. As Sandrino pointed out, you'll still need to push a new deployment package up (which includes all roles), but you can then specify to upgrade only a single role from the entire package by specifying the role name for the RoleToUpgrade element.
See this MSDN reference article on the Upgrade Deployment API call.
EDIT: All REST APIs are also available through PowerShell cmdlets (downloadable here). Take a look at Set-AzureDeployment, which has an Upgrade parameter set.
Let's say I have 3 instances in the Azure. Each is running separate layer of the application, as I described in this question Independent deployment of separate layers to Azure. For independent deployment of each layer (read Role) a separate Azure deployment project is created. The question is, what instance will be replaced, when I will be deploying, for example business layer? Can I be sure that the instances with UI and Data Access will stay untouched? How the instance to be replaced is found, based on name of the role?
To clarify, you have 3 layers, each hosted in a different windows azure role (not instance). If you have each role in a seperate deployment (seperate hosted services), then when you deploy, you are only going to be upgrading that layer. The other layers will not be impacted.
However if there are any signature differences, a dependent layer may break if the service its trying to call changes. Its for this reason that you want t omake sure any services support versioning and are always backwards compatible at least one version.
I've created a quick blog post with some screen shots of doing a single role upgrade. Note that the silverlight portal issued an exception for me while doing this and I've reported that error and will update the blog post if we find out what it was about.
Updated: There is bug in the silverlight management portal that currently prevents the performance of a single role upgrade. The Windows Azure team is aware of this and will be addressing it in a future update. No ETA for that update at this time. However, you can still perform the single role update/upgrade via the management API.
As Brent said, it is definitely possible to do a Single Role upgrade. It used to be that if you made any changes to the ServiceDefinition (change VM size, added new Config settings, updated Role Name or changed the instance count from the service definition that is currently deployed) when you upgraded that role, Azure Fabric Controller would not allow you to do in-place upgrade. Now, that is also possible. So you can do an in-place upgrade on Role and bump up the VM size. As always, you at least want to have 2 instances to ensure that you don't experience any downtime.
Ranjith
http://www.opstera.com