Deploying Multiple but Distinct Instances of the Same Package

(Samuel Kompfner) #1

Hi Team,

I see there have been a couple of previous posts about the similar subject, but none have actually resulted in a suitable or clean solution.

Here’s my scenario:

We have 1 package; “Gateway.v1.0”, a Windows Service.
I have 8 gateway servers.
We need to install 100 instances of “Gateway.v1.0” on all gateway servers BUT each Windows Service needs to be named distinctly, and installed in separate folders, as they each have their own specific configuration, managed by Substitute Variables in Files.

It could be done by creating a step for each gateway (no way!), or with some horrifically complicated Powershell, but do you, our Octopus saviours, have any cleaner solution in the available or in the pipeline that might address this?


(Eddy Ma) #2

Hi Sam

Thanks for getting in touch!

By looking at your scenario, multi-tenant deployment seems like a good fit. Basically each instance is a tenant and has its own configurations, that way you can just have 1 step.During deployment, you can specify what tenants you would like to deploy, also by tagging the tenants in a group, you can deploy to a tag, Octopus will work out what tenants are invoked.

I would suggest to have a look at our tenant document from here if you have not done so yet.

I hope this helps!

Let me know what you think and how you go.


(Samuel Kompfner) #3

Hi Eddy, unfortunately that will not be suitable. We already use Tenants for their designated purpose. And that doesn’t seem a lot different from creating a step for each one. We literally might have 100+ instances of the same package deployed to a server - really needs a dedicated step template that maybe reads off a config script, perhaps?

(Eddy Ma) #4

Hi Sam

I am just wondering at what situation tenant does not fit?


(Samuel Kompfner) #5

Ok…I think I begin to understand…so, it would be one step, with all the config as Octopus variables…each version of the variable would be scoped to a particular instance Tenant, right? And as long as I select all those tenant tags when I deploy that step, multiple instances of the service will be deployed? All configured according to each tenant-scoped variable?

(Eddy Ma) #6

Hi Sam

Yeah, only one step and the rest should be done by variables. A project can have Project Templates and Common Templates which define tenant specific variables. You could get more info regarding tenant variables from here

I hope this helps!


(Samuel Kompfner) #7

Thanks Eddy.

Normally I’d give Octopus 110% for clarity, ease of use, and ‘covering all bases’, but I do kinda feel this is an area that could use some feature development, especially with the trend towards microservices. Perhaps process steps could have a flag called ‘multi-instance’, for example, when if checked, lets you assign Library Sets, or another mechanism, for defining a multiple instance deployment of one component.

I use Tenants for their original purpose, that is, to define feature sets specifically per customer.

(Samuel Kompfner) #8

@Eddy_Ma Hi Eddy, I’m trying to use Tenant Tags to differentiate all the instance of our product ‘Elvis’:
image but I am still only getting one instance deployed:
Do I literally have to create a new Tenant, not Tenant Tag, for each instance of the software I want to deploy?

This is how our Tenant page looks so far (all the tags under IMI Hub are my attempt at create tags for the software instances):

It’s gonna get pretty chaotic if a new Tenant is required for each software instance!

Or am I still not doing something right?


(Tom Peters) #9

Hi Sam,

Firstly, with regards to Tenant Tags, they simply provide a convenient way to group and target sets of Tenants.

Do I literally have to create a new Tenant, not Tenant Tag, for each instance of the software I want to deploy?

Yes, each Tenant typically represents a separate Deployment, so if you need to perform 100 Deployments then you require 100 Tenants. Tenant Tags make it easy to target sets of Tenants, so if you only wanted to do deploy to 25 out of those 100 Tenants, you could target a Tenant Tag associated with 25 of those Tenants. If it is tedious to create 100 Tenants, you could write a script against the API to do this for you.

There is another alternative which may be a better fit for you, and may work better than using Tenants: Create a separate Deployment Target for each instance of the service you need to install.

As with Tenants, this option requires you to create a separate Deployment Target for each instance of the service that you wish to install, so you would end up with 100 Deployment Targets for 100 services. You may also wish to script the creation of these targets using the API, as it may be tedious to create them all manually. Note that you do not need to install a separate instance of the Tentacle service for each of these Deployment Targets - multiple Deployment Targets can reference the same Tentacle, so you only need 1 Tentacle per physical server.

Once you have created these separate Deployment Targets, ensure they all have the same Target Role (eg gateway-service) and then your single step in your Deployment Process just needs to target the gateway-service Role, which will cause this step to run once on each of those 100 Deployment Targets.

If you need to vary the deployment parameters slightly between each Deployment Target, you can do this using the Project Variables. There are two options for how you can configure these variables:

  1. Create separate variable values for each Deployment Target, and scope these values to the appropriate machines (see Scoping Variables). For example, if you wanted to vary the InstallationDirectory for each Deployment Target, then you would have 100 values for the InstallationDirectory variable, one for each Deployment Target.
  2. Create parameterized variables derived from information from the Deployment Target. For example, if you are trying to specify the folder that the service is installed within, you might create a variable called InstallationDirectory with a single value like C:\path\to\directory\#{Octopus.Machine.Name}. This will substitute the name of the Deployment Target in the path, and prevent you from needing to create 100 variables for each of the 100 Deployment Targets.

When trying to decide between modelling this scenario with Deployment Targets or Tenants, one key consideration is that each Tenant will produce a separate Deployment, so you will have 100 Deployments. If you instead use Deployment Targets, then you will end up with a single Deployment for all 100 Targets.

So if the deployment of each of these instances are truly separate and independent (does it make sense to deploy 1 of these services without deploying the other 99?), then Tenants might work well. If they all should be deployed at the same time, or there is other work that should be done as part of this Deployment, then Deployment Targets is probably the best fit.

Hope that helps, let me know if you have any more questions, or if you need help scripting against the API.


(Samuel Kompfner) #10

Thanks Tom. Neither methods really suite the ‘clean’ design we like to maintain in Octopus, so I will raise it as a feature request.

(system) #11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.