【问题标题】:How to achieve zero downtime deployment to Azure web app with database updates?如何通过数据库更新实现对 Azure Web 应用程序的零停机部署?
【发布时间】:2017-04-08 00:31:47
【问题描述】:

我正在尝试实现一个 Azure Web 应用的零停机时间部署,其中需要在部署过程中应用数据库架构更新

我有以下设置:

Production 网络应用,带有 production-db 连接字符串。

Staging 部署槽,带有 staging-db 连接字符串。

我的伪部署过程是这样的:

  1. 制作production-db数据库的副本
  2. 配置 Staging 槽以使用 数据库副本
  3. 将代码部署到 Staging
  4. 架构更新应用到数据库副本
  5. Staging 槽(使用更新的数据库)中测试运行应用并预热
  6. 如果一切正常,请执行 热插拔,以便 Staging 插槽中预热的应用程序上线,即成为生产插槽,仍在使用更新的数据库

换句话说,在热插拔之后,我希望新代码和更新的数据库都处于活动状态。

如果此时出现问题,我可以简单地再次交换插槽,使旧的生产应用程序(及其数据库)上线。

据我所知,当我交换插槽时,应用程序将使用生产插槽的连接字符串,重新启动应用程序并强制我应用数据库架构更新更新后的代码直播。

我希望我正确地描述了这一点。 :) 这似乎应该是一个相当普遍的情况?

非常感谢任何帮助或指点!

PS。我查看了 Azure seamless upgrade when database schema changes,但该答案无效,因为我无法在不影响应用程序的情况下应用架构更新。

编辑: 只是一个想法:也许我应该跳过将连接字符串作为门户设置,而是将其保留在 web.config 中。这样,在交换时,应用程序不需要重新启动,并且由于 web.config 将包含在交换中,新的 production 插槽将使用更新的数据库。

编辑 2: 当应用程序设置或连接字符串在插槽之间不同时,我认为应用程序重启是错误的。看来我确实可以为部署槽设置不同的连接字符串(指向数据库副本),然后在不影响网站访问者的应用重启的情况下进行交换。

【问题讨论】:

标签: database azure deployment


【解决方案1】:

你不能让连接字符串粘到插槽上吗?

详细信息here

【讨论】:

  • 并非如此。 :/ 交换时,应用程序将重新启动并指向原始生产数据库,而不是通过部署槽升级的数据库。
猜你喜欢
  • 2011-05-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-05-26
  • 2017-01-01
  • 2017-12-18
  • 2016-03-30
相关资源
最近更新 更多