1

Sometimes in our website which is deployed on Azure web roles, issue comes related to small bugs in javascript and HTML. We go to all instances of webroles and fix these JS and HTML file on machines.

But I was looking into some automated way of doing this, downloading the files to patch from some central location and replace the files in all azure web roles. I am using ASP .net MVC for website.

It is possible to redeploy the website with the patch in the package but we don't want to wait for long deployment time. Please let me know if it is possible via some internal WEB API which replaces the content on all azure web roles.

David Makogon
  • 69,407
  • 21
  • 141
  • 189
Gyan Prakash
  • 61
  • 10
  • 2
    Have you considered using Web Apps instead of Cloud Services Web Roles? Deployment is easier and quicker (you can deploy directly from a public repository o use Web deploy to upload just the files that changed). – gbellmann Jul 18 '16 at 23:48
  • Thanks for the pointer to Web APP. I will try to see if we can fit in there. Though we have few worker roles also with our Webservice right now. Will it be possible to deploy worker roles too in WEB App? One more thing is it is going to take a lot of time to migrate to WEB APPs so is it possible doing this patching in azure webroles? – Gyan Prakash Jul 19 '16 at 00:22
  • Patching can't be done in cloud services the way you want. Regarding the migration, you have 2 options: 1) you can migrate your web roles to Web Apps and keep your worker roles in your cloud service. 2) you can also migrate your worker role to a web job (within the same web app or another web app, depends on whether you want/need them to scale independently or not). – gbellmann Jul 19 '16 at 01:12
  • So you are not using an automated deployment process to deploy changes to the web roles? – Brendan Green Jul 19 '16 at 01:19
  • We are using an automated process but that takes a lot of time to update the website and change is only a small javascript/HTML file. – Gyan Prakash Jul 19 '16 at 17:51

3 Answers3

1

There are 2 ways to deploy a new webrole:

  • redeploy
  • inplace update

The first one is the slowest, meaning new VM's are booted.

With inplace upgrade (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-update-azure-service/) The new application package is mounted on a new drive (usually F: instead of E:) and the IIS website is swapped to the new drive.

You can try this by going to the old portal and upload a new application package. In just a few seconds/minutes the update is done.

Erik Oppedijk
  • 3,496
  • 4
  • 31
  • 42
  • Could you please explain more where to upload application package? I tried uploading the cspkg and it takes long time like more than 30 minutes everytime. I am going to my service and hitting "update" button in old portal and uploading package and config. – Gyan Prakash Jul 19 '16 at 17:24
  • What is included in your cloud service? share some parts of the config. Do you use startup tasks to install components? Did you try this as well with an (almost) empty website? It used to be quite fast – Erik Oppedijk Jul 20 '16 at 19:26
  • I can not share config because it is a internal product. Though we use startup task to install many things and we use caching also for worker roles which takes a lot of time to update the deployment. – Gyan Prakash Jul 20 '16 at 22:12
0

After digging many things on stackoverflow, I crafted my own solution which is creating a topic and subscribing to the topic in code when website starts. When I want to patch the web app then I send a message to Topic to start patching then each machine in the web roles will get notification from topic and start patching themselves. Patching itself is very easy, which is going to a web storage and downloading files from there and replacing files in approot. When azure maintenance happens this patching may go away, so for this situation I made patching work started at start up of website too.

Gyan Prakash
  • 61
  • 10
-2

Cloud service deployment packages tend to be slow since they are basically a recipe on how to build and configure your deployment. The deployment not only puts the recipe out in Azure (so it can be used again if it needs to move your machine), but also follows the recipe to build out a VM for your Cloud Service (WebRoles/WorkerRoles are platform as a service so you don't have to worry about the OS and infrastructure level like you would if you were using the Virtual Machine Azure product but they do still run in VMs on physical hardware).

What you are looking to do is something that will update the recipe (your cloud service package) and your deployment after it is out and running already ... there is no simple way to do that in Cloud Services.

However, yes you could create a startup script that could pull the site files from blob storage or some other centralized location - this would compare to how applications (fiddler for example) look for updates then know how to update and replace themselves. For that sort of feature you will likely need to run code as an elevated user - one nice thing about startup scripts are they can run as an elevated user - so they can do about anything you need done on a machine (but will require you to restart the instance for them to run). Basically you would need to write some code that will allow your site to update itself. This link may help: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-startup-tasks/

If you have the ability to migrate to WebApps and WebJobs, I would recommend looking into that since that compute product solves your problem really well. Here is a useful answer of the differences between WebApps and Cloud Services: What is the difference between an Azure Web Site and an Azure Web Role

Community
  • 1
  • 1
Jason Haley
  • 3,770
  • 18
  • 22
  • 2
    Telling someone to move from one service to another is *not* an answer (and there are actual reasons why moving to a web app is sometimes impossible). Also, cloud service deployments are *not* vm creation packages. They only contain a deployment that gets rolled out and configured on a pre-built baseline VM image. – David Makogon Jul 19 '16 at 05:25