我有一个关于部署槽的问题，因为我想弄清楚我想使用部署槽的方式是否可以接受。在我们的团队中，我们的大多数 Web 应用程序往往有 3 个环境：
目前我们只获得了一个应用服务资源。由于我们想维护为上述 3 个环境部署的应用程序代码的 3 个版本，我想知道是否可以利用 3 个单独的部署槽，或者创建 3 个单独的 Web 应用程序是要走的路吗？
从文档中我知道部署槽用于快速测试，然后将其换出到生产环境，但由于我们目前仅限于 Web 应用程序的单个实例，我正在考虑利用部署槽。
我想知道您对此的看法，以及我是否应该为此类场景使用新的应用服务或插槽。
【问题讨论】：
标签： azure azure-web-app-service
只是将它们分开是更灵活且可能更安全的方法。如前所述，没有成本差异；但是，我想指出，如果 Web 应用程序真的是 3 个不同的环境，那么它们应该是 3 个不同的应用程序服务。这将使您能够在每个环境后面都有一个数据库，一个 Identity 分配给每个环境，Application registration 以及每个环境可能不同的 access restrictions 规则。
事实上，将它们分开可能会节省成本，因为 DEV 中的应用服务可能比 PROD 中的应用服务规模更小。或者 DEV 可以在不使用时直接删除，并在工作时通过 ARM 重新部署。
来自Microsoft Best Practices on app service slots，它使用一个槽调用：
- 您可以先在暂存部署槽中验证应用更改，然后再将其与生产槽交换。
- 首先将应用程序部署到插槽并将其交换到生产环境中，以确保插槽的所有实例在之前都已预热 被换成生产。这消除了停机时间，当您 部署您的应用程序。流量重定向是无缝的，没有 由于交换操作，请求被丢弃。你可以自动化 通过在预交换时配置自动交换来完成整个工作流程 不需要验证。
- 交换后，具有先前暂存应用程序的槽现在具有先前的生产应用程序。如果更改交换到生产中 插槽不是您所期望的，您可以执行相同的交换 立即恢复您的“最后一个已知的良好网站”。
为了进一步说明，部署槽应用于Blue-green deployment or canary releases 此链接用于 DevOps 部署，但同样的概念适用于应用服务槽。
当然，缺点可能是更多的开销和管理。如果是单独的应用服务，那么可能会单独的 DNS 记录、网络规则、SSL 证书等。
【讨论】：
从技术上讲，我相信可以按照您的建议进行操作，因为每个部署槽都承载您应用程序的全功能版本，并且您可以使用 this routing method 访问特定槽。您只需将每个环境部署到其自己的插槽，并且永远不会交换它们。
但是，没有理由这样做。您可以免费创建其他 Web 应用程序。您只需为 App Service 计划付费，并且您可以在该计划上运行任意数量的 Web 应用程序，因此您最好为每个环境创建单独的 App Service，因为它们都是非生产，您可以在同一个应用服务计划中安全地运行它们。
【讨论】：