When looking at the original request to implement rolling deployments I noticed the option to run the PowerShell script would allow the script to run from the octopus server itself:
We use a PowerShell cmdlet that needs to be installed on the server and registered. Unfortunately we do not want to install this on each of our servers, and think running it from the octopus server would be a better option.
We originally planned to allow Octopus server to execute PowerShell scripts. But as we went down this path, it began to open up a number of security issues. So then we thought about having Octopus have a worker process for executing scripts, and went down that rabbit hole, before realizing: we have a worker process, it’s called Tentacle.
So the solution is to install Tentacle on your Octopus server, and to add that Tentacle to each environment, probably with a role like “octopus”. Then, have your script step run on the “octopus” role.
We are trying to get to a point where we can use the new rolling deployments, but cannot see how it would working our set-up at the moment. When a child step is specified it cannot run on a different role to the parent step.
I already installed the tentacle on the deployment server but the main variable we need to pass to the “Remove from load balancer” step is the current server we are deploying to. Presumably this is what the child steps were created for.
We have 2 roles of servers, A and B. Our current octopus process may look something like:
PS (Remove servers A)
Deploy to A
PS (Add servers A)
PS (Remove servers B)
Deploy to B
PS (Add servers B)
As you can see, we have duplicate steps. We also do not have the ability to easily specify which group of servers we are taking offline for the deployment, without adding the IPs manually.
We could possibly use child steps if we had the ability to run the script on a different role with access to some context information about the current server, e.g. the IP address or some scoped variables.
Create a variable for each machine with its IP address (call it IpAddress for example). In the “Scope” settings for the variable, scope the value to the machine.
Set up a rolling deployment to all machines in the A role. Use the $IpAddress variable in the script to remove/add the machine
This would bring us back to the original question. If we use rolling deployments at the moment the powershell script executed runs on the tentacle of each server, not the tentacle of the octopus server.
We are using multiple data centers and would like the ability to rolling deploy to each data center, each with their own config (ideally).
It appears that we could make rolling deployments work if:
The child PowerShell step can be executed on a different role. We are using a load balancer which requires a PowerShell cmdlet to be installed and registered on the machine, which we do not want to install on each server nor do we think this is a good solution.
The ability to have child environments within an environment. This way we could have child environments for each data center and also tweak any configuration variables we have specific to each data center.
The rolling deployment could then be more flexible and allow us to rolling deploy across child environments, roles or batch size.
I hope our scenario now makes sense. The main issue is the limitations of the child steps. We also could do with more power to distinguish between data centers and provide alternative configuration.
Thanks for expanding on the scenario Michael, I think I understand the issue now.
When we designed rolling steps we limited the child steps to only running on the same machine as the rest of the rolling step. The reason for this is that otherwise, the UI would get confusing:
Rolling step across machines in role web-server
Take out of load balancer (role: admin-server)
Remove from load balancer (role: web-server)
Return to load balancer (role: admin-server)
The tricky part is what happens if there are multiple machines in the admin-server role as well as the web-server role - do they all get called at once, or just one, and what arguments do they get given?
Now, the current limitation is there because this seemed like it would complicate the UI and we weren’t sure if anyone actually had a scenario like this. Now we do know
I’ve made a note here to think about how this can be. We will do it, it’s just a question of how and when.
As a workaround, perhaps you could make a tiny service that runs on the Octopus server and accepts HTTP requests to add/remove machines from the balancer (which then calls that PowerShell cmdlet). Then you could have your PowerShell script in the rolling deployment invoke that service?
No problem. Yeah I can understand how the child steps could get confusing if the role is different, especially if there are many servers in that role. Thanks for adding this as a feature.
We did consider making a web service to remove the machine from the load balancer as suggested but we have kept this on the back burner thus far in order to reduce complexity and add a few more steps into octopus for the time being.
Thanks Dalmiro - that is not a solution in this context because we need to run it as a child step within a rolling step.
For each web server, we need to execute a script task on the load balancer.
This seems like a really basic request and probably a universal need for anyone using load balanced deployments. I don’t understand why this is still not supported?
Apologies for my wrong reply! I misread the overall idea of this thread the first time.
The github issue about this is still open, meaning we will eventually get to it (otherwise we would have closed it already). Unfortunately I still can’t give you an exact date for it, but I’m sure you’ll get a notification when something happens now that you commented on the github issue.
Okay - thanks! For what it’s worth I have a tentacle on the load balancer and have successfully tested my scripts on it using the Octopus Script Console.
All we need now is for the child step to be able to run the script! Tiny little change. Super small.
