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:
- 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.
- 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.
Regards,
Tom