azure - Azure 共享应用服务计划中的不同环境

Question

最近我开始尝试并熟悉一些 Azure 产品。我制作了一个简单的应用程序，将其与 azure 函数和 azure 存储以及其他一些产品(例如服务总线)连接起来。

到目前为止一切顺利，该应用程序运行良好，并且我已经接触到了一些出色的 Azure 服务。

但现在我不确定如何最好地继续，因为到目前为止我拥有的是我的应用程序的开发版本。如果我想制作一个产品版本，我是否必须提供一组不同的用于开发版本的所有 Azure 资源？

基本上，我会有 mydevsite.azurewebsites.net 和 myprodsite.azurewebsites.net。它是否正确？我可以使用一些 IP 地址限制来限制 mydevsite.azurewebsites.net，这样就不会公开可用，但我仍然觉得这是一种很奇怪的方法，应该有更好的方法。

对于这样的场景有通用的方法吗？

Answer 1

这是一个有点宽泛的问题，但我可以说出我以前是如何做到的。

常见的设置是三个环境:开发、测试和生产。开发主要在开发人员的机器上运行(尽可能多)。我们使用本地 IIS 安装来运行 Web 应用程序，并使用本地 SQL Server 作为数据库。 Azure 存储和 Cosmos DB 也可以在本地模拟。例如，某些服务(例如搜索)无法在本地运行，因此您无论如何都必须在 Azure 中运行这些服务。

测试和生产基本上是两个相同的资源组，具有相同的资源，只是配置略有不同。因此，将应用服务计划、SQL 数据库等加倍。

当然，根据您想要的方式，您可以跨环境共享资源。但以某种方式确保他们不会意外使用其他环境的东西是个好主意。这样做的明显不好的一面是，您将生产数据与测试数据放在同一位置，坦率地说，它们不应该放在一起。

我知道一些组织完全在 Azure 中运行开发环境。造成这种情况的原因可能有几个:环境非常繁重，无法真正在开发计算机上运行，​​或者他们也想在开发阶段测试 ARM 模板部署。

拥有重复的服务允许您使用 ARM 模板来自动部署和更新基础设施，这非常好。

如果您使用的是标准版或更高版本，您可能会考虑将应用服务中的部署槽用于不同的环境，但它们实际上并不是用于此目的。我们使用它们来减少部署新版本时的应用程序停机时间，并在更新结果不佳时作为后备。因此，部署将转到“暂存”部署槽，该槽与另一个部署槽进行交换，并且新版本已上线。然后，我们停止部署槽，这样我们就不会不必要地在后台运行旧版本。

但除此之外，我们还有一个单独的应用程序服务计划，其中包含单独的 Web 应用程序和自己的暂存槽。

部署槽文档:https://learn.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing