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

Question

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

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

目前我们只有一个应用服务资源。由于我们希望维护为上述 3 个环境部署的应用程序代码的 3 个版本，我想知道是否可以利用 3 个单独的部署槽，或者创建 3 个单独的 Web 应用程序是正确的方法吗？

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

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

Answer 1

将它们分开是更灵活且可能更安全的方法。如前所述，没有成本差异；但是，我想指出，如果 Web 应用程序确实是 3 种不同的环境，那么它们应该是 3 种不同的应用程序服务。这将使您能够在每个环境后面拥有一个数据库，即 Identity分配给每个环境，Application registration和潜在的不同access restrictions每个环境的规则。

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

来自Microsoft Best Practices on app service slots它调用插槽用于:

• You can validate app changes in a staging deployment slot before swapping it with the production slot.
• Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up beforebeing swapped into production. This eliminates downtime when youdeploy your app. The traffic redirection is seamless, and norequests are dropped because of swap operations. You can automatethis entire workflow by configuring auto swap when pre-swapvalidation isn't needed.
• After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the productionslot aren't as you expect, you can perform the same swapimmediately to get your "last known good site" back.

为了进一步说明，部署槽应用于 Blue-green deployment or canary releases此链接适用于 DevOps 部署，但相同的概念适用于应用服务插槽。

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