10

(Note that I'm using the new "blade" Azure Portal exclusively and use the new terminology, so avoid words like "Azure Website" as they do not apply here).

In the Portal I created two Azure App Services, "foo-production" and "foo-staging" - both exist in the same Subscription and Resource Group, and share the same App Service Plan. These App Services represent the production and staging deployments of a straightforward ASP.NET web application, which runs as a normal website.

The App Service Plan is "Basic: 1 Small".

My understanding is that when you use Azure App Services with a Basic or higher App Service Plan, that the Plan represents a VM which I'm able to host as many IIS websites as I want on - these IIS websites are represented in Azure as Azure App Services.

Given this, one would assume when I access the filesystem of the VM in Kudu ( https://yourwebsite.scm.azurewebsites.net/DebugConsole ) that I would be able to see each website's files under some common root directory.

However when I access the Kudu console for the foo-production website, I see that its files are in D:\home\site\wwwroot and files for foo-staging are not to be found.

If I'm understanding this correctly, it means that Azure actually created a whole new VM just for each website and that websites cannot share a filesystem - and that I cannot have a more advanced Azure-managed IIS configuration - I'd have to create my own self-managed Windows Server VM.

I can understand the motivation behind a separate VM for each website, it just seems wasteful - Windows Server requires at least a gigabyte of memory for each VM, yet my website is largely just static files (but I can't use a Shared App Service Plan because I need some of the more advanced functionality). That can't be economical for Microsoft then.

How can I have multiple Azure App Services in an Azure-managed environment share the same VM? Or am I thinking about it incorrectly?

To avoid an X/Y problem: I'll state that my primary concern is the persistence of files. The web-application I'm deploying stores uploaded files to a subdirectory of the webroot and those files should be there permanently. There is ambiguous information out there: some people suggest websites (and all their files) are actively destroyed and recycled and that Azure Storage Blobs should be used. I would like to use Azure File Shares, unfortunately I get ACCESS_DENIED errors when using WNetAddConnection2 and some users report that Azure File Shares cannot be used from within Azure App Services - though I cannot find anything authoritative from Microsoft about this.

Dai
  • 141,631
  • 28
  • 261
  • 374
  • I belive the number of VM's is based on the App Service Plan. Since it's "1 small", that means you have 1 VM. There must be some other file storage mechanism that is making the sites appear to see their own versions of the D drive. – mellamokb May 10 '16 at 02:06
  • @mellamokb Interestingly, there is no `C:` drive - everything, even the `Windows`, `Program Files`, and `Users` directories are all under `D:` – Dai May 10 '16 at 02:08
  • If you look under the Environment tab, there are hints of a shared C:\ drive: `C:\DWASFiles\Sites\#1sitename\` is what I see for example. I can confirm it doesn't seem possible to access the C:\ drive. – mellamokb May 10 '16 at 02:11
  • Regardless, that is definitely the wrong layer, since it's a managed service. All of our app services use Azure Storage File service, which is maybe something different than what you mean by Azure File Share? Azure Storage Files is still REST API based but acts sort of like a file system. – mellamokb May 10 '16 at 02:13
  • @mellamokb It's a legacy application that needs to be moved to Azure quickly. – Dai May 10 '16 at 02:14
  • Then I would recommend either a full-blown VM or at least a IaaS cloud service. Cloud services are scalable and highly available, but you can also RDP, mount network shares (e.g. Azure File Storage), and generally interact with the file system. However on Cloud Service you do have to persist to something more than the local file system, which gets destroyed during fabric updates or OS updates. – mellamokb May 10 '16 at 02:17
  • @mellamokb Please link me to an authoritative information source that states files are lost, deleted or destroyed on Azure Cloud Services or Azure App Services (formerly known as Azure Websites). – Dai May 10 '16 at 02:35
  • 1
    If you need a source, check https://blogs.msdn.microsoft.com/kwill/2012/10/05/windows-azure-disk-partition-preservation/. But I'm actually speaking from (unpleasant) experience. It can be very deceptive, because your files may persist for many months before the first real event that causes them to be deleted. Just don't go there, trust me. It's very easy to setup a Azure File Storage network share that you reattach after any cloud service update. And if it must be the C:\ drive (like our application was), then use a symlink. – mellamokb May 10 '16 at 02:38
  • @mellamokb The article you linked to is from 2012 and refers to `.cspkg`-deployed applications, for which the ephemeral nature of local file system storage is very apparent, however my question relates to Azure App Services. – Dai May 10 '16 at 02:51
  • This isn't the place to have a discussion. Take this to chat. Or folks can start posting answers. – David Makogon May 10 '16 at 03:02
  • You might find this question useful - about the architecture of app services - http://stackoverflow.com/questions/35253899/ – Michael B May 10 '16 at 05:18

3 Answers3

14

If they are in the same App Service Plan, they are running in the same VM. Try typing hostname in Kudu Console for each and you'll see the same machine name.

But note that they each run in a different sandbox, which prevents them from seeing each other's files. Folders like d:\home are virtualized, and are actually pointing to network shares. So you can't use that to make conclusions as to the machines are the same.

David Ebbo
  • 42,443
  • 8
  • 103
  • 117
  • 2
    Seems David Makogon just beat me to it, so you can pick his answer :) – David Ebbo May 10 '16 at 03:11
  • 1
    Can you elaborate on the sandbox mechanism? I'm keen to learn exactly how it works - and if I can achieve the same effect on my own, self-managed servers. – Dai May 10 '16 at 06:43
  • You can read more about the sandbox here: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox. It's special to Azure Web Apps, so you cannot use that same sandbox locally. – David Ebbo May 14 '16 at 21:06
8

As I answered here, all app services within a plan run in the same set of VMs, sharing all compute resources.

You assumed each app service within a plan shares files with all other app services. This is incorrect: Each app service will have its own set of files, in d:\home for each app service. If you need to share files, you'll need to use something external to App Services, like Azure File Service (an SMB share). Azure File Service is separate from the space created for you on a per-app-service basis.

David Klempfner
  • 8,700
  • 20
  • 73
  • 153
David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • 1
    Is it 1 VM for all app services within a plan or is it a set of VMs for all app services within a plan? I'm asking this because I am currently experiencing some weird problems in Live environment and I have seen that prod-staging has a different hostname than prod and I want to figure out if this is a good lead to find the problem. – Flavia Obreja Feb 01 '19 at 20:07
5

  1. An Azure "App Service" is analogous to a "Container" (Docker terminology). Although it's based on a VM, it's much lighter weight than a VM itself. For example, you cannot RDP into it.

  2. An Azure "VM" is a full-fledged virtual machine. The OS can be Windows or any of several different flavors of Linux.

  3. You can get more information here:

Here is an excellent article that compares Web Sites (one example of an App Service), Cloud Services, and VMs:

http://www.c-sharpcorner.com/UploadFile/42ddd2/azure-websites-vs-cloud-service-vs-virtual-machines/

Azure Websites

Azure Websites has very little responsibility to complete, and relatively less control. It is the best choice for most web apps. Deployment and management are integrated directly into the platform we get.

Azure Cloud Services

If you want more, web server like environment you might want to go with Azure Cloud Services. You can remote into your cloud services and configure startup tasks. Cloud Services provide you more Ease of Management and Agility than Azure Websites

Azure Virtual Machines

Provides you rich set of features; however, correctly configuring, securing and maintaining VMs require much more time and more IT expertise compared to Azure Cloud Services and Azure Websites.

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • 2
    This is orthogonal to the question, which has nothing to do with comparisons between VM/Cloud Service/App Service (and Service Fabric). – David Makogon May 10 '16 at 12:38