Like many others I am enthusiastic about the lightweight WebJobs that can so easily be added to Azure Websites.
But I assumed one of the advantages with WebJobs was to easily modify the scheduling. When I tried I was surprised that there seems to be no way to do that. A deployed WebJob seems to be stuck with the initial scheduling.
Do I need to deploy new WebJobs just to modify the scheduling?
To change the schedule, or to Modify the CRON value just use the App Service Editor to modify the WWWROOT/App_Data/jobs/triggered/YOUR_WEBJOB_NAME/settings.job file;
By the time of writing, App Service Editor is still in preview but it
will work.
In the settings.job file amend the schedule in CRON value and will be reflected in the App's Web Job Dashboard.
The App Service Editor is available in App Service > Development Tools
App Service Editor (Preview)
I finally found it.
Scheduled WebJobs turn up under Scheduler in the main bar.
The Save button is not visible until you actually make a change.
Related
I have a deployment process that places everything needed within a repository which my azure AppService is already configured to pull from.
This deployment process is fully automated and works well.
I would like to amend this deployment process to include one or more console applications which would then be configured to be run as WebJobs, either when triggered, or on a continuous basis.
However the configuration for webjobs appears to want me to upload the .exe during configuration, rather than point at a pre-existing .exe.
This seems less than optimal, because it suggests that I'll have to reupload each time said console app changes.
It would be far more convenient to be able to point to a known location within the AppService which contained the full deployment of the WebJob console App.
Is there a way to achieve this?
As I know, the deployment process you want couldn't be done. No matter on which way WebJob is deployed, Job is copied to the file system on the Kudu in essence. And WebJob is a function depending on Web App Service, so the deployment couldn't be processed as a whole. You could read the Wiki.
From your description, I suggest you using Azure Functions. You also could use TimeTrigger、BlobTrigger、HTTPTrigger etc. You could write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it.
If you still have questions, please let me know.
I am updating my Azure App Service from Azure DevOps. Currently, my release is like this:
Stop the App Service,
Update the App Service, and
Start the App Service.
My question is whether it reasonable to stop the App Service during the update? When I select a release template from Azure DevOps for Azure App Service, there are't any stop/start steps, only the update step. So I am wondering if the stop/start is even needed?
What we have done mostly is:
Stop staging slot
Deploy to slot
Start slot
Swap staging to production
Stop staging slot
Martin's suggestion on Take app offline is also a good one!
We prefer to deploy to slots and then swap so we incur minimal impact to production and can also rollback easily.
Stopping/taking app offline can prevent file locking issues.
It probably depends on your app. If you don't have any issues when you just update your app (such as the a file is in use issue) you can consider to use the Take App Offline flag which will place an app_offline.htm file in the root directory of the App Service during the update (then it will be removed). This way user will recognize that something is happening with the app.
However, I often ended up doing the same like you: Stop, Update, Start 😉
There are (5) options for safe-deployment (atomic updates) to Azure Web Apps. Here is my preferred order ranked by priority and feature richness:
Run-from-Package + ZipDeploy (makes site read-only)
ZipDeploy (using kudu REST api - automatically takes site offline)
Azure CLI (az webapp)
msdeploy (-enableRule:AppOffline, or stop/start site to enforce atomicity)
FTP (using publish profile, make sure to upload appoffline.htm)
There are numerous other deployment options like cloud sync, github continuous, local git, etc - but they are all built upon Kudu APIs (as is Azure CLI).
Note: If you're using Azure DevOps - it's supports nearly all these options - leverage the Azure App Service Deploy task
Agree with both Martin and juunas. If you want to deploy without impacting users then you need to use the slot swap approach. juunas brings up the great point of easily rolling back too. Our approach includes another slot we call "hotfix". This adds a few benefits:
Having an environment with production configs so that you can optionally do additional testing before actually doing the swap.
Roll back in prod even when devs have already deployed into a staging environment.
Allows you to test bugs in the current and previous versions of the code. Helpful when someone says "well it worked before this deployment"...
This is what it looks like.
I've added some webjobs to an appjob. The webjobs are deplayed from VS together with a new version of the webapp.
TO schedule the jobs I've added a settings.job file to the webjob rootfolder.
If I look in Azure the webjobs are scheduled correctly.
But how to change that schedule from Azure ? The only way to change that schedule now seem to be to change the settings.job file and redeploy from VS.
UPDATE:
given that KUDU does not always work and that the procedure to change the schedule is not really fit for a non-tech user. I started looking at using azure scheduler. But cannot find out how to get it working.
From the webapp|webjob configuration I took the webhookurl, usr, pwd.
Created a new schedule using this webhookurl and credentials (basic auth)
But I get this error:
No route registered for '/api/triggeredwebjobs/<webjobname>/run'
Any suggestions?
how to change settings.job schedule.
You could put the settings.job file at the root of WebJob directory and modify it, then redeploy your WebJob project.
You could leverage kudu, and navigate to D:\home\site\wwwroot\app_data\jobs\triggered\<job-name>, then modify the settings.job.
Moreover, you could use the WebJobs API for creating/updating the schedule for a triggered job, and it would automatically create/update the settings.job file for you.
PUT https://{webdeploy-username}:{password}#{your-webapp-name}.scm.azurewebsites.net/api/triggeredwebjobs/{webjob-name}/settings
Body: {"schedule": "*/30 * * * * *"}
I have checked my WebJob log on kudu, it would take some time for the modified schedule to take effort.
I started looking at using azure scheduler. But cannot find out how to get it working.
No route registered for '/api/triggeredwebjobs//run'
For Azure Scheduler, you could refer to David Ebbo's blog here. Based on your error, I assumed that your Http method is wrong, you should use POST. Here is my test, you could refer to it:
For those who struggle with the same issue :
Best solution turned out to be to use Azure's Scheduler Job Collections.
The tricky part was finding out how to set this up.
Action settings:
- https
- copy the uri you find in the properties page of the webjob to call, it is called 'webhook'
- copy the credentials from the same place
You can also access Kudu (Advanced Tools) at https://yoursite.scm.azurewebsites.net, and modify the settings.job file directly via the Console.
I would recommend you redeploy though so that you have the right schedules in your version control at all times. Otherwise you might publish and then realize you have the old schedules again.
We have a website running as a web-app service on Azure. Our CM environment stalls and needs restarted periodically.
While we investigate the cause of this, I'd like to set the application pool to refresh overnight. I can't find anything in the portal to indicate how or where this is done. Can anyone help?
The Kudu service allows you to setup auto healing based on rules for memory, requests, or status code. To get to the dashboard navigate to https://[Your Azure App Name].scm.azurewebsites.net and then click on Tools -> Support and then turn on Autoheal, click Update and then optionally add any rules that make sense.
For more details, check out the blog post Auto Heal your Azure Web App.
You can assign a webjob to your service where you can upload a zipped .bat file and schedule it to run using a cron job
I THINK something like this should do it
azure webapp restart --resource-group xxx --name xxx
But, don't really want to mess about too much with our live environment.
The Kudu solution looks like the one we are going to go with. But, not until we take a good look at the perfomance/analytics. We definitely have a memory leak on the go somewhere
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}.