我应该在更新期间停止 Azure 应用服务吗？

Question

我正在从 Azure DevOps 更新我的 Azure 应用服务。目前，我的发布是这样的：

1. 停止应用服务，
2. 更新应用服务，并
3. 启动应用服务。

我的问题是在更新期间停止应用服务是否合理？当我从 Azure DevOps for Azure App Service 选择发布模板时，没有任何停止/启动步骤，只有更新步骤。所以我想知道是否需要停止/启动？

Answer 1

我们做的最多的是：

1. 停止暂存槽
2. 部署到插槽
3. 开始槽
4. 将暂存转换为生产
5. 停止暂存槽

Martin 关于 Take app offline 的建议也不错！

我们更喜欢部署到插槽然后交换，因此我们对生产的影响最小并且还可以轻松回滚。 停止/使应用脱机可以防止文件锁定问题。

Answer 2

这可能取决于您的应用。如果您在更新应用时没有任何问题（例如文件正在使用问题），您可以考虑使用 Take App Offline 标志，该标志将放置一个 app_offline.htm 文件在更新期间在应用服务的根目录中（然后它将被删除）。通过这种方式，用户将认识到应用程序正在发生某些事情。

然而，我经常会像你一样做：停止、更新、开始?

Answer 3

有 (5) 个选项可安全部署（原子更新）到 Azure Web 应用程序。这是我按优先级和功能丰富度排列的首选顺序：

1. Run-from-Package + ZipDeploy（将网站设为只读）
2. ZipDeploy（使用 kudu REST api - automatically takes site offline）
3. Azure CLI (az webapp)
4. msdeploy（-enableRule:AppOffline，或stop/start site to enforce atomicity）
5. FTP（使用发布配置文件，请务必上传 appoffline.htm）

还有许多其他部署选项，例如 cloud sync、github continuous、本地 git 等 - 但它们都基于 Kudu API (as is Azure CLI)。

注意：如果您使用的是 Azure DevOps - 它支持几乎所有这些选项 - leverage the Azure App Service Deploy task

Answer 4

同意 Martin 和 juunas 的观点。如果您想在不影响用户的情况下进行部署，那么您需要使用插槽交换方法。 juunas 也提出了轻松回滚的要点。我们的方法包括另一个我们称之为“修补程序”的插槽。这增加了一些好处：

1. 拥有一个带有生产配置的环境，这样您就可以在实际进行交换之前选择性地进行额外的测试。

2. 即使开发人员已经部署到暂存环境中，也可以在 prod 中回滚。

3. 允许您测试当前和以前版本代码中的错误。当有人说“在此部署之前它工作得很好”时很有帮助......

这就是它的样子。