使用Azure SDK 1.4.1中的Web Deploy

公告    ：本博客为微软云计算中文博客  的镜像博客。   部分文章因为博客兼容性问题  ，会影响阅读体验  。如遇此情况，请访问  原博客。

 

 

刚刚更新的Azure SDK v1.4.1通过使用Web Deploy，支持单一运行的Web Role实例就地升级。本文详细介绍了如何使用这些新的功能。

SDK更新可以从这里下载：开始

 正如Windows Azure团队博客宣布的，

直到今天，托管服务的反复的部署过程仍需要你使用Management portal或者Service Management API重新打包应用程序并将它上传到Windows Azure。Windows Azure SDK 1.4更新包通过与Web Deployment Tool(Web Deploy)结合，解决了这个问题。

 关于Azure的一个普遍的抱怨就是roles启动花费太长时间，而且之后的每次升级，你的软件都需要一个启动周期（条款，初始化，启动，运行），开发过程明显变慢。Web Deploy Tool可以用来代替升级一个in-place role — 意味着程序的核心可以在反复的开发周期中不必打包全部云项目而更新。这意味着一个缺少的CSS链接，验证元素，隐藏代码元素或者其他改变可以在不终止你的Role Instance的情况下创建。

 值得注意的是Web Deploy仅限于一个单一的Role Instance — 如果你有一个拥有多个角色的复杂的网站（如果你处在开发周期并进行到了部署产品前的最后一个阶段，很有可能在Production中，而不太可能在Staging中）你将无法使用Web Deploy。既然这样，我建议你应该考虑在开始规划之前，使用一个单独的开发实例实现你的技术，或者你可以在总是将实例数目减到1之前，再次增加你所选数量的规模。查看更多限制，请参阅这里。

 这是一种十分有用的Windows Azure流水线化部署方式，因为它略过了长时间的启动过程。这应当在选择使用完全部署，还是部分Web Deploy时考虑，例如Startup Tasks在执行Web Deploy时无法运行。一些安装任务（例如）在Role最开始创建的时候已经被执行了，因此不需要再次执行它。

 这篇博客中，我使用了我之前一篇博客中的代码，Restricting Access to Azure by IP Address。我使用这篇博客是因为它包含了一个在最初发布到Role生效并响应服务器请求时，添加了一个重要的时限的启动任务。这个延迟要优于启动Azure Role的延迟，因为它在IIS中安装了一个模块。这也是那些集成Web Deploy后所希望能解决的耗时类型之一，因为start up task不需要在Web Deploy中被重复调用。

 首先，必须安装标准步骤将Cloud Project部署到Azure。右击Cloud Project，选择“Publish”。 

 标准发布

那些熟悉SDK v1.4和早期版本的人会注意到这个截图上出现了一个新的复选框；最初是灰色的，这允许Web Deploy授权到你的Azure role。我们需要允许这一点，这样做的方式是（按照屏幕标签上的暗示）首先使Remote Desktop访问Azure role。点击“Configure Remote Desktop Connections”链接，选择Enable Connections for all Roles并按照截图上的内容填满所有需要的细节。确保你记住了你输入的密码，因为稍后你将要用到它。 

设置Remote Desktop到Azure Roles

 当我们一做完这些，Enable Web Deploy复选框将可以使用。 

选择Enable Web Deploy复选框

这个三角显示警告： 

“Web Deploy默认使用一个不受信任的，自签名的证书，建议不要上场敏感数据。请参阅帮助查看更多安全的Web Deploy信息。” 

现在我建议你不要使用Web Deploy Tool上传敏感数据。如果有疑问，这不应该作为你使用的首选路径。

一旦你已经为roles激活Web Deploy，点击OK，开始部署。这是标准的完全部署，需要一段时间生成一个Instance，并实例化它。 

造成这么长的延迟的原因是因为我在IIS中安装了一个新的模块，这个过程完成至少需要8到9分钟。典型的部署将会使用10到15分钟。

从我的日志来看，这个过程花费了21分钟。 

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. 

这21分钟的延迟就是Web Deploy力图减少的。我现在将进入到我的role。

你是一个IP地址！

我们现在将要对解决方案的MasterPage做一点点小的改变，将“You are: an ip address”改为“Your IP is: an ip address”。这个变化需要对ASPX Web应用程序重新编译（通过编程或者引用上的变化也可以在这里做为例子示范）。使用Web Deploy不可能做一些改变 — 例如添加新的Roles，改变启动任务和改变ServiceDefinitions。

为了更新我们的代码，在Visual Studio中右击Web Role APPLICATION项目。这与以前通过右击云项目发布不同。选择“Publish”。

Web Deployment选项

这些选项都将替你完成，你只需要输入之前在设置Remote Desktop链接到你的Roles时输入的密码。

点击Publish生成你的程序并发布至Azure。我的这个过程只用了不到5秒钟。

========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

就是那样。令人惊讶的快，我甚至不能确定它已经开始工作了。

 按照下面的访问相同的Service URL

更新的Web应用程序！

 正如你所看到的，web应用程序已经被更新。我们从一个21分钟的部署周期到一个5秒钟的反复的部署周期。这是令人惊讶的。

最后需要注意的一点是，引自 Windows Azure团队博客上关于使用Web Deploy的限制：

当在Windows Azure托管服务的交互式部署时使用Web Deploy请注意以下几点：

• Web Deploy只适用于单一角色实例
• 该工具仅用于反复部署和测试阶段
• Web Deploy跳过打包阶段。网页上的更改不会持久。为了保存更改，你必须对服务进行打包和部署。

 

Happy clouding,

Andy

 

本文翻译自：http://blog.bareweb.eu/2011/04/using-web-deploy-in-azure-sdk-1-4-1/