Azure: Stop a Role without stopping all other Roles in hosted service

Question

As an example, I have a hosted service with two roles, web and worker. I want to get rid of the worker role temporarily. Is there an easy way to achieve this? It would seem like something that should be trivial.

In the azure portal, if I select one of the roles and hit STOP, it stops all the roles in the hosted service. In Visual studio, I could delete the role from the "Roles" folder and republish, but then when I want to have that role start again I would have to go through the whole process of adding the role; and a seemingly unnecessary publish.

Answer 1

At the moment you won't be able to do this without republishing your application. But there is an easy way to manage this in Visual Studio. You can create 2 Azure projects, one with the WorkerRole and one without the WorkerRole (note that you'll need to duplicate everything you configure for the WebRole, like certificates, service configuration, ...):

And to make this deployment process a bit easier I suggest you write a PowerShell script that does the following (for example):

• Upload *.cspkg
• Deploy to staging
• VIP swap
• Delete staging deployment

Anyways, changing the number of instances to 0 would have been the perfect solution for you, but this isn't possible at the moment. Someone of the product team confirmed that this feature would be coming, but it would only be in a release after the fall of 2012. Vote for the feature here.

Answer 2

No, not without redeploying, because roles are defined in the ServinceDefinition, and this cannot be changed once a service is deployed. You can change the ServiceConfiguration (e.g. number of role instances, but not to zero).

As Jim says, you can force instances to restart. You could probably even saboutage instances so they would not successfuly start after restart.

Answer 3

This thread is a few years old now, but we still have the same problem as I write this answer.

The one somewhat cleaner way that I've found is to introduce a setting in my worker wole's service configuration, with a boolean string.

Then, in my WorkerRole.OnRun(), I can leverage the setting flag to affect code execution path with an if statement.

Note that this will not actually stop the Worker Role instances from running, it simply will add a "feature flag" pattern that prevents the actual worker code path(s) from executing during each loop iteration of the role's OnRun().

The benefit of this is that if I update the setting from the Azure Mgmt Portal, it will force the role to restart and pick up the new setting value.

The con is that if you were trying to turn off the worker role to minimize cost, this will NOT help you as the role instances will keep running.

HTH

Answer 4

Another solution is that you can run the Web roles in one deployment and the worker roles in the other. As long as your solution didn't require the roles to communicate directly with each other then should be fine. For example, if the instances communicate with each over queues then both deployments can utilize the same storage connection string (or Service Bus namespace).

Having the separate deployments allows you to have scripts to tear down the worker role when you don't need it and redeploy it when you do. While the answer that Sandrino provided works, it requires there to be the VIP swap and full deployment involving the web roles which you don't want affected. Using two separate deployments allows you to keep these separated and still get the result you want.

If the roles do need to communicate directly with each other without some shared intermediary (like a queue or a database) then Sandrino's answer looks to be a decent option. Also, make sure to vote for the feature he links to.