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.
Related
I think I misunderstood Azure Web App deployment slots and have used them incorrectly.
We have a .NET Core 2.1 Web App that we wanted to upgrade to Core 3.1. Rather than upgrade the existing we wrote a new one from the ground up so we could refactor it a little at the same time.
So I created a new deployment slot in Azure and added the new Web App via its (different) GitHub repo. That's fine, the new slot Web App loaded fine and after testing we decided to switch to the new version.
On the go-live I removed all the custom domains from the 2.1 version, and added them to the 3.1 version, along with SSL (there are lots of domains that use the same web app via DNS mappings, which I updated to point to the new slot's CNAME), tested this and it all worked fine. I hit 'swap slots' and essentially nothing happened - the 2.1 app stays as 'Production', and 3.1 is still the a 'slot app'.
Now I've stopped the 2.1 app, and all our traffic is flowing to the 3.1 slot version, but this strikes me as a problem! I need to get rid of the 2.1 version!
Any ideas how to solve this? i.e. how to make (from the pic) 'eadgen-GenV2' the main/production slot, so I can delete the original 'eadgen'?
ref: my original question about this!
eadgen is your default slot and eadgen-GenV2 is a temporary slot, I think you can only delete the temporary slot. You can try to use this:
What will be swapped is:
General settings, such as framework version, 32/64-bit, web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Public certificates
WebJobs content
Hybrid connections
Virtual network integration
Service endpoints
Azure Content Delivery Network
From the description of the documentation it seems to be able to change the framework version.
This is the doc:
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-two-slots
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.
i run a azrue webrole (hosts 2 websites + 1 webservice) which was originally uploaded in that mentioned "package".
After the initial upload I published some hotfixes of one of the websites via Web Deploy.
If my azrue role restarts (of whatever reason) the updated sites falls back to the version the role was originally uploaded with.
Is that intended? Is there some way to prevent this? I can't find any information on that topic :(
Thanks for your help!
If my azure role restarts (of whatever reason) the updated sites falls
back to the version the role was originally uploaded with.
Is that intended?
Yes. Any changes done to the website after the package is published will be rolled back in case Azure decides to tear down the role and put it in another VM. This is because Azure Cloud Services (Web/Worker role) are stateless. However this should not happen when a role restarts (or in other words reboots).
Is there some way to prevent this?
Unfortunately no. If you want to make your changes persistent, you will have to update the deployment by uploading a new package.
I have a web role in azure that is using syncfusion docToPdf to convert word documents to pdf.
If I publish this role using a full deployment, converting a doc is fast, <500ms.
But after a update deployment, it's unusable slow, >5s every time.
If I reimage the instance it will be fast again, until I do a new deployment update.
If I reboot the slow instance it has no effect.
For all other functionality in the role there is no performance difference between full deployment and upgrade deployment.
I do not understand why this is happening or where to start to fix it...
It turns out that this happened because of Application Insights, for some reasons it made word to pdf 10 times slower.
When we modified applicationinsights.config and replaced [All Namespaces] with only our own namespaces syncfusion started running smoothly again
Windows Azure cloud service take some amount of time to initiate the service while accessing it first time, immediately after update deployment. This is due to the cloud service stops from the server when the service is idle for a certain amount of time, while updating the cloud service. Whereas the service remains running immediately after full deployment, hence it doesn’t require to restart service. Please refer the below blog for further details
http://wp.sjkp.dk/windows-azure-websites-and-cloud-services-slow-on-first-request
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