2008-09-29 69 views
119

部署我们的网站的新版本我们执行以下操作:如何部署ASP.NET应用程序以零停机时间

  1. 拉上新的代码,并将其上传到服务器。
  2. 在活动服务器上,从IIS网站目录中删除所有活动代码。
  3. 提取新代码zip文件到现在空IIS目录

这个过程是所有脚本,并很快发生,但仍然可以是10-20秒停机时的旧文件被删除,并部署新文件。

0秒停机时间方法的任何建议?

+0

不应该在ServerFault上吗? – 2009-11-19 02:42:57

+46

也许,但ServerFault在2008年9月不存在 – 2010-05-13 09:29:04

+3

IIS可以指向一个符号链接文件夹吗?更改符号链接是否会导致IIS进程重新启动? – 2012-05-07 00:36:02

回答

71

您需要2台服务器和一台负载均衡器。下面是步骤:

  1. 打开服务器上的所有流量2
  2. 部署服务器上1
  3. 测试服务器1
  4. 打开服务器上的所有流量1
  5. 部署服务器2
  6. 测试服务器上2
  7. 打开两台服务器上的流量

事情是,即使在这种情况下,如果您使用“粘性会话”,仍然会重新启动应用程序并丢失会话。如果你有数据库会话或状态服务器,那么一切都应该没问题。

+5

两台虚拟机也可以工作。 :) – Till 2008-09-29 10:16:55

+3

您还可以配置负载平衡器,以便它为给定服务器的现有会话提供服务,但不接受新会话。这样可以避免丢弃会话。然而,这种技术需要等待会话结束,并且一般而言,您需要编写脚本。 – 2009-10-07 04:13:46

5

我能想到的唯一的零宕机方法涉及至少2台服务器上的托管。

59

Microsoft Web Deployment Tool支持这种在一定程度上:

使Windows事务文件 系统(TxF的)支持。当启用TxF支持 时,文件操作是 原子;也就是说,他们要么成功 要么完全失败。这确保数据完整性并防止数据或文件 存在于“中途”或 损坏状态中。在MS Deploy中,默认情况下禁用TxF为 。

看来交易是针对整个同步的。此外,TxF是Windows Server 2008的一项功能,因此此事务功能不适用于早期版本。

我相信这是可以修改你的脚本使用文件夹,版本和IIS元数据库0停机:

  • 在现有的路径/网址:
    • 路径:\网络\应用程序\ V2。0 \
    • 网址:下
      • \网络\程序\ 2.1 \
    • 修改IIS元数据库http://app
  • 复制新的(或修改)的网站服务器更改网站路径
    • from \网络\程序\ 2.0 \
    • \网络\程序\ 2.1 \

这种方法具有以下优点:

  • 倘若新版本有一个问题,你可以很容易地回滚到V2.0
  • 要部署到多个物理或虚拟服务器,你可以使用你的脚本文件部署。一旦所有服务器都有新版本,您就可以使用Microsoft Web部署工具同时更改所有服务器的元数据库。
-7

我建议保留旧的文件那里,只是覆盖它们。这样停机时间仅限于单个文件覆盖时间,并且一次只有一个文件丢失。

不知道这有助于在“Web应用程序”,但(我认为你说这是你使用的是什么),这就是为什么我们总是用“网站”。另外,对于“网站”部署,不会重新启动您的站点并删除所有用户会话。

1

我会改进乔治的回答一下,如下,一台服务器:

  1. 使用Web部署项目到现场预编译成一个DLL
  2. 拉上新的网站,并把它上传到服务器
  3. 其解压缩到位于与该站点的正确权限的文件夹中的一个新的文件夹,所以解压缩文件继承正确的权限(也许是E:\网络,包括子文件夹v20090901,v20090916等)
  4. 使用IIS管理器来更改文件夹续的名称癌宁现场
  5. 保留旧的文件夹有一段时间了,所以你可以回退到它的问题

步骤4的情况下将导致IIS工作进程循环。

这是,如果你不使用的是InProc会话只有零停机时间;如果可以的话,使用SQL模式(甚至更好,完全避免会话状态)。

。当然,这是有点棘手,当有多个服务器和/或数据库的变化....

7

我通过这个去最近,我想出了一个解决办法是有两个网站在成立IIS并在它们之间切换。

对于我的配置,我对每个A和B这样的网站的web目录: C:\局域网\活一个\接口 C:\局域网\活乙\接口

在IIS中,我有两个相同的站点(相同的端口,认证等),每个站点都有自己的应用程序池。其中一个站点正在运行(A),另一个站点停止(B)。活的主机还有活动的主机头。

当谈到部署生活时,我只是发布到STOPPED网站的位置。因为我可以使用其端口访问B站点,所以我可以预热站点,以便第一个用户不会导致应用程序启动。然后使用批处理文件复制我实况主持人头B,停止A和B.开始

6

使用Microsoft.Web.Administration的ServerManager的类,你可以开发自己的部署代理。

诀窍是更改VirtualDirectory的PhysicalPath,这会导致旧的和新的Web应用程序之间的在线原子切换。

请注意,这可能会导致旧的和新的AppDomain并行执行!

的问题是如何改变数据库等

通过轮询旧的或新的PhysicalPaths的AppDomain的存在,它可以检测的时候,老的AppDomain(S)已经终止同步,如果新AppDomain(s)已启动。

要强制一个AppDomain开始你必须做出一个HTTP请求(IIS 7.5支持自动启动功能)

现在,你需要一种方法来阻止新的AppDomain请求。 我使用一个已命名的互斥体 - 它由部署代理创建并拥有,由新Web应用程序的Application_Start等待,然后在部署代理完成数据库更新后发布。

(我在web应用程序中使用标记文件来启用互斥等待行为) 一旦新的web应用程序正在运行,我将删除标记文件。

6

行,所以既然大家都downvoting我写的,早在2008年*答案...

我会告诉你我们是怎么做的,现在在2014年,我们不再使用的网站,因为我们使用的ASP。 NET MVC现在。

当然,我们并不需要一个负载平衡器和两个服务器来做到这一点,那很好,如果你对你保持每个网站3台服务器,但它是为大多数网站总矫枉过正。

此外,我们不依赖于微软的最新向导 - 太慢了,太多隐藏的魔法,太容易改变它的名字。

下面是我们如何做到这一点:

  1. 我们有复印件生成的DLL为“滨酒馆”文件夹后生成步骤。

  2. 我们除了使用比较(这是极好的**),以验证和同步更改的文件(通过FTP,因为,获得广泛支持)到生产服务器

  3. 我们有一个包含网站上的安全网址一个按钮,复制一切都在“滨酒馆”到“本”(以先备份来实现快速回滚)。此时,应用程序会自行重新启动。然后我们的ORM检查是否有任何表或列需要添加并创建它们。

这仅仅是几毫秒的停机时间。应用程序重新启动可能需要一两秒钟的时间,但在重新启动期间,请求会被缓冲,因此停机时间实际上为零。

整个部署过程需要5秒到30分钟,这取决于有多少文件被更改多少变化审查。

这种方式,你不必将整个网站复制到不同的目录,但只是bin文件夹中。您也可以完全控制流程,并确切知道正在发生的变化。

**我们一直做的,我们正在部署的变化快速眼球 - 作为最后一分钟的仔细检查,所以我们不知道怎么测试,如果有什么休息,我们准备好了。我们使用Beyond Compare,因为它可以让你通过FTP轻松区分文件。如果没有BC,我绝不会这样做,你不知道你在覆盖什么。我不再推荐Web站点,因为它们构建起来比较慢,而且可以用半编译的临时文件造成严重的崩溃,我们之前使用它们是因为它们允许更多的敏捷文件非常快地修复一个小问题,你可以看到你正在部署的东西(如果使用Beyond Compare当然 - 否则忘记它)。

1

要扩大sklivvz的答案,它依靠有一些负载平衡器类型(或仅在同一服务器上备用副本)

  1. 将所有流量传送到站点/服务器2
  2. 可选稍等一下,以保证尽可能少的用户尽可能对部署的版本未决工作流程
  3. 部署到网站/服务器1,预热时间尽可能
  4. 执行数据库迁移事务(力争使这个可能)
  5. 立即将所有流量网站/服务器1
  6. 部署到网站/服务器2
  7. 直接流量到两个站点/服务器

这是可能引进一点烟雾测试,通过创建一个数据库快照/复制,但是这并不总是可行的。

如果可能并需要使用“路由差异”(例如不同的租户URL:s(customerX.myapp.net)或不同用户)首先部署到未知的豚鼠组。如果没有失败,发布给大家。

由于数据库迁移都参与其中,回滚到以前的版本往往是不可能的。

有些方法可以使应用程序在这些场景中发挥更好的效果,例如使用事件队列和回放机制,但由于我们正在讨论如何部署对正在使用的某些内容所做的更改,因此实际上没有任何可以避免的方法。

1

这是我如何做到这一点:

绝对最低系统要求:
1服务器与

  • 1负载平衡器/反向代理(例如nginx的)端口80
  • 2 ASP运行NET/mono fastcgi-chroot jails在2个不同的TCP端口上

工作流程:

开始交易myupdate

try 
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond 

    wait (custom short interval) 

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse) 
    Updatedb - secondary read-only mode (switches database to read-only) 

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database 
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service) 
    ssh into every machine in array_of_new_webapps 
    run apt-get update 
    then either 
    apt-get dist-upgrade 
    OR 
    apt-get install <packagename> 
    OR 
    apt-get install --only-upgrade <packagename> 
    depending on what you need 
    -- This deploys the new application to all new chroots (or servers/VMs) 

    Test: Test new application under test.domain.xxx 
    -- everything that fails should throw an exception here 
    commit myupdate; 

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number) 
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x: Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc. 

catch 
     rollback myupdate 
     switch to read-write mode 
     Web-Service: Tell all applications to send web-socket request to unblock read-only mode 
end try 
8

您可以通过使用应用程序请求路由在IIS上的不同端口的两个本地IIS站点之间的软件负载均衡器实现在一台服务器上零停机时间部署。这被称为蓝绿色部署策略其中在任何给定时间,只有一个站点在负载均衡器中可用。部署到“关闭”的站点,对其进行热身并将其带入负载平衡器(通常通过传递应用程序请求路由运行状况检查),然后将原始站点从“池”移出(再次通过使其健康检查失败)。

A full tutorial can be found here.