Following up my last post on Azure Web App for Containers, in part two we’ll go through the various types of storage options available with Azure Web App for Containers, along with the scenarios where they fit best.
As of writing this post, there are 3 storage options:
- Stateless
- Storage on App Service Plan
- Storage using a Storage Account File Share
Stateless
As you all know, containers without any volume mounts are completely stateless — i.e., the container will not persist data once it is shut down. When you create an instance of Azure Web App for Containers, this is the default option. Reboots on Azure App Service platform can happen from time to time for maintenance. The only files which are persisted across reboots in this mode are the logs which are located under the /home/LogFiles folder.
This scenario is best applicable for APIs where you don’t have to store any data on the server itself. A typical use case would be a 3-tier architecture application where each layer resides as a separate resource in Azure.
Storage on App Service Plan
Using this option allows you to store data on the App Service Plan. In order to enable this, you would have to create an App Setting (WEBSITES_ENABLE_APP_SERVICE_STORAGE=true). In this mode, what happens is that the /home directory is persisted across reboots. Azure does this by mounting storage behind the scenes at this path and then persisting it. As this storage is maintained by Azure, it ensures that it is performant. From what I have seen, in case there is an issue (Performance or Availability) with the storage, Azure will try to switch to the secondary copy and while this is being done, this storage becomes read-only.
When site level backups are enabled on such an instance, the contents of the /home directory are also backed up. The downside to this is that this storage is only visible to your Web app and is not accessible to the outside world.
This option is best for scenarios where storage is required on the server with a minimal overhead of maintenance like when hosting Drupal & WordPress.
Storage using a Storage Account File Share
As of writing this, this option is still in Preview but allows you to connect external services to the Storage Account. This can be set up by going to the “Path Mappings” section of the Azure App Configuration –
This type of mapping supports both Blob containers and Azure Storage File Shares. Although the functionality provided by both is pretty much the same, the technologies behind the scenes which support these are different. For Blob Containers, Blobfuse is used to handle the translation and mapping of file paths to remote blob paths whereas mounting Azure Storage File Shares uses SMB Protocol and uses the CIFS mounts on Linux.
I would suggest you use the Azure Storage File Shares and not the Blob Containers for these storage mounts as Blobfuse is not POSIX (Portable Operating System Interface) compliant. For best performance and stability, use the Azure Storage File Share mount.
While using this option, do keep in mind that the site backups do not back up the mounts. You would have to manage the backups of the mounts on your own.
This option is best suited for scenarios where you need more control over the storage and the ability to connect other devices to the same storage as the Web App for Container.
Stay tuned for the next part!
The trend of making applications serverless is on fire! And it’s not just hype…going serverless makes the administration, monitoring and debugging of code so much easier that developers all around are flocking to use it in one way or the other.
We’ve all heard the phrase, “Anything that can go wrong, will go wrong”…otherwise known as Murphy’s Law. I couldn’t find a better phrase to describe a recent problem we encountered at AIS Managed Services.
Through our 
Figure 1 Mind you, this App Service plan runs another website!