28

What will happen when I deploy a continuously running Azure WebJob with a QueueTrigger (queue connection defined in app.config) into a Deployment Slot (for example "Staging")?

Will it start to run and listen to messages in the queue or will only start in the Production slot?

My fear is that if will just start processing messages from the queue even tough its not in the Production slot yet. If this is the case, should the queue connectionstring be moved from app.config into Azure Website config so my Staging and Production slots can run on different queues?

pbering
  • 933
  • 6
  • 8

3 Answers3

34

Using slot sticky settings, you can now set

WEBJOBS_STOPPED = 1

on the staging slot. This will prevent webjobs from starting on the staging slot, and the setting will remain on the staging slot when the code is swapped into production.

https://github.com/projectkudu/kudu/wiki/Web-jobs#configuration-settings

Erik A. Brandstadmoen
  • 10,430
  • 2
  • 37
  • 55
  • 1
    Just remember to check the "Slot setting" checkbox or it will indeed swap to production. – mlienau Aug 24 '16 at 21:25
  • I set this value on the stage slot, but after updating stage (auto swapping), the webjobs are still running on my stage slot. Am I missing something? – scojomodena Feb 23 '17 at 03:57
12

Yes, it will start running in the staging slot.

If you don't want this, then pointing it to a staging queue is indeed the way to go.

Update (11/24/2014): you can now chose to make certain setting & connection strings 'sticky to the slot' using PowerShell. See this post for details.

David Ebbo
  • 42,443
  • 8
  • 103
  • 117
  • 3
    If we're swapping Staging w/ Production ... then that means I have to go in and manually re-configure my Queues right? If I've setup a 'staging' Queue for my 'staging' slot to work with, then when I swap... my now "production" (which was just "staging") will still be pointing at the "staging" queue, right? – ericb Jun 27 '14 at 20:24
  • 3
    You are correct, and this is not ideal. We are working on improving the situation by allowing some settings to become 'sticky to the slot'. i.e. if you set something on the staging slot and mark it as sticky, it will not swap into production. – David Ebbo Jun 28 '14 at 01:08
  • 1
    I just got burned when switching slots and failing to stop a continuous job on the staging slot so that I ended up with the old version and new versions both running at the same time. Sticky would be good because then I could have the staging slot always point to its own storage and queues. – jdasilva Aug 10 '14 at 06:35
  • David, I'd love to be able to set ConnectionStrings as sticky to the staging slot. – Maarten Aug 27 '14 at 20:56
  • 1
    Not to mention the ability to do config transforms like web project releases; rather sad it's still not baked into VS. – pdwetz Sep 01 '14 at 04:31
  • 6
    Another question - not sure it's worthy of a new SO post - what happens if a webjob is currently running when you do a "swap"? – Matt Roberts Mar 19 '15 at 16:18
  • Why are webjobs not duplicated when you create a slot and import the existing prod? – Tony Gutierrez Jun 28 '18 at 21:38
  • @TonyGutierrez because generally, that feature only imports **metadata** (like App Settings), but does not copy any **files**. Note that what you are asking is not really related to the original question, so you may be better of asking a new question. – David Ebbo Jun 29 '18 at 16:20
  • To users, webjobs are settings. I get that behind the scenes they are stored in files, but I was surprised to find mine gone after a slot swap and in researching have seen many others with the same issue. – Tony Gutierrez Jun 29 '18 at 19:57
0

My solution is to remove the Web Jobs from the slot(s) after deployment, before swapping slots and/or starting the app service in the slot:

az webapp webjob continuous remove --webjob-name fooJob --name fooApp --resource-group fooApps --slot fooSlot

Can be done in Azure DevOps Release by adding Azure CLI task with inline powershell script.

Darth Sonic
  • 105
  • 7