如何使用Web部署发布ASP.NET MVC2站点?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (80)

我目前使用Web Deploy,http: //learn.iis.net/page.aspx/346/web-deploy/发布我的MVC2应用程序。它过去运行良好,但现在它已经到了我无法继续使用它的地步:

当MVC应用程序很小,只有少数用户时,很容易发布。只需右键单击Visual Studio中的项目,然后选择“发布”。而且由于只有少数用户,很容易找到无人使用该站点进行快速更新的时间。

然后,该应用程序变得更大,并有更多的用户。“发布”行动开始时间越来越长,偶尔会超时。即使在部署之前回收应用程序池,仍然需要很长时间。

此外,很难找到一个没有人使用该站点的时间,因此可以在不影响任何人的情况下完成更新。

现在手动部署需要花费更长的时间,从5到20分钟。用户数量显着增长,因此部署总是会影响到某人(响应时间慢,超时,站点不可用等)

那么我能做什么?有没有更好的选择使用Web部署?

今天的部署需要18分钟才能发布49个已更改的文件。这种情况很荒谬,是我们现在最大的弱点之一。所以我开始一个体面的大小的奖金,希望解决这个问题。

还有一些问题可能会导致解决方案:

  • 为什么只有少数文件发生变化需要这么长时间?
  • 为什么Web部署zip始终包含整个代码库,而不仅仅是更改文件?
  • 为什么不自己手动复制已更改的文件并跳过整个Web部署?但是很难手动确定哪些文件已经改变。我使用SVN - 它是否有办法只输出两个分支之间已更改的文件?
  • 我应该问什么其他问题,但还没有想过呢?

这正是我在做这个部署,并且是一个理想的方法。Web部署可以正确识别哪些文件已经更改,但是它会超时并且不会发布。解决方案中大约有2500个文件,可能需要很长时间才能确定哪些文件发生了更改?或者可能是发布具有较短的超时值,并且只需上传15mb zip文件即可使用。

我确实完全控制了服务器,它确实支持Web部署。实际上有两台服务器:主服务器和一台备用服务器,以防万一第一台服务器出现故障。所以任何解决方案都必须易于部署到多台服务器上(网络部署是理想的,直到它停止工作)。

建议为每个版本创建一个新文件夹,然后只需将IIS更改为指向该新文件夹,听起来像在发布期间它会降低停机时间/缓慢时间。但这是一个非常手动的过程,我宁愿更自动化的东西。

我设法缩小了范围,发现它的速度很慢 - 但不是为什么。这是来自部署日志:

[9/02/2011 12:11:56 a.m.] Performing synchronization pass #1.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/1' is applicable to 'iisApp/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'Add write permission to App_Data Folder/1' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data' because of its scope.
[9/02/2011 12:11:56 a.m.] Source createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True']). Update pending.
[9/02/2011 12:11:56 a.m.] Update operation on createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) skipped because of rule CreateApplicationRule.
[9/02/2011 12:11:56 a.m.] Source filePath (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data\Create.sql) does not match destination (Default Web Site/virtual-dir/App_Data\Create.sql) differing in attributes (size['259691','259697'],lastWriteTime['02/08/2011 10:45:20','02/06/2011 03:48:16']). Update pending.

[400 lines of file updates skipped, time expired 2 seconds ....]

[9/02/2011 12:11:58 a.m.] Delete operation on filePath (Default Web Site/v2/zzz_app_offline.htm) skipped because of rule DoNotDeleteRule.
[9/02/2011 12:11:58 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:11:58 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:13:47 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:13:47 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:17:11 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data) does not match destination (Default Web Site/virtual-dir//App_Data) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:17:11 a.m.] Updating setAcl (Default Web Site/virtual-dir//App_Data).
[9/02/2011 12:17:11 a.m.] The dependency check 'DependencyCheckInUse' found no issues.
[9/02/2011 12:17:11 a.m.] The synchronization completed in 1 pass(es).

缓慢的原因是"Updating setAcl"组件。我正在检查开发框和服务器框的ACL以查看有哪些不同。但是,将ACL从开发箱复制到服务器箱似乎是一个非常糟糕的主意!我已经在服务器上设置了ACL。

提问于
用户回答回答于

我首先试图找出发生超时的地方。你已经提到了一个有2,500个文件的15MB zip文件,这不会让我感到特别大。是否尝试过在Visual Studio中创建部署包,然后直接在服务器上运行它?这将使网络延迟超出图片,这是一个非常基本的变量,当涉及到超时。

至于为什么需要上传整个应用程序的zip文件,需要记住已更改内容的实际标识以及随后部署到IIS中的全部内容都发生在服务器上。本地机器上的Visual Studio或msdeploy不是这样的。

至于为什么你不只是手动复制已更改的文件,它在我所引用的博客文章中进行了总结,但简而言之,它很费力且容易出错。这意味着你需要有意识地完成“我的2,500个文件中的哪些文件刚刚改变”的思考过程,而不是简单地说“让我的目标站点与我的开发版本匹配”。你没有提到你是否发布了web.config,但显然配置转换是为什么简单的CTRL-C和CTRL-V方法很麻烦的另一个重要原因。

试图直接从SVN进行更改也是有风险的。你的第一个问题是你必须要更新修订的完整性和准确性充满信心,如果你得到公布相应的更改。然后,将尝试将这些内容同步到目标上,然后回到前一段中提出的相同问题。另一个大问题是版本控制对象代码总是令人讨厌; 您将与项目中的其他人发生永久冲突,并且VCS根本无意以此方式运作。

我的建议是专注于解决问题的根本原因 - Web部署已经超时 - 而不是简单地尝试解决症状。只手动发布变更或者搞乱IIS绑定只会给您长期带来更多麻烦,并且会在短期内做更多工作。了解如何共享创建包的结果,将其复制到服务器,然后在本地执行,然后我们将从此处执行。一旦按照设计工作,应该可以看到部署时间不超过几分钟,并且可以在几秒钟内测量站点中断。

顺便说一句 - 可能还想添加您的PC和服务器之间的延迟时间,以及通过HTTP传输15MB文件通常需要多长时间。

用户回答回答于

我会开始做一些非web部署健康检查。想到一些想法

  • 域或工作组中的Web服务器?
  • 什么dcdiag显示?
  • 什么netdiag显示?
  • 是同一个域中的开发盒和prod盒?

是否有机会尝试应用不再存在的用户或组,禁用或来自Web服务器域以外的域?您的组织可能拥有包含子域或域信任的域层次结构,这些域有效,但通信在生产数据中心中被阻止。

我想我还会手动查看ACL,看看是否有不能解决的条目(它们在解决之前显示为SIDS)。

扫码关注云+社区