I have a web role in a cloud service with 2 instances.
I have a function that creates files in one instance and switches to the other mid-function, causing 404 errors because it can't find the files.
In Azure Web Apps, there is a setting in the Azure Portal to turn ARR Affinity on or off. I don't see anything like that in Azure Cloud Services.
For cloud services, you'll need to install it manually by yourself on your startup task of csdef file.
ARR is not installed by default for IIS.
You can refer to this article for more information (from step 4).
Related
(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.
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.
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.
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.
An Azure "VM" is a full-fledged virtual machine. The OS can be Windows or any of several different flavors of Linux.
You can get more information here:
Azure App Service, Cloud Services, Virtual Machines, and Service Fabric comparison
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.
I have a Worker Role that need complex environment settings (install a couple of softwares, setup some directories and etc) so I want to deploy it to VM ( instead of Cloud Service that specialize in more simple environment without pre configure settings).
The problem that I can only publish to Cloud Service (from VS 2013), am I missing something ?
I tried to find some article and relevant materiel about deploy a Worker Role to a VM and the only things I found is related to the Cloud Service.
How can I do it ?
(or provide me a general guidelines)
Simply put, you can't deploy a Worker Role as is into an Azure Virtual Machine (IaaS) without doing code changes.
Things you could do:
Isolate your business logic into a separate DLL and then create a separate Windows Service project which consumes this DLL. Then you could deploy that Windows Service into a VM. Do note that your business logic DLL should not have references to any libraries which will only run in Cloud Services kind of environment (e.g. Diagnostics, ServiceRuntime etc.)
Do take a look at Startup Tasks for Cloud Services. They do provide a mechanism to perform additional tasks like installing software when your Cloud Service is deployed.
Azure Web Jobs are a big time saver in that they solve the plumbing of triggers, continuous running, dashboard, etc. But I've only seen them run in Web sites. It'd be great to be able to move them to a Worker Role. Do you have suggestions about how to do it?
I'd personally love to see how they implement it, so that I can replicate it in my worker role, without reinventing the wheel...
The answer to the main question is No Azure WebJobs are part of Azure Websites and only run in an Azure Website context/host.
But Azure WebJobs SDK which is an SDK that allows you to write code that is triggered on Azure storage blobs/queues and Azure service bus queues including some great logging capabilities, can be used outside of Azure WebJobs and so they can run anywhere (locally, VMs, WebRoles).
It is important to understand that Azure WebJobs are a framework that is part of Azure Websites that allows (almost) any console application (and .bat, .php, .js, ... scripts) to run continuously or triggered (manually/scheduled).
WebJobs SDK and WebJobs are not dependent on each other although they work great together.
Also to see how it's implemented go to https://github.com/projectkudu/kudu as it's open sourced (for now The WebJobs part, SDK may be open sourced in the future).
Yes, you can use Azure WebJobs outside of Azure Web Sites. You use the Azure WebJobs SDK to do so. There is a sample on MSDN on how to use the SDK in an console app. It then goes on to host it in a web site, but you can of course host it in other ways. There is another article, "Hosting Azure webjobs outside Azure, with the logging benefits from an Azure hosted webjob" that explicitly talks about using WebJobs outside of Azure. With a little work this should work in a Worker role as well.
I'll stipulate that I've not actually done this myself, but the SDK does make it possible.
I'd also recommend this treasure trove of resources for WebJobs.
I have successfully deployed my service to the azure cloud services and its working great. But I am having one problem, I have a logging layer in my service which logs activities and error to the log files. But now when I have deployed my service to azure cloud services I am unable to access the log files, since I made the package file for deploying it to azure. Can somebody tell me how to access those logs file.
Windows Azure Diagnostics - http://msdn.microsoft.com/en-us/library/windowsazure/gg433048.aspx.
There is also a couple short 5 minute videos that shows how to set it up and use it - http://channel9.msdn.com/Series/DIY-Windows-Azure-Troubleshooting/Enabling-WAD and http://channel9.msdn.com/Series/DIY-Windows-Azure-Troubleshooting/WAD-Intro.
I have several web and worker roles in my solution, but I also have a non-Azure application running on a Azure hosted VM. That application connects to Azure storage for various things like reading and writing blobs and queues, and that works fine.
I'd like to use Azure diagnostics from within that same application (a .NET app running on a VM hosted in Azure). However, if I try to initialize diagnostics I get an exception that:
System.InvalidOperationException: Not running in a hosted service or the Development Fabric.
This makes sense, but I'm wondering if it's possible to use the diagnostics in some way without being a hosted service. In particular, I'm using azure diagnostics to gather logging information, written out by System.Diagnostics.Trace, and that's all hidden away from the application code, so if there were some other APIs I have a place I can probably slot that in.
Any ideas?
Thanks,
JC
Unfortunately, no. At least not today. The agent has some hard-coded checks for the RoleEnvironment stuff and when it is not there, it fails. This is also the reason you cannot use the agent in the IaaS stuff today either.