Right now I have a web job that is Continuos with "Always On". This webjob listens for queue messages and performs actions. Everything works fine but I have to pay for every minute the web job "listens" to commands, isn't it?
I have seen that you can also run a web job on demand but I haven't found any example code on how to execute an on demand web job.
Background: I am running a web crawler inside a web job that receives the URL that should be crawled from a message queue. I would like to minimize the costs.
How can I execute an on demand web job from my ASP.NET website?
Thanks
Since your site is already running on a Standard Instance and the WebJob is running in the same Web Hosting Plan at your site, you are not paying anything additional as both the WebJob (and its host site) and the site itself are running on the same VMs.
You can enable (or leave) Always On enabled and not incur any additional costs. Turning off Always On will not save you any money and as you are aware, it is required for a Continuous WebJob to run properly.
Hope that helps.
Related
We are migrating to Azure. We have a Web App deployed. However, I have a Windows Service that I need to add in to the mix. The service continuously runs, checking the associated Service Bus Queue for messages every 5 seconds.
I am looking for recommendations on how to do this.
I have looked at Web Jobs. But, I don't understand how it gets kicked off. I know there is a Web Hook involved - but I just want the code to run continuously without having to be constantly kicked.
We are also trying to avoid the cost of having a VM involved.
Thanks in advance.
Since you already have a web app, you could use a Azure App Service to run the Web App. The Azure App Service will allow you to also have a Web Job that you can have run on a schedule.
It does not make sense to break you web app into Azure Functions since it is already built. You can have the service run in an Azure Function, but it will probably add more complexity to interact with the web app (if that is what is happening) and if the service is running every 5 seconds, that could get costly.
I've written a Node app that essentially serves as a Task Scheduler (or cron) to run batch processes on set time intervals using node-schedule. When I run this program locally or on a VM, the process will run continuously and execute my jobs until the process is forcibly killed. When I deploy this app to Azure as an Azure App Service, the process is treated more as a "Web App", and after a period of inactivity on the site (ie no web traffic), Azure kills the process. If I access the "site" via a browser, it kicks it back up again.
It seems as though Azure is tied to the Node app being an express-based "web app" and as far as I can tell, there's not a way to deploy my command line app in a reliable manner. Am I missing something or is there a better way to deploy this application in Azure either via Web App, or another offering? Would really like to avoid having to maintain a VM just for this purpose.
For your immediate problem of idle timeout there is a simple configuration available called Always on. Take a look at the link here - https://learn.microsoft.com/en-us/azure/app-service/web-sites-configure.
Always On. By default, web apps are unloaded if they are idle for some
period of time. This lets the system conserve resources. In Basic or
Standard mode, you can enable Always On to keep the app loaded all the
time. If your app runs continuous WebJobs or runs WebJobs triggered
using a CRON expression, you should enable Always On, or the web jobs
may not run reliably.
Also look at cost implications discussion here - Does the Azure Websites "*Always On" option have any implication on price?
Now whether App Service is the best solution or not for your problem of Task scheduling, is a more subjective and longer discussion, where you need to evaluate multiple offerings that Azure has and your requirements/priorities etc.
Azure has it's own task scheduling service - https://azure.microsoft.com/en-us/services/scheduler/
Scheduler Jobs are very simple to configure from Azure Portal. You can:
Make calls to http/https endpoints (which implicitly gives you multiple ways to solve your problems). Authentication can be done using basic, certificate or AzureAD OAuth Client credentials).
Send messages to Storage queue or Service Bus queue/topic which can then be processed appropriately by other processes.
If those Azure Scheduler capabilities aren't enough and you need something more involved, here is some guidance on the best practices documentation on background jobs - https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#schedule-driven-triggers
I have a confusion over differences between using app service alone and app service with web jobs.
I have a computation intense task (2-20 min) that must be triggered manually (user asks for it from time to time). Right now everything happens in one app service. I'm thinking to extract this heavy process to a webjob in another app service. This new app service will be empty (no api served) but host this web job, which I'll trigger from first app service.
I'm bothered that second app service will be empty.
Can I use second app service to do the work without using webjobs (just WebApi project)? Or I should stick to webjobs? What would be pros and cons of these two approaches?
In my opinion, we shouldn't compare the web api and web jobs. Because this two things is used for different environment.
The webjobs feature:
Web Jobs can be configured to be manually triggered or run on a
schedule.
Web Jobs can be configured to be Continuously running (aka running constantly, all the time)
Web Jobs can be setup to be Triggered based on events in other Azure Services, such as a new messaged added to a Storage Queue or Service Buss Queue or Topic
Web Jobs can be long running
Web Jobs can be short running
Web Jobs can be implemented in any language as either a command-line executable or script
Azure Web Jobs can be implemented to fill any background processing need.
So if you want to work with background processing and don't want to return the response to any other application. I suggest you could choose webjobs.
The web api is easy to build HTTP services for the customer to get the response.
So this is used to interact with others. So If you want to get the result and used in any other place. You could choose web api.
The web api feature:
Attribute Routing
CORS - Cross Origin Resource Sharing
OWIN (Open Web Interface for .NET) self hosting
Web API OData
...
All in all, if the computation will not interact with others(return the result to customer), I suggest you could choose web jobs.
Right. So this article: https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/ mentions that you can "You can run programs or scripts in WebJobs in your App Service web app in three ways: on demand, continuously, or on a schedule. There is no additional cost to use WebJobs."
Which is great, the free-alternative is a Scheduler Job Collection
with a job, but you're limited to running it every hour. So being able to run the webjob as part of the webapp, and on a higher frequency is what we need.
However, I'm really struggling to find any way of automating this process. Using the Azure portal to add a web job works fine - but the "automation script" generation tool doesn't generate a json file which includes anything about the webjob - so we'd always have to manually create it.
There are examples of custom templates for automating the creation of webjobs - but they all create said webjob as part of a Scheduler Job Collection, where we are limited to the hourly execution.
To summarise: I'm looking for a way of automating the creation of a webjob, linked to a web-app (such that it doesn't incur extra costs).
Any help would be much appreciated.
WebJobs are deployed by folder convention (as described here), so deploying a WebJob is no different from deploying a Web App. It's simply a matter of getting the files in the right place.
Specifically, triggered WebJobs (manual or scheduled) go under site\wwwroot\app_data\jobs\triggered\{job name} and continuous WebJobs go under site\wwwroot\app_data\jobs\continuous\{job name}.
My Scenario is very simple
A website running in azure which is the host of the webjob (the webjob will run under the context of this website).
A webjob, which is a console based application, scheduled to run every 5 minutes. Printing just a log message using COnsole.Writeline
Now, if i stop the website and go and check the execution logs of the webjob, it still gets executed every 5 minutes.
So when we say webjob runs in the same context of the website, what it actually means?
I believe the "context" here means that the WebSite and WebJob run in the same environment, with access to the same files. For example, you can prepare data for the WebSite in the WebJob. Conversely, you can save data in the WebSite scripts to be later batch-processed by the WebJob. You can also manage WebJobs the same way as the WebSite, they are all accessible using the same FTP(S) account.
If you look at the kudu documentation, it says :
Process model
The Kudu service site runs in the same sandbox as the site. By default, it runs in the different process as the site.
The only thing that really 'connects' the Kudu site to the real site is the file system, and that works regardless of what process or machine they each run on.
So your webjob run under the same environment but used a different process. It shares settings, files but if your website is turn off your web jo will continue on running.