When you create a deployment target in Octopus Deploy it has to be assigned to at least one role. What does a “role” mean? How do they work in Octopus Deploy?
You need to be able to tell Octopus Deploy where to deploy code. However, you cannot use machine name, as that will (most likely) be different for each environment. Roles allow you to define the server you want to deploy. In this image below, the deployment will occur on any server with the role OctoFx-Web.
When a deployment occurs Octopus will find all the servers with that role in that specific environment. In this case, when I deploy to Dev it will find two servers.
The role name itself is very important. If at all possible, do not use generic role names such as IIS-Server or App-Server in your deployment process. We recommend [App]-[Component] such as OctoFx-Web and OctoFx-RateService. This will give you more control and flexibility. If your process is deploying to IIS-Server and you want to have a separate server for that specific app then you’d have create a unique role and then go into the deployment process and update it.
A deployment target can be assigned to 1 to N roles.
However, don’t include the environment name in the role, such as OctoFx-Web-Prod. That will lead to unnecessary steps added into your process and more maintenance than necessary.
In your scenario you have 2 servers in the Development environment, both having the OctoFX-Web Role.
Can you elaborate a bit as to how you would be able to have one Tenant deploy to d-octofx-web-01 while another Tenant would deploy to d-octofx-web-02?
When looking at ‘Preview and customize’ just before deployment, it shows me all the deployment targets that fit the Role targeted by the deployment step, even though the Tenant I’ve chosen to deploy to is only associated with one of the two available deployment targets with that Role in the Environment.
With the multi-tenancy feature in Octopus Deploy you can set 1 to N number of tenants for a specific deployment target.
Once multi-tenancy is enabled on a project, the overview screen changes so you can pick which tenant gets which version and at what time.
Thanks Bob.
I think i get the multi-tenancy idea but having trouble getting things to happen on specific deployment targets when there is more than one target in the specified role in the environment.
Given the following scenario:
I have a Production environment with 2 SQL servers (SQL1 and SQL2). Client databases are to be installed to either one or the other, not both. Each server has a tentacle installed so they each appear as a discrete deployment target. Each of the SQL servers is assigned a Role = SQLSVR. Only the SQL2 deployment target is associated to my tenant CLIENT1 (specified by name, not tag).
My project has a step that checks to see if the database already exists on the SQL server. The ‘On Targets in Roles’ value = SQLSVR. The ‘Conditions:Tenants’ is set to run for All Tenants.
When I run a deployment for the tenant CLIENT1, the Preview and Customize dialog shows me that it’s going to run the step on both SQL1 and SQL2 (and when tested it does run on both servers.)
I’m assuming that this is because both servers are in the Role targeted by the step?
Now I can include/exclude deployments targets manually here at deploy time… but that’s not very ‘automated.’
How would I make sure that this step ONLY executes on deployment target SQL2? My actual environment will have 5+ SQL servers all in the same Role, but when I install a new database it only needs to go on one server… not all 5.
I don’t recommend installing tentacles directly on SQL Server nodes. You’ll run into problems such as this (among others).
When you do an IIS deployment you are changing something directly on the server, copy some files to a local directory, point IIS Metabase to that directory, etc. The tentacle needs to be installed because it is doing some low level access. With SQL Server, you are running scripts against port 1433. It doesn’t need to be on SQL Server. I’d recommend:
- Setting up a jumpbox or a worker pool to sit between Octopus Deploy and your SQL Servers.
- Storing the database server and name as a variable for each tenant, using either the project variable template or a variable set variable template.
Your scripts will use those tenant variables to determine which database to connect to.
Thanks Bob. Gives me something to think about.
In our case we are actually deploying a SQL Backup (.bak file) to the server and then using a step to Restore it locally. It seemed that the tentacle was a necessity since we’re not just running scripts against a SQL server. I suppose we could establish one central network location that each SQL server would have to reach out to for the .bak file and map them all to it.
Ah, I see. Makes sense. With .bak files they don’t have to be physically on the SQL Server, they can be on a file share somewhere and run the Restore Database command. Typically, most SQL Servers I see don’t have any files stored directly on them, so hopefully your DBA has a file share you can dump these to.
1 Like