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.
Related
I am having an issue with my Azure Update Management not pushing the updates to the Windows VM.
This was working before I domain joined to Azure Active Directory Domain Services.
From what I have read on the Microsoft Site, it looks like this is a known issue, wanted to shoot it off here to see if anyone has found a work around. It looks like that it is not selecting the updates. I do have the selection in the schedule setup to do all updates.
Things I have tried.
Recreated the Services Account.
Deleted and redid the automation account
Delete and setup the Updates Management Configuration
Verified they do work manually.
I am relatively new to Azure, so I apologies for the lack of knowledge.
I have since found the answer. The Worker process from Azure has to be reinstalled if it was installed prior to the domain join.
Per article below web app has an option to either auto or manual scale:
https://azure.microsoft.com/en-us/documentation/articles/insights-how-to-scale/
Would appreciate if I can get clarification on below:
Scenario:
I've ASP.NET Sitecore CMS which uses Lucene behind the scene for search. Lucene index gets rebuilt upon publish of new pages.
Lets say I manually or auto scale to 2 instances:
What exactly happens behind the scene i.e. copies all the website folder to new VM and sets up IIS etc?
Web App has functionality to FTP and view website folders. Is it possible to FTP to both of these instances? From what I know I can only FTP to one of them.
Update:
Problem we are facing:
We use lucene index for our web applications. Looks like the index is built on one web app and not other (website works for some user and not for others). We would like to FTP or RDP and see to make sure this is the case.
Thanks.
The FTP or the GIT provided by the Azure is not on the same instance when you use WebApps, So if you do FTP its not to one of the instances - its somewhere else, but when you change files in the FTP or push to GIT, the triggers kick in and a continuous deployment to the Webapp instance/s is done. You can be very well assured that when you upload new files to your FTP that comes with WebApp the build will be updated on both instances. In fact that's one of the driving forces behind webapps that you don't need to think about a VM.
We used once Lucene on Web Apps with multiple instances. What we did back then was use Azure Blob Storage to keep the index files, no matter the number of instances, all had the same index information.
The only problem was that when new instances would come up (autoscale), they had to load the index on memory and that lead to some cold-starts.
We moved to Azure Search afterwards and never looked back :)
I have an Azure Cloud Service out in production. I recently received the following message from Microsoft about upcoming service for their Cloud Services platform:
All Cloud Services running web and/or worker roles referenced below will experience downtime during this maintenance. Cloud Services with two or more role instances in different upgrade domains will have external connectivity at least 99.95 percent of the time. Please note that the SLA guaranteeing service availability only applies to services that are deployed with more than one instance per role. Azure updates one upgrade domain at a time. For more information about distribution of roles across upgrade domains and the update process, please visit the Update an Azure Service webpage.
The way I take the email, each instance is essentially a VM on a different host, and they'll be rebooting hosts throughout the maintentance period, so if I don't want to be out of service during this time, I need to ensure I have more than one instance. Is this accurate? If so, how do I "add" an instance?
That is correct.
You can increase your instance count by updating the configuration for the role. In Visual Studio, you can do this in the Properties window for the role and increase the Instance count setting. Then, redeploy the service.
A faster way is to download the configuration file (.cscfg) for the role from the Azure portal, update the instance count setting, and then upload the changed configuration file. The setting is in the Instances element shown here.
You can download the configuration file for the role from the Azure portal (portal.azure.com) by going to the Cloud Service blade and clicking on Settings in the toolbar. In the Settings blade click Configuration. In the Configuration blade are where you will find Download and Upload buttons in the toolbar.
The way I take the email, each instance is essentially a VM on a
different host, and they'll be rebooting hosts throughout the
maintentance period, so if I don't want to be out of service during
this time, I need to ensure I have more than one instance. Is this
accurate?
Your understanding is correct.
If so, how do I "add" an instance?
There are many ways to do it.
One would be to edit your role's configuration file (*.cscfg) and changing the Instances element's count property from 1 to 2 and then uploading this file through Azure Portal (Cloud Service --> Configure Tab --> Upload button)
Other one would be to change the instance count through "Scale" tab for Cloud Service in question. On this tab, you will see "Instance Count" setting. Just update it from 1 to 2.
Other options include PowerShell, writing code but I think the ones I mentioned above should be the easiest way to accomplish the task.
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
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.