部署不同版本的应用服务时，何时使用部署槽与单独的应用服务

Question

我有一个关于部署槽的问题，因为我试图弄清楚我想要使用部署槽的方式是否可以接受。在我们的团队中，我们的大多数 Web 应用程序往往有 3 个环境：

• DEV - 最新的开发代码
• QA - QA 正在积极测试的代码
• BC - 最后再次为 QA 提供一个单独的环境来运行向后兼容性测试

目前，我们获得了一个单一的应用服务资源。由于我们想要维护为上述 3 个环境部署的应用程序代码的 3 个版本，我想知道是否可以利用 3 个单独的部署槽，或者创建 3 个单独的 Web 应用程序是否可行？

从文档中我知道部署槽用于快速测试，然后将其交换到生产中，但由于我们目前仅限于 Web 应用程序的单个实例，我正在考虑利用部署槽。

我想知道您对此的想法，以及我是否应该为此类场景使用新的应用程序服务或插槽。

Answer 1

从技术上讲，我相信可以执行您所建议的操作，因为每个部署槽确实托管应用程序的全功能版本，并且您可以使用此路由方法访问特定槽。您只需将每个环境部署到其自己的插槽中，而无需交换它们。

然而，没有理由这样做。您可以免费创建其他 Web 应用程序。您只需为应用程序服务计划付费，并且您可以根据需要在该计划上运行任意数量的 Web 应用程序，因此您最好为每个环境创建单独的应用程序服务，因为它们都是非生产中，您可以在同一个应用程序服务计划中安全地运行它们。

Answer 2

只需添加将它们分开是更灵活且可能更安全的方法。如前所述，没有成本差异；但是，我想指出，如果 Web 应用程序确实是 3 种不同的环境，那么它们应该是 3 种不同的应用程序服务。这将使您能够在每个环境后面拥有一个数据库、分配给每个环境的身份、应用程序注册 以及每个环境可能不同的访问限制规则。

事实上，将它们分开可能会节省成本，因为 DEV 中的应用程序服务可能比 PROD 中的应用程序服务规模更小。或者 DEV 可以在不使用时删除，并在使用时通过ARM重新部署。

从Microsoft 关于应用程序服务插槽的最佳实践中，它指出使用插槽可以：

• 您可以在将临时部署槽与生产槽交换之前验证应用程序更改。
• 首先将应用程序部署到插槽并将其交换到生产环境中，可确保该插槽的所有实例在交换到生产环境之前都已预热。这消除了部署应用程序时的停机时间。流量重定向是无缝的，并且不会因为交换操作而丢弃任何请求。当不需要预交换验证时，您可以通过配置自动交换来自动化整个工作流程。
• 交换后，具有​​先前暂存应用程序的插槽现在具有先前的生产应用程序。如果交换到生产槽的更改不符合您的预期，您可以立即执行相同的交换以恢复“最后一个已知的良好站点”。

为了进一步说明部署槽应用于蓝绿部署或金丝雀版本此链接适用于DevOps 部署，但相同的概念适用于应用程序服务槽。

当然，缺点可能是更多的开销和管理。如果单独的应用程序服务，则可能会单独的 DNS 记录、网络规则、SSL 证书等。