Just deployed a boilerplate Web Role in Azure Cloud service. Upon launching, it seems the default current dir is "d:\windows\system32\inetsrv" and home is "F:\sitesroot\0"
It seems I have limited write permissions, no delete permissions.
2 questions:
How much storage is there on this server under F:\sitesroot? Is it persistent?
How do I control the default permission/access of a web role?
You should be reading/writing to a LocalStorage resource. When you define a LocalStorage resource a folder is configured on the C: drive with appropriate size and permissions setup.
There is no persistent local storage for WebRoles. If you need something persistent then you should use Azure storage (blobs/tables) or something else like SQL Azure.
See http://msdn.microsoft.com/en-us/library/ee758708.aspx for more information, and http://convective.wordpress.com/2009/05/09/local-storage-on-windows-azure/ for sample code.
Related
In Azure I have 2 load balanced VMs with an IIS shared config. These are linked to a premium storage account. All up and running. I have persisted the premium fileshare to both VMs as a drive (S).
The wwwroot is on the storage account, along with the IIS config files.
The app pool is set up as the storage account password so I have access the the share.
All good up to this point.
My issue is that the app also needs to see data on another fileshare. (general fileshare, not premium). This will be used for storage and Archive.
The problem is that the IIS app pool is configured with the creds for the premium storage and fails when trying to also use the general storage.
Can this be done?
Is there a way to link to both fileshares in IIS or should I be looking somewhere else?
Thanks
Colin
Is this even possible? I have a couple web apps and a couple of Azure Functions running under the same App Service Plan. I'd like to (ideally) have them use a specific Storage plan, so I can keep everything in one place. I envision them in different containers under the same plan.
If that's not possible...then where are the files? Are they on the storage that's built into the App Service Plan itself? If so, can I connect to this somehow, so I can manage the files through something like Storage Explorer?
Today when playing with the Azure Az Powershell tool I found I was able to provision a Function App without a Azure Storage back-end. This cannot be done via the UI. An easy way to provision a Function App with a storage account backend is by leveraging the Azure UI for provisioning.
When a Function App is provisioned via command line, the bits seem to be stored within the function app itself. There is an FTP URL given if you download the publish profile. The files can be read and written to using an FTP tool like WinSCP (as alternative to Kudu)
I'd like to (ideally) have them use a specific Storage plan, so I can keep everything in one place. I envision them in different containers under the same plan. If that's not possible...then where are the files?
Every Azure Web App has a home directory stored/backed by Azure Storage. More detail info please refer to Azure WebApp sandbox. It is owned by Azure WebApp Service, we are not able to choose Azure Storage to setup WebApp by ourselves currently. But we could config storage account for Azure WebApp Diagnostic logs.
Are they on the storage that's built into the App Service Plan itself? If so, can I connect to this somehow, so I can manage the files through something like Storage Explorer?
Different WebApp Service Plan has different volume of the storage. We could use Kudu tool (https://yoursite.scm.azurewebsites.net) to manage the files. More detail info about Kudu please refer to the document.
Update:
We could access the home directory with the Kudu tool. More details please refer to the snapshoot
My Azure API app uses the new Windows File storage API.
In the startup on my Azure API app I need to map to a UNC path. The 3rd party application we integrate with needs to reference a local/UNC path for files.
In doing so I am getting a Error: ERROR_ACCESS_DENIED
Is it possible to map a UNC path to Azure File Store in a Web/API app?
If so - is it possible to run the app pool under an elevated account?
Or can I map this drive before using a different account somehow?
Its possible to add a UNC path to an Azure File.
You may getting an access denied due to different user contexts between file share creation and access. Please check out the Persist your storage account credentials for the virtual machine section in this article: https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-files/
Additionally, you could use canned user (storage account name, key) credentials to run the app pool.
I've been working through this tutorial to get started with cloud services in Azure.
The project has one web role and two worker roles, and they share similar code for accessing the storage tables. Could I have a common data access layer shared between them? Would I create a separate role for this? I'm not really sure where to start.
Yes you can, but is that what you want? Sharing the same access layer, all services will access the same database.
You just need to add a Nuget Package Windows Azure Storage and access your storage account / blobs, tables, queues...
My Web Role is on StorageAccount1 and my Azure Storage Table on StorageAccountB.
My Web Role performs operations (inserts, updates, queries) on the Storage Table.
Both of these Storage Accounts are in the SAME Affinity Group.
Will performance be better if my Web Role and Storage Table are in the same Storage Account?
You are probably confused by the "Publish" window in Visual Studio. The "Publish" window allows you to choose some info on how your application is deployed, like the Cloud Service but also the Storage Account. When you choose a storage account it doesn't mean your application will be stored in that storage account, it only means that the service package (the package which contains your application) will be uploaded there. Once the package is uploaded the Fabric Controller will take it and deploy it to your Cloud Service.
Besides that it's still a good idea to deploy your Cloud Service (Web Role) in the same affinity group as your Storage Account. By choosing the same affinity group Windows Azure will try to physically group your Cloud Services and Storage Accounts to minimize the network overhead.