【发布时间】：2016-09-04 19:35:08
【问题描述】：
（请注意，我仅使用新的“刀片”Azure 门户并使用新术语，因此请避免使用“Azure 网站”之类的词，因为它们不适用于此处）。
在门户中，我创建了两个 Azure 应用服务，“foo-production”和“foo-staging”——它们都存在于同一个订阅和资源组中，并且共享同一个应用服务计划。这些应用服务代表一个简单的 ASP.NET Web 应用程序的生产和暂存部署，该应用程序作为普通网站运行。
应用服务计划是“基本：1 小”。
我的理解是，当您使用带有基本或更高应用服务计划的 Azure 应用服务时，该计划代表一个虚拟机，我可以在该虚拟机上托管任意数量的 IIS 网站 - 这些 IIS 网站以Azure 作为 Azure 应用服务。
鉴于此，人们会假设当我访问 Kudu (https://yourwebsite.scm.azurewebsites.net/DebugConsole) 中的 VM 文件系统时，我将能够在某个公共根目录下查看每个网站的文件。
但是，当我访问 foo-production 网站的 Kudu 控制台时，我看到它的文件在 D:\home\site\wwwroot 中，并且找不到 foo-staging 的文件。
如果我理解正确，这意味着 Azure 实际上只为每个网站创建了一个全新的虚拟机，并且网站不能共享文件系统 - 而且我不能拥有更高级的 Azure 托管 IIS 配置 - 我会必须创建我自己的自我管理的 Windows Server VM。
我可以理解为每个网站使用单独的 VM 背后的动机，这似乎很浪费 - Windows Server 至少需要为每个 VM 提供 1 GB 的内存，但我的网站基本上只是静态文件（但我不能使用Shared 应用服务计划，因为我需要一些更高级的功能）。这对微软来说是不经济的。
如何让 Azure 托管环境中的多个 Azure 应用服务共享同一个 VM？还是我想错了？
为了避免 X/Y 问题：我将声明我主要关心的是文件的持久性。我正在部署的 web 应用程序将上传的文件存储到 webroot 的子目录中，这些文件应该永久存在。那里有模棱两可的信息：有些人建议网站（及其所有文件）被积极销毁和回收，应该使用 Azure 存储 Blob。我想使用 Azure 文件共享，不幸的是，我在使用 WNetAddConnection2 时收到了 ACCESS_DENIED 错误，并且一些用户报告说 Azure 文件共享不能在 Azure 应用程序服务中使用 - 尽管我无法从 Microsoft 找到任何关于此的权威信息。
【问题讨论】：
-
我相信虚拟机的数量是基于应用服务计划的。由于它是“1 个小”，这意味着您有 1 个 VM。一定有其他文件存储机制使网站看起来可以看到自己的 D 驱动器版本。
-
@mellamokb 有趣的是，没有
C:驱动器 - 一切，甚至Windows、Program Files和Users目录都在D:下 -
如果您查看“环境”选项卡，可以看到共享 C:\ 驱动器的提示：例如，我看到的是“C:\DWASFiles\Sites\#1sitename”。我可以确认似乎无法访问 C:\ 驱动器。
-
无论如何，这绝对是错误的层，因为它是托管服务。我们所有的应用服务都使用 Azure 存储文件服务，这可能与您所说的 Azure 文件共享有所不同？ Azure 存储文件仍然基于 REST API，但其行为类似于文件系统。
-
如果您需要来源，请查看blogs.msdn.microsoft.com/kwill/2012/10/05/…。但我实际上是从（不愉快的）经历中说的。这可能非常具有欺骗性，因为您的文件可能会在导致它们被删除的第一个真实事件之前持续数月。只是不要去那里，相信我。设置任何云服务更新后重新附加的 Azure 文件存储网络共享非常容易。如果它必须是 C:\ 驱动器（就像我们的应用程序一样），那么使用符号链接。
标签： azure azure-web-app-service