Support "run on any tentacle" model for deployments
We use tentacles primarily as machines that deploy code to Azure, thus they act more like "Deployment Agents" than "Deployment Targets". As a result, it would be nice to be able to configure a project/step/etc. to run on the first available tentacle in a pool (defined by environment/role/whatever).
Right now, if I were to have a role "azure-deployer", and I had multiple tentacles in that role, my steps would run on ALL tentacles in that role. Instead, I'd like to be able to have it run on the first available tentacle. Of course, an alternate solution (that we are using as a workaround) is to give each project its own tentacle (sometimes sharing a machine with other tentacles), but this is less flexible given that all we need is for the deployment process to pick ANY available tentacle.
Anyway, we're loving the product, and are able to work around this issue, but this would be a cool feature!
Andrew Stanton-Nurse
shared this idea
Workers were designed to solve this scenario: https://octopus.com/docs/infrastructure/workers
4 comments
-
Jonathan Goldman
commented
We are exploring another way of solving this issue.
The first step of the deployment process is a powershell script set to run on octopus server which uses Octopus.Environment.MachinesInRole[] to random select a machine to use as the "database deployer". This is then saved in an octopus variable.
Subsequent steps which need to run only on a single machine check that variable against Octopus.Machine.Name.
-
Nikola Sivkov
commented
We have the same issue... we have many projects and servers and the roles thing isn't very maintainable.
-
Casey
commented
Building on the below question from the support forums, we have a task that I want to only run 1x per a deployment. We have too many machines to track which ones are live to use the approach of a special role to *run once*, and with ODs acceptance of ephemeral machines, keeping up with a machine in this special role is an undue maintenance burden. We should have a simple check box that for a particular environment / deployment, we only want to run a step once.
For context on how this helps, the question below was to run a DB script once per deployment and not get triggered for each machine.
My case is running a script that tags a GIT Repos on release. I can work around it by testing for tags and not retagging, but allowing a once per deployment will minimize load, remove unneeded calls, speed up deployment time (we have envs with 100s of boxes) on my GITHub Ent server.
-
Piers Williams
commented
Often there are tasks that *can* run across multiple machines in an environment, but *should* run a limited number of times (most common being only-once). Database scripts are probably the canonical example, but others exist.
In that case it would be useful to limit (globally) the total number of times a step will execute across all nodes in the deployment. Think of it as a upper bound on a rolling deployment.
Existing workarounds include running the step against a specific 'tag', which only exists once per environment, but this is a hack because it can't respond dynamically to changes in the server environment (cattle not pets?), and instead requires tedious manual configuration.
Another workaround is to make each deployment step idempotent, but this can be hard to achieve depending on the nature of the step, and can incur an additional time penalty on the deployment (depending on how long the step takes, and how many nodes are involved).
This is similar to http://octopusdeploy.uservoice.com/forums/170787-general/suggestions/7049888-deployment-machine-index but I raised this because I think this should be supported first-class, rather than able-to-be-supported-by-hacks-in-scripts.