The recently refreshed Azure SDK v1.4.1 now supports the in-place upgrade of a single running Web Role instance using Web Deploy. This post details how to use this new feature.
The SDK refresh is available for download here: Get Started
As announced by the Windows Azure team blog,
Until today, the iterative development process for hosted services has required you to re-package the application and upload it to Windows Azure using either the Management portal or the Service Management API. The Windows Azure SDK 1.4 refresh solves this problem by integrating with the Web Deployment Tool (Web Deploy).
A common complaint regarding Azure has been that roles take too long to start up, and since every update to your software requires a start up cycle (provision, initialize, startup, run) the development process is slowed significantly. The Web Deploy tool can be used instead to upgrade an in-place role – meaning the core of an application can be refreshed in an iterative development cycle without having to repackage the whole cloud project. This means a missing CSS link, validation element, code behind element or other change can be made without having to terminate your Role Instance.
Note that Web Deploy is limited to a single Role Instance – if you have a complex website with multiple roles (which is more than likely in Production but maybe less likely in Staging if you are in a development cycle and working on the last stage before you deploy to Production) you cannot use Web Deploy. I suggest in this case that you should consider either a separate development instances where you can prove your technology before beginning to scale it, or you can always reduce the number of instances to 1, before then increasing the scale again to your chosen number. For other limitations, see here.
It is a useful streamlining of the Windows Azure deployment path as it bypasses the lengthy process of Startup. This must be considered when choosing whether to do a full deployment or a partial Web Deploy, for things such as Startup Tasks do not run when performing a Web Deploy. Any install task (for instance) has already been undertaken when the Role was initially created, and so does not execute again.
In this blog, I use the code from my previous blog, Restricting Access to Azure by IP Address. I use this blog as it includes a startup task that adds a significant length of time from the initial publish to the Role becoming available and responsive to browser requests. This delay is greater than the standard delay in starting an Azure Role as it installs a module into IIS. It is also these types of delay that the Web Deploy integration ask as a remedy for, as the start tasks do not need to be repeated on a Web Deploy.
Firstly, one has to deploy the Cloud Project to Azure in the standard way. This is achieved by right clicking on the Cloud Project and selecting “Publish”.
Standard Publish
On this screen, those familiar with SDK v1.4 and earlier will notice a new checkbox; initially greyed out, this allows the enabling of Web Deploy to your Azure role. We need to enable this, and the way to do so is (as hinted by the screen label) to firstly enable Remote Desktop access to the Azure role. Click the “Configure Remote Desktop Connections” link, check the Enable Connections for all Roles and fill out all the details required on this screen. Make sure you remember the Password you enter, as you’ll need this later.
Set up Remote Desktop to the Azure Roles
Once we have done this, the Enable Web Deploy checkbox is available for our use.
Check the Enable Web Deploy checkbox
The warning triangle shown warns:
“Web Deploy uses an untrusted, self-signed certificate by default, which is not recommended for upload sensitive data. See help for more information about how to secure Web Deploy”.
For now I recommend you don’t upload sensitive data at all using the Web Deploy tool, and if in doubt, this should not be the preferred route for you to use.
Once you have enabled the Web Deploy for roles, click OK, and the deploy beings. This is the standard, full deploy that takes a while to provision an Instance and instantiate it.
From my logs, this takes 21 minutes. The reason for this particularly long delay is that I have an new module being installed into IIS which adds around 8 to 9 minutes at least to complete. Typically the deploy would take 10-15 minutes.
12:33:52 - Preparing... 12:33:52 - Connecting... 12:33:54 - Uploading... 12:35:08 - Creating... 12:36:04 - Starting... 12:36:46 - Initializing... 12:36:46 - Instance 0 of role IPRestricted is initializing 12:41:27 - Instance 0 of role IPRestricted is busy 12:54:12 - Instance 0 of role IPRestricted is ready 12:54:12 - Creating publish profiles in local web projects... 12:54:12 - Complete.
This 21 minute delay is what Web Deploy is seeking to reduce. I will now access my role.
You are an ip address!
We will now make a trivial change to the MasterPage of the solution, changing “You are: an ip address” to “Your IP is: an ip address”. This change requires a recompilation of the ASPX Web Application, and so could be cosmetic like this change, or programmatic or referential. Some changes are not possible with Web Deploy – such as adding new Roles, changing startup tasks and changing ServiceDefinitions.
In order to update our code, right click on the Web Role APPLICATION Project in Visual Studio. This is different to the previous Publish, which was accessed by right clicking on the Cloud Project. Select “Publish”.
Web Deployment options
All of these options are completed for you, although you have to enter the Password that you entered when you set up the Remote Desktop connection to your Roles.
Clicking Publish builds and publishes your application to Azure. This happens for me in under 5 seconds.
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========
That is that. It’s amazingly quick and I wasn’t even sure it was working initially 🙂
Going to the same Service URL gives the following:
An updated web app!
As you can see, the web application has been updated. We have gone from a deployment cycle of 21 minutes, to an iterative deployment cycle of 5 seconds. AMAZING.
One last thing to note, straight from the Windows Azure Team Blog regarding constraints on using Web Deploy:
Please note the following when using Web Deploy for interactive development of Windows Azure hosted services:
- Web Deploy only works with a single role instance.
- The tool is intended only for iterative development and testing scenarios
- Web Deploy bypasses the package creation. Changes to the web pages are not durable. To preserve changes, you must package and deploy the service.
Happy clouding,
Andy
Andy Cross
azurecoder
Beth Martin
elastacloud = azurecoder + bareweb 
Good write up! I wish the tips from the Windows Azure Team blog were at the top. I was pretty excited about web deploy until I read “Web Deploy only works with a single role instance.”
That sure makes it a lot less useful. Very disappointing.
It”s not a tool to be used with a fully scaled Production Role to be sure – but you can update a Staging slot deployment with it without too much hassle. If you have n(>1) instances in Staging, simply edit your configuration to reduce the count down to 1 (or use a powershell script or scaling service), use Web Deploy and then rescale. Realistically, Staging doesn”t need the scaling power of Production in most cases.
Either way, I took your advice and put a note towards the top, to make this limitation clearer.
Cheers
Andy
Good write up! I wish the tips from the Windows Azure Team blog were at the top. I was pretty excited about web deploy until I read “Web Deploy only works with a single role instance.”
That sure makes it a lot less useful. Very disappointing.
It”s not a tool to be used with a fully scaled Production Role to be sure – but you can update a Staging slot deployment with it without too much hassle. If you have n(>1) instances in Staging, simply edit your configuration to reduce the count down to 1 (or use a powershell script or scaling service), use Web Deploy and then rescale. Realistically, Staging doesn”t need the scaling power of Production in most cases.
Either way, I took your advice and put a note towards the top, to make this limitation clearer.
Cheers
Andy
— It’s not a tool to be used with a fully scaled Production Role to be sure – but you can update a Staging slot deployment with it without too much hassle. .. Realistically, Staging doesn’t need the scaling power of Production in most cases.
Andy, it is probably worth rejigging your distinction between production and staging. The Microsft Patterns & Practices book “Moving Applications to the Cloud” suggests you test in a separate testing “production” hosted service NOT the staging slot for your production hosted service. The staging slot is really intended, in this model, to be used only with a VIP swap in which the FAbric Controller promotes the staging slot deployment by having the load balancer redirects traffic to it rather than the erstwhile production slot deployment.
Anyway, good post. (Or is it anyways? I”m always getting my British and American usages mixed up these days.)
Thanks Neil, and I”m glad you liked the rest of the post; I agree that having a separate hosted service for a development iterative cycle is the way to go, with Staging only being used for the VIP swap. My notion of Staging and Production being used for “different things” even I wouldn”t recommend in the long run! That book you mention is a great resource, http://msdn.microsoft.com/en-us/library/ff728592.aspx.
Thinking on it a little more; a Web Deploy to Production via Staging (which was vaguely what I was shooting for) would require a scale down to 1 on staging, Web Deploy, scaled up to n instances, VIP Swap. This is in contrast to what I said about “without too much hassle”.
Anyway, I tend to use anyway rather than anyways 😉
— It’s not a tool to be used with a fully scaled Production Role to be sure – but you can update a Staging slot deployment with it without too much hassle. .. Realistically, Staging doesn’t need the scaling power of Production in most cases.
Andy, it is probably worth rejigging your distinction between production and staging. The Microsft Patterns & Practices book “Moving Applications to the Cloud” suggests you test in a separate testing “production” hosted service NOT the staging slot for your production hosted service. The staging slot is really intended, in this model, to be used only with a VIP swap in which the FAbric Controller promotes the staging slot deployment by having the load balancer redirects traffic to it rather than the erstwhile production slot deployment.
Anyway, good post. (Or is it anyways? I”m always getting my British and American usages mixed up these days.)
Thanks Neil, and I”m glad you liked the rest of the post; I agree that having a separate hosted service for a development iterative cycle is the way to go, with Staging only being used for the VIP swap. My notion of Staging and Production being used for “different things” even I wouldn”t recommend in the long run! That book you mention is a great resource, http://msdn.microsoft.com/en-us/library/ff728592.aspx.
Thinking on it a little more; a Web Deploy to Production via Staging (which was vaguely what I was shooting for) would require a scale down to 1 on staging, Web Deploy, scaled up to n instances, VIP Swap. This is in contrast to what I said about “without too much hassle”.
Anyway, I tend to use anyway rather than anyways 😉
This would have been great if it worked for production. Until it does, Azure is not practical to use for me.
Hi Ralph,
Here are my thoughts:
It would work in production for a single instance role. This single instance role isn”t recommended as you need to have at least 2 instances to be covered by the 100% uptime SLA.
If you were to use this directly into a production slot, it would cause the recycling of the AppDomain that your WebRole was running on, since WebDeploy always redeploys the BIN folder. This means you would have dropped requests while the domain was restarting, which is something to avoid if possible.
Instead, you can use a WebDeploy on a testing, or pre-production environments with a single role instance (since a perpetual uptime isn”t so important for internal testing). This lets you provision your services once, and then quickly upgrade with bugfixes and/or new features as part of your dev cycle.
When you come to deploy to production, you will first deploy to Staging of your “production subscription” as a whole package, guaranteeing that Startup Tasks are executed and that the scaling is correctly configured. You would then perform a VIP swap.
Alternatively, if you don”t want the ability to test without affecting production, or you rely on some kind of localised instance state (not a great idea in of itself!), you can use an In-Place upgrade of your Production slot which doesn”t have to provision the instances again, but instead reuses the instances. Detailed here, http://msdn.microsoft.com/en-us/library/ee517255.aspx, this uses the concept of “Upgrade Domains” to reliably upgrade your software whilst providing continuous service to your consumers.
Best regards,
Andy
Andy,
Thanks for the thorough response. Because of the reasons you mentioned (single role and other limitations), web deploy currently cannot (or at least should not) be used directly on a production environment. This is a big limitation for me. Any minor modification I need to make on the production app would still take me 10 minutes to make.
I currently run a Windows instance on EC2. With web deploy, I can make a change on the production environment from within Visual Studio in seconds. On Google App Engine too, I can make a change on a production app from Eclipse in seconds.
I am sure Microsoft has good technical reasons for why this is not possible. It may take a major change in the implementation to make this possible. I think it is necessary. This is a very competitive space. This lack of feature turns many developers away from Azure. Maybe not all developers care about this, but a big percentage do.